MyZubster Is Entering Its Hardest Phase: Connecting Code to Reality

MyZubster, an Italian open-source digital ecosystem, is transitioning from building components to integrating them into a unified system, a phase its developers describe as the hardest yet. The project recently encountered a storage issue while running a Monero node, where a full disk halted blockchain synchronization, highlighting the need for capacity, reliability, and observability in addition to features. The team emphasizes that a process being 'running' is not sufficient for health; multiple signals are required to verify operational status.

MyZubster Is Entering Its Hardest Phase: Connecting Code to Reality Building a prototype is relatively easy. Building a repository is harder. Building an ecosystem where software, infrastructure, AI, blockchain, contributors and real-world data must work together is something else entirely. That's the phase MyZubster is beginning to enter. MyZubster is an Italian open-source digital ecosystem currently under development. It isn't a finished product, and we don't want to describe experimental components as production-ready systems. But something important is happening. The project is moving from: BUILDING COMPONENTS toward: CONNECTING COMPONENTS ↓ TESTING THEM ↓ OBSERVING FAILURES ↓ COLLECTING EVIDENCE ↓ VERIFYING RESULTS And this transition is changing how we think about the entire architecture. The prototype phase is ending Early-stage development encourages experimentation. You create APIs. You test databases. You integrate AI. You deploy services. You experiment with blockchain. You build interfaces. You create repositories. Eventually, however, adding another component stops being the hardest problem. The real question becomes: Can these components operate together as one observable system? That's where MyZubster is heading. A simplified view looks like this: MYZUBSTER Developers ───────────────┐ │ Users ────────────────────┤ │ IoT / Sensors ────────────┤ ▼ DATA LAYER │ ▼ PROVENANCE │ ┌─────────┴─────────┐ ▼ ▼ AI BLOCKCHAIN │ │ └─────────┬─────────┘ ▼ EVIDENCE │ ▼ VERIFICATION │ ▼ DIGITAL SERVICES Every box is relatively understandable individually. The difficulty exists between the boxes. Infrastructure immediately challenges architecture We recently saw a perfect example while operating a Monero node. The daemon was running. RPC was responding. The node reported: busy syncing: true synchronized: false Everything appeared to suggest normal synchronization. Except the blockchain height stopped progressing. The reason wasn't an exotic blockchain bug. It was storage. The server reached: /dev/mapper/lv-root 79 GB total 79 GB used 0 GB available 100% The Monero LMDB database had grown significantly while the node was still catching up with the network. We recovered several gigabytes by identifying development repositories that were safely reproducible from their remote Git repositories. The node immediately began moving again. We observed progress from approximately: 2,705,556 ↓ 2,708,936 ↓ 2,711,216 ↓ 2,838,236 Then something equally useful happened. The filesystem filled again. Why? Because the underlying capacity problem hadn't disappeared. We had treated the symptom. Not the architecture. That's a development milestone too It might sound strange to call a full disk a milestone. But it exposed something important. MyZubster can no longer think only about: FEATURES We need to think about: CAPACITY RELIABILITY OBSERVABILITY RECOVERY DATA GROWTH SERVICE HEALTH That's what happens when experimental software begins interacting with persistent infrastructure. The architecture diagram meets physics. And physics usually wins. “Running” is not a health status This experience also reinforced another principle. Suppose Linux tells us: monerod → RUNNING That doesn't prove the node is healthy. Actual health requires multiple signals: Process alive + RPC responsive + Network connectivity + Peers + Database writable + Blockchain height progressing + Storage available = Operational Node This idea extends far beyond blockchain. An API returning 200 OK doesn't necessarily mean the underlying system is functioning correctly. An AI model returning an answer doesn't mean the answer is correct. A sensor sending packets doesn't mean its measurements are valid. A CI workflow passing doesn't prove a physical-world claim. Availability is not verification. This changes how we think about AI AI is becoming increasingly capable of observing and operating software systems. But giving AI access to infrastructure without giving it reliable evidence creates another problem. Imagine an agent receiving: monerod = running It could conclude: Everything is operational. But give it: { "process": "running", "rpc": "responsive", "syncing": true, "height progressing": false, "disk usage": 100, "disk available": 0 } and the conclusion changes completely. Now the agent has evidence. This is the model we're interested in: OBSERVATION ↓ EVIDENCE ↓ AI ANALYSIS ↓ INTERPRETATION ↓ ACTION ↓ VERIFICATION Not: AI ↓ GUESS ↓ ACTION GitHub becomes more important in this model Another interesting development is happening around contribution. External developers are beginning to show interest in concrete MyZubster work. Recent areas include: REST APIs MongoDB schemas mapping data Node.js / Express data pipelines unit testing QA reproducibility API verification This is significant for an open-source project. Because the transition we ultimately want isn't: Founder writes code ↓ Repository grows It's: Problem ↓ Issue ↓ Contributor ↓ Implementation ↓ CI ↓ Review ↓ Evidence ↓ Reusable component GitHub therefore becomes more than storage. Issues document problems. Pull requests document proposed solutions. Commits document changes. CI documents automated verification attempts. Failures document assumptions that didn't survive testing. That history has value. Failed CI isn't noise We're also seeing experimental workflows fail. That's expected. When building blockchain settlement experiments, metaverse integrations, APIs or other new components, some workflows won't pass immediately. The wrong response would be hiding those failures. A verification-oriented ecosystem should preserve them. ASSUMPTION ↓ IMPLEMENTATION ↓ TEST ↓ FAIL ↓ EVIDENCE ↓ DIAGNOSIS ↓ NEW IMPLEMENTATION Failure becomes part of the development record. This principle becomes even more important when software begins making claims about the physical world. From software testing to real-world verification One of MyZubster's emerging research directions concerns environmental and agricultural applications. We're exploring questions around: environmental data; agronomic data; water; irrigation; circular water reuse; IoT; KPI; MRV; data governance; scientific validation. This creates a fascinating engineering problem. Imagine MyZubster eventually displays: WATER SAVED: 31% Where did 31% come from? A database? An AI model? A sensor? A calculation? A researcher? A manually entered value? Without provenance, it's just another number on a dashboard. A meaningful pipeline requires something closer to: PHYSICAL EVENT ↓ MEASUREMENT ↓ RAW DATA ↓ TIMESTAMP + CONTEXT ↓ PROVENANCE ↓ METHODOLOGY ↓ CALCULATION ↓ KPI ↓ EVIDENCE ↓ VALIDATION Now the number has a history. And potentially, it can be challenged and reproduced. This is why we're exploring MRV MRV means: Measurement, Reporting and Verification. It's common terminology in environmental and sustainability contexts, but from a developer perspective it introduces a powerful architectural idea. A system shouldn't simply report a result. It should preserve enough information to explain how the result was produced. That principle could eventually apply far beyond environmental projects. Imagine: Environmental contribution ↓ Evidence ↓ Verification Developer contribution ↓ Evidence ↓ Verification Physical-world event ↓ Evidence ↓ Verification Digital transaction ↓ Evidence ↓ Verification Different domains. Same architectural principle. Exploring LIFE 2027 We're also currently exploring whether a focused environmental use case could eventually become part of a future LIFE 2027 proposal. This needs an important clarification. Exploration is not funding. A conversation is not a partnership. A proposed consortium is not an approved consortium. And a research direction is not a completed project. We're currently interested in determining whether there is a problem that is: REAL + MEASURABLE + SCIENTIFICALLY VALIDATABLE + TECHNICALLY IMPLEMENTABLE + REPLICABLE Only after those conditions start making sense does the technology become interesting. The objective shouldn't be: “How can we put MyZubster into a European project?” It should be: “Is there a measurable environmental problem where MyZubster's architecture can provide useful evidence?” That's a much better engineering question. Scientific validation introduces a new boundary Developers are accustomed to this: npm test PASS But imagine we're testing environmental impact. A passing unit test cannot prove that irrigation efficiency improved. CI can verify the software that performs a calculation. It cannot independently prove the physical event behind the input data. That's where different disciplines begin connecting: SOFTWARE ENGINEERING + FIELD DATA + IOT + DATA SCIENCE + SCIENTIFIC METHODOLOGY + MRV = VERIFIABLE RESULT And this is precisely why MyZubster increasingly looks like an ecosystem rather than a conventional application. The next phase Our biggest challenge now isn't adding another hundred features. It's proving one complete vertical slice. For example: REAL-WORLD EVENT ↓ SENSOR / SOURCE ↓ RAW DATA ↓ PROVENANCE ↓ MYZUBSTER ↓ AI ANALYSIS ↓ KPI ↓ SCIENTIFIC VERIFICATION ↓ REPRODUCIBLE RESULT One pipeline. One measurable use case. One result. If it works, we improve it. If it fails, we document why. Then we build again. The real product may be evidence There's an interesting possibility hidden inside all of this. Maybe the most important thing MyZubster eventually produces isn't an application screen. Maybe it isn't an NFT. Maybe it isn't an AI response. Maybe it isn't even a blockchain transaction. Perhaps the fundamental unit is: VERIFIABLE EVIDENCE Everything else could become a way of producing, processing, connecting or interpreting it. People create evidence. Devices create measurements. GitHub records development evidence. Blockchains can anchor certain records. AI interprets information. Scientists validate methodologies. Applications make the results usable. Then the architecture starts looking different: MYZUBSTER People ───────────┐ Devices ──────────┤ Developers ───────┤ Sensors ──────────┤ Software ─────────┤ ▼ EVIDENCE │ ┌───────┼───────┐ ▼ ▼ ▼ AI MRV Blockchain │ │ │ └───────┼───────┘ ▼ VERIFICATION │ ▼ TRUST Not blind trust. Inspectable trust. We're still building There are components that work. There are components being tested. There are infrastructure problems we're solving. There are contributors beginning to participate. There are research directions being explored. There are failed workflows. There are ideas that may never survive experimentation. That's exactly why we're building publicly. Because the interesting question isn't: Can we make MyZubster look finished? It's: Can we build a digital ecosystem capable of showing how it knows what it claims to know? That's a much harder problem. And that's the one worth attempting. MyZubster Build → Observe → Measure → Verify → Connect → Replicate Suggested DEV tags: opensource programming ai devopsMyZubster Is Entering Its Hardest Phase: Connecting Code to Reality Building a prototype is relatively easy. Building a repository is harder. Building an ecosystem where software, infrastructure, AI, blockchain, contributors and real-world data must work together is something else entirely. That's the phase MyZubster is beginning to enter. MyZubster is an Italian open-source digital ecosystem currently under development. It isn't a finished product, and we don't want to describe experimental components as production-ready systems. But something important is happening. The project is moving from: BUILDING COMPONENTS toward: CONNECTING COMPONENTS ↓ TESTING THEM ↓ OBSERVING FAILURES ↓ COLLECTING EVIDENCE ↓ VERIFYING RESULTS And this transition is changing how we think about the entire architecture. The prototype phase is ending Early-stage development encourages experimentation. You create APIs. You test databases. You integrate AI. You deploy services. You experiment with blockchain. You build interfaces. You create repositories. Eventually, however, adding another component stops being the hardest problem. The real question becomes: Can these components operate together as one observable system? That's where MyZubster is heading. A simplified view looks like this: MYZUBSTER Developers ───────────────┐ │ Users ────────────────────┤ │ IoT / Sensors ────────────┤ ▼ DATA LAYER │ ▼ PROVENANCE │ ┌─────────┴─────────┐ ▼ ▼ AI BLOCKCHAIN │ │ └─────────┬─────────┘ ▼ EVIDENCE │ ▼ VERIFICATION │ ▼ DIGITAL SERVICES Every box is relatively understandable individually. The difficulty exists between the boxes. Infrastructure immediately challenges architecture We recently saw a perfect example while operating a Monero node. The daemon was running. RPC was responding. The node reported: busy syncing: true synchronized: false Everything appeared to suggest normal synchronization. Except the blockchain height stopped progressing. The reason wasn't an exotic blockchain bug. It was storage. The server reached: /dev/mapper/lv-root 79 GB total 79 GB used 0 GB available 100% The Monero LMDB database had grown significantly while the node was still catching up with the network. We recovered several gigabytes by identifying development repositories that were safely reproducible from their remote Git repositories. The node immediately began moving again. We observed progress from approximately: 2,705,556 ↓ 2,708,936 ↓ 2,711,216 ↓ 2,838,236 Then something equally useful happened. The filesystem filled again. Why? Because the underlying capacity problem hadn't disappeared. We had treated the symptom. Not the architecture. That's a development milestone too It might sound strange to call a full disk a milestone. But it exposed something important. MyZubster can no longer think only about: FEATURES We need to think about: CAPACITY RELIABILITY OBSERVABILITY RECOVERY DATA GROWTH SERVICE HEALTH That's what happens when experimental software begins interacting with persistent infrastructure. The architecture diagram meets physics. And physics usually wins. “Running” is not a health status This experience also reinforced another principle. Suppose Linux tells us: monerod → RUNNING That doesn't prove the node is healthy. Actual health requires multiple signals: Process alive + RPC responsive + Network connectivity + Peers + Database writable + Blockchain height progressing + Storage available = Operational Node This idea extends far beyond blockchain. An API returning 200 OK doesn't necessarily mean the underlying system is functioning correctly. An AI model returning an answer doesn't mean the answer is correct. A sensor sending packets doesn't mean its measurements are valid. A CI workflow passing doesn't prove a physical-world claim. Availability is not verification. This changes how we think about AI AI is becoming increasingly capable of observing and operating software systems. But giving AI access to infrastructure without giving it reliable evidence creates another problem. Imagine an agent receiving: monerod = running It could conclude: Everything is operational. But give it: { "process": "running", "rpc": "responsive", "syncing": true, "height progressing": false, "disk usage": 100, "disk available": 0 } and the conclusion changes completely. Now the agent has evidence. This is the model we're interested in: OBSERVATION ↓ EVIDENCE ↓ AI ANALYSIS ↓ INTERPRETATION ↓ ACTION ↓ VERIFICATION Not: AI ↓ GUESS ↓ ACTION GitHub becomes more important in this model Another interesting development is happening around contribution. External developers are beginning to show interest in concrete MyZubster work. Recent areas include: REST APIs MongoDB schemas mapping data Node.js / Express data pipelines unit testing QA reproducibility API verification This is significant for an open-source project. Because the transition we ultimately want isn't: Founder writes code ↓ Repository grows It's: Problem ↓ Issue ↓ Contributor ↓ Implementation ↓ CI ↓ Review ↓ Evidence ↓ Reusable component GitHub therefore becomes more than storage. Issues document problems. Pull requests document proposed solutions. Commits document changes. CI documents automated verification attempts. Failures document assumptions that didn't survive testing. That history has value. Failed CI isn't noise We're also seeing experimental workflows fail. That's expected. When building blockchain settlement experiments, metaverse integrations, APIs or other new components, some workflows won't pass immediately. The wrong response would be hiding those failures. A verification-oriented ecosystem should preserve them. ASSUMPTION ↓ IMPLEMENTATION ↓ TEST ↓ FAIL ↓ EVIDENCE ↓ DIAGNOSIS ↓ NEW IMPLEMENTATION Failure becomes part of the development record. This principle becomes even more important when software begins making claims about the physical world. From software testing to real-world verification One of MyZubster's emerging research directions concerns environmental and agricultural applications. We're exploring questions around: environmental data; agronomic data; water; irrigation; circular water reuse; IoT; KPI; MRV; data governance; scientific validation. This creates a fascinating engineering problem. Imagine MyZubster eventually displays: WATER SAVED: 31% Where did 31% come from? A database? An AI model? A sensor? A calculation? A researcher? A manually entered value? Without provenance, it's just another number on a dashboard. A meaningful pipeline requires something closer to: PHYSICAL EVENT ↓ MEASUREMENT ↓ RAW DATA ↓ TIMESTAMP + CONTEXT ↓ PROVENANCE ↓ METHODOLOGY ↓ CALCULATION ↓ KPI ↓ EVIDENCE ↓ VALIDATION Now the number has a history. And potentially, it can be challenged and reproduced. This is why we're exploring MRV MRV means: Measurement, Reporting and Verification. It's common terminology in environmental and sustainability contexts, but from a developer perspective it introduces a powerful architectural idea. A system shouldn't simply report a result. It should preserve enough information to explain how the result was produced. That principle could eventually apply far beyond environmental projects. Imagine: Environmental contribution ↓ Evidence ↓ Verification Developer contribution ↓ Evidence ↓ Verification Physical-world event ↓ Evidence ↓ Verification Digital transaction ↓ Evidence ↓ Verification Different domains. Same architectural principle. Exploring LIFE 2027 We're also currently exploring whether a focused environmental use case could eventually become part of a future LIFE 2027 proposal. This needs an important clarification. Exploration is not funding. A conversation is not a partnership. A proposed consortium is not an approved consortium. And a research direction is not a completed project. We're currently interested in determining whether there is a problem that is: REAL + MEASURABLE + SCIENTIFICALLY VALIDATABLE + TECHNICALLY IMPLEMENTABLE + REPLICABLE Only after those conditions start making sense does the technology become interesting. The objective shouldn't be: “How can we put MyZubster into a European project?” It should be: “Is there a measurable environmental problem where MyZubster's architecture can provide useful evidence?” That's a much better engineering question. Scientific validation introduces a new boundary Developers are accustomed to this: npm test PASS But imagine we're testing environmental impact. A passing unit test cannot prove that irrigation efficiency improved. CI can verify the software that performs a calculation. It cannot independently prove the physical event behind the input data. That's where different disciplines begin connecting: SOFTWARE ENGINEERING + FIELD DATA + IOT + DATA SCIENCE + SCIENTIFIC METHODOLOGY + MRV = VERIFIABLE RESULT And this is precisely why MyZubster increasingly looks like an ecosystem rather than a conventional application. The next phase Our biggest challenge now isn't adding another hundred features. It's proving one complete vertical slice. For example: REAL-WORLD EVENT ↓ SENSOR / SOURCE ↓ RAW DATA ↓ PROVENANCE ↓ MYZUBSTER ↓ AI ANALYSIS ↓ KPI ↓ SCIENTIFIC VERIFICATION ↓ REPRODUCIBLE RESULT One pipeline. One measurable use case. One result. If it works, we improve it. If it fails, we document why. Then we build again. The real product may be evidence There's an interesting possibility hidden inside all of this. Maybe the most important thing MyZubster eventually produces isn't an application screen. Maybe it isn't an NFT. Maybe it isn't an AI response. Maybe it isn't even a blockchain transaction. Perhaps the fundamental unit is: VERIFIABLE EVIDENCE Everything else could become a way of producing, processing, connecting or interpreting it. People create evidence. Devices create measurements. GitHub records development evidence. Blockchains can anchor certain records. AI interprets information. Scientists validate methodologies. Applications make the results usable. Then the architecture starts looking different: MYZUBSTER People ───────────┐ Devices ──────────┤ Developers ───────┤ Sensors ──────────┤ Software ─────────┤ ▼ EVIDENCE │ ┌───────┼───────┐ ▼ ▼ ▼ AI MRV Blockchain │ │ │ └───────┼───────┘ ▼ VERIFICATION │ ▼ TRUST Not blind trust. Inspectable trust. We're still building There are components that work. There are components being tested. There are infrastructure problems we're solving. There are contributors beginning to participate. There are research directions being explored. There are failed workflows. There are ideas that may never survive experimentation. That's exactly why we're building publicly. Because the interesting question isn't: Can we make MyZubster look finished? It's: Can we build a digital ecosystem capable of showing how it knows what it claims to know? That's a much harder problem. And that's the one worth attempting. MyZubster Build → Observe → Measure → Verify → Connect → Replicate