MyZubster Development Update: From Open-Source Code to a Verifiable Ecosystem
Over the last few weeks, MyZubster has been evolving quickly.
But the most important change isn't a new UI, another AI model, or another repository.
It's architectural.
We're beginning to connect pieces that were previously developed independently:
open source, AI, blockchain infrastructure, real-world data, digital identity, environmental applications, and scientific validation.
MyZubster remains under active development. Some components are operational, others are prototypes, and several directions described here are still being researched.
That distinction matters.
Here's where we're going.
- GitHub is becoming part of the ecosystem
Our GitHub organization is increasingly more than a place where source code is stored.
Development now spans repositories and experiments covering areas such as:
MyZubster
├── Core platform
├── Gateway / APIs
├── Mapping
├── Digital identity
├── AI
├── Blockchain experiments
├── Environmental data
├── Metaverse experiments
├── Marketplace
└── Verification infrastructure
We're also seeing external developers expressing interest in specific issues.
Recent contributor interest includes work around:
REST APIs for mapping plants, animals and people;
MongoDB data models;
backend development;
API/data pipelines;
unit testing;
reproducibility and verification.
This is important because an open-source ecosystem becomes much more interesting when development isn't limited to its original creator.
- We're testing blockchain infrastructure for real
Blockchain integration isn't useful if it exists only in an architecture diagram.
We're operating infrastructure and discovering the practical problems that come with it.
One recent example came from our Monero node.
The node appeared to be synchronizing:
busy_syncing: true
synchronized: false
But eventually synchronization stopped progressing.
The problem wasn't theoretical.
The server had reached:
Disk usage: 100%
Available: 0 GB
After identifying reproducible local repositories and safely removing unnecessary copies, storage became available again.
The result?
The blockchain immediately continued progressing.
We observed the height moving through values such as:
2,705,556
↓
2,708,936
↓
2,711,216
↓
2,838,236
That gave us a valuable infrastructure lesson:
A process being alive doesn't mean a service is healthy.
- Infrastructure is now becoming an engineering problem of its own
The Monero incident changed how we're thinking about MyZubster operations.
A production service shouldn't simply expose:
RUNNING
It should expose evidence about its actual condition.
For a blockchain node, for example:
PROCESS
+
RPC
+
PEERS
+
BLOCK HEIGHT
+
SYNC PROGRESS
+
DISK CAPACITY
+
DATABASE HEALTH
=
OPERATIONAL STATE
We're now addressing the immediate infrastructure bottleneck by planning additional server storage.
But the larger lesson is architectural.
Eventually, MyZubster services should be capable of describing their own operational state in machine-readable form.
Imagine:
{
"service": "blockchain-node",
"state": "syncing",
"storage_pressure": true,
"rpc": "available",
"progressing": true,
"action_required": "expand-storage"
}
Now an AI agent doesn't need to guess whether infrastructure is healthy.
It can reason over evidence.
- AI should analyze evidence, not manufacture truth
This has become one of the central principles behind MyZubster.
We don't want:
DATA
↓
AI
↓
TRUTH
We want something closer to:
SOURCE
↓
RAW DATA
↓
PROVENANCE
↓
EVIDENCE
↓
AI ANALYSIS
↓
INTERPRETATION
↓
VERIFICATION
AI can be extremely powerful inside this pipeline.
But the evidence needs to remain distinguishable from the AI's interpretation of that evidence.
This principle becomes particularly important when software begins interacting with the physical world.
- Environmental applications are becoming a serious research direction
One of the directions we're exploring for MyZubster concerns environmental and agricultural data.
We're currently discussing areas including:
Water
Agriculture
Irrigation
Circular water reuse
Environmental monitoring
Agronomic data
KPI
MRV
Data governance
Scientific validation
This isn't about adding a green dashboard to an application.
The challenge is much harder.
Suppose a digital system claims:
Water consumption reduced by X%
How do we prove it?
We need to know:
What was measured?
Where?
When?
Using which instrument?
What was the baseline?
What methodology was used?
How was the KPI calculated?
Can another party reproduce it?
That's why we're exploring MRV:
Measurement, Reporting and Verification.
- We're exploring a LIFE 2027 direction
Another important development is the exploration of a possible future LIFE 2027 proposal.
The concept we're investigating is not:
“Let's put MyZubster into an EU project.”
Instead:
Can we identify a real environmental problem and demonstrate a measurable improvement using an open, verifiable digital infrastructure?
A possible architecture looks like this:
REAL ENVIRONMENT
↓
MEASUREMENT
↓
DATA
↓
PROVENANCE
↓
MYZUBSTER
↓
AI / ANALYSIS
↓
KPI / MRV
↓
SCIENTIFIC VALIDATION
↓
MEASURED IMPACT
↓
REPLICATION
We're having exploratory conversations with organizations and researchers around these questions.
These discussions should not be interpreted as finalized partnerships, funding decisions, or an approved LIFE consortium.
We're still doing the work required to determine what is scientifically and economically realistic.
- Scientific validation changes the role of software
This is perhaps the most interesting part.
Normally developers decide whether software works.
Tests pass.
CI turns green.
The application deploys.
Done.
But consider environmental claims.
A successful deployment doesn't prove environmental impact.
CI PASSING
≠
SCIENTIFICALLY VALID RESULT
Software can collect and process evidence.
Researchers can define methodologies.
Field operators can produce observations.
Sensors can generate measurements.
AI can analyze patterns.
But the final claim needs to survive verification.
This creates an interesting intersection between:
software engineering + science + field operations.
- Contributors could eventually participate in more than coding
This also changes what an open-source contributor could mean inside MyZubster.
Today contribution normally looks like:
Issue
↓
Fork
↓
Code
↓
Pull Request
↓
Review
↓
Merge
Tomorrow we want to investigate a broader model:
Contribution
↓
Evidence
↓
Verification
↓
Reputation
↓
Reusable knowledge
A contribution might eventually involve software, datasets, documentation, validation, mapping or other forms of verifiable work.
That's still a direction under development, not a finished mechanism.
But it's an important distinction.
- We're learning that failure is valuable data
Some CI workflows fail.
Some integrations don't behave as expected.
Infrastructure runs out of resources.
Experimental architectures need redesigning.
That's normal.
In fact, for a system centered around verification, failure must remain visible.
Experiment
↓
FAIL
↓
Evidence
↓
Diagnosis
↓
Improvement
is often more valuable than:
Experiment
↓
Everything is fine
without evidence.
This is one reason we're building MyZubster publicly.
- What MyZubster is becoming
It's becoming increasingly difficult to describe MyZubster simply as an application.
A better description might be:
MyZubster is an open-source experimental digital ecosystem designed to connect people, software, AI and real-world data through verifiable evidence.
That's an ambition, not a declaration that every layer is already complete.
Today we have code.
We have infrastructure.
We have experiments.
We have contributors beginning to appear.
We have blockchain nodes.
We have APIs.
We have prototypes.
We have research discussions.
And we have failures that are teaching us how the architecture needs to evolve.
The next milestone isn't to claim that everything is finished.
It's to make one complete pipeline work:
REAL EVENT
↓
DATA
↓
PROVENANCE
↓
EVIDENCE
↓
AI
↓
KPI
↓
VERIFICATION
↓
REPRODUCIBLE RESULT
If we can demonstrate that end-to-end on a meaningful real-world use case, MyZubster will have crossed a much more important boundary than simply launching another application.
It will have connected software to verifiable reality.
And that's the experiment we're building in public.
MyZubster
Build → Observe → Measure → Verify → Connect → Replicate