Building an Evidence-First Contributor Network: How MyZubster Connects Independent Projects
Open-source collaboration becomes fragile when contribution history, current responsibilities, public profiles, and external projects all live in different places.
At MyZubster, we are working on a simpler boundary:
Contributors keep control of their own repositories and environments.
MyZubster connects only the evidence, interfaces, and explicitly approved collaboration checkpoints.
This is not a claim that every contributor belongs to a DAO, has a public digital passport, or is part of a funded research consortium. Those are separate states and must remain separate.
Our public README now includes a compact status index for contributor roles, digital-passport publication, external projects, and LIFE-oriented pilot candidates:
The model
A connected contributor project follows this path:
independent repository or environment
→ public, bounded evidence
→ documented interface or fixture
→ reproducible test
→ reviewed result
→ optional Knowledge / Passport / pilot link
The important words are bounded, optional, and reviewed.
A GitHub fork is not automatically a competence credential. A merged pull request is not automatically a public Passport. A pilot is not automatically a partnership. And a LIFE-oriented internal track is not an EU LIFE grant or consortium.
The contributors and linked projects
Daniel Ioni — coordination and evidence boundaries
- GitHub: @danieldirimini-myzubster
- Core project: MyZubster
- Current scope: interim product and governance coordination, privacy boundaries, acceptance criteria, and evidence architecture.
The role is deliberately limited: coordination is not unilateral DAO authority. High-impact actions such as public-profile publication, treasury activity, deployment, funding, or institutional commitments require their own explicit process.
Nicola / N4K48 — independent Docker node and interoperability reference
- GitHub: @nicolaususnicola-lgtm
- Project: myzubster-mvp
- Reference: independent pilot-node path
Nicola’s work is the clearest example of the independent-project model. The N4K48 environment remains independently operated, while published Docker, provenance, and read-only interoperability evidence can be reviewed by others.
The next proposed checkpoint is an authenticated, sanitized N4K48 ↔ MyZubster test. It is a technical interoperability task—not a transfer of ownership, a production deployment, or a LIFE membership claim.
khongten124 — Open Period Care research and evidence package
- GitHub: @khongten124
- Evidence: PR #1451
- Project documentation: Open Period Care package
- Network reference: Pilot Node Network #1505
The Open Period Care work is connected as a research/evidence package. The contribution has a bounded evidence state and can be reused as a reference for provenance, structured requirements, and reproducible review.
It does not claim clinical validation, product efficacy, institutional endorsement, or a formal LIFE role.
Aming9303 — gateway, sensor, replication, and signed-webhook evidence
- GitHub: @Aming9303
- Project fork: MyZubsterGateway
- Evidence:
Aming’s public work contributes to the technical edge of the network: adapters, replication checks, and signed webhook behavior. These are useful building blocks for future environmental or operational pilots, including Circular Water, but they do not imply access to a partner’s systems or data.
wasim-builds — security and local resilience design
- GitHub: @wasim-builds
- Evidence:
Wasim has opted into a strictly local and isolated resilience-design track. The planned deliverable is a draft PR containing a threat model, Compose configuration, health checks, rollback instructions, and redacted smoke-test evidence.
There is no authorization for a public Onion deployment, production access, reimbursement, or paid bounty in that scope.
foxxx009 — documentation, KPI, and evidence framework
- GitHub: @foxxx009
- Documentation repository: myzubster-docs
- Marketplace repository: MyZubster-Marketplace
- Evidence:
foxxx009 has consented to existing public graph links. That is not the same as accepting a new project assignment. Their evidence is useful for future independent verification and KPI work, but any new pilot must start with a separate opt-in and a defined test plan.
Shweta Singh — technical verifier path, still consent pending
- GitHub: @Shweta-singh24
- Project fork: MyZubsterGateway
- Reference: Pilot Node Network #1505
Shweta’s public fork has been discovered, but a fork alone is not enough to claim a verified contributor role. The proposed path is technical verification: Docker, Node.js, HTTPS/read-only interoperability, documentation, and contributor-to-contributor reproduction.
That path remains opt-in and evidence pending.
What the digital Passport means
A MyZubster Contributor Passport is not an automatic profile created from a GitHub username.
A public Passport requires explicit publication consent. It should expose only an approved, minimized public projection of contribution evidence. It must not expose internal reviewer data, payment identifiers, reward amounts, settlement records, secrets, or sensitive personal information.
This is an active privacy requirement, tracked in issue #1598.
What “LIFE-oriented” means here
MyZubster has candidate real-world tracks such as kefir, Circular Water, and circular-care evidence. They can reuse technical components created by independent contributors:
- Docker and independent-node operation;
- data schemas and deterministic hashes;
- read-only adapters;
- KPI dashboards;
- evidence review and provenance;
- privacy and consent controls.
But the language must stay precise:
- a candidate is not a consortium member;
- a technical pilot is not a validated field pilot;
- a company reviewing a concept is not yet a project partner;
- an internal LIFE-oriented track is not EU LIFE funding.
For Circular Water, the correct approach is to build reusable, synthetic-data components first. If a water utility later authorizes a real case, only the authorized data, constraints, and measurements are connected to the shared framework.
Why this structure matters
The goal is not to centralize everyone’s work under one account or one server.
The goal is to make collaboration inspectable:
who owns the project?
what was actually tested?
what evidence is public?
what is proposed versus accepted?
what consent exists?
what can be reused safely?
That is how a contributor network becomes credible: not by making the biggest possible claim, but by preserving the boundary between evidence, consent, current work, and future ambition.
If you want to contribute, start with a small bounded task, publish reproducible evidence, and keep control of your own work. The network can connect it when both the technical and consent conditions are satisfied.
Top comments (0)