DEV Community

Daniel Ioni
Daniel Ioni

Posted on

From Contributors to Independent Nodes: Building Evidence-First Decentralization in MyZubster

#decentralization #ai #devops #opensource

From Contributors to Independent Nodes: Building Evidence-First Decentralization in MyZubster

Open source becomes much more interesting when contributions stop being isolated pull requests.

A contributor writes a security regression test.

Another builds signed payment webhooks.

Another develops a KPI and evidence framework.

Another maintains an independent Docker node.

Another contributes research and structured Knowledge Cards.

Another implements jurisdiction policy enforcement.

Normally, all of these contributions eventually disappear into the same repository history.

We wanted something different.

We wanted each contribution to remain attributable to its author, independently reproducible, and connectable to a broader network of people, projects, evidence, and knowledge.

Today we moved MyZubster one step closer to that model.

We built and tested an evidence-first contributor interoperability layer where independent contributions can be reproduced on controlled infrastructure, verified against explicit expectations, and recorded without pretending that every contributor runs the same software or that every successful test proves more than it actually does.

The central idea is simple:

Independent contributors do not need identical runtimes. They need a common evidence contract.

This article explains what we built, what failed along the way, what we currently mean by “decentralization,” and how new contributors can join the experiment.

The problem with contribution graphs

A GitHub graph already contains a lot of useful information:

Contributor
    ↓
Repository
    ↓
Issue
    ↓
Pull Request
    ↓
Commit
Enter fullscreen mode Exit fullscreen mode

But that graph does not answer several important questions.

Can somebody else reproduce the contribution?

Does it still work on the current codebase?

Which exact commit was tested?

What inputs were used?

What was expected?

What actually happened?

What evidence boundary applies?

And perhaps most importantly:

What does a successful test not prove?

We wanted a model that could extend the normal GitHub contribution graph:

Contributor
    ↓
Public repository / PR
    ↓
Immutable commit
    ↓
Independent verifier
    ↓
Controlled execution environment
    ↓
Expected vs actual result
    ↓
Evidence record
    ↓
Contributor / Knowledge Graph
Enter fullscreen mode Exit fullscreen mode

This is becoming the foundation of the MyZubster contributor network.

GitHub is the provenance layer

For this architecture, branches are useful for development.

Commits are useful for evidence.

A branch can move.

A commit SHA cannot.

So when we create a contributor interoperability checkpoint, we try to retain:

GitHub username
repository
pull request
contributor commit SHA
merged commit SHA, when applicable
test scope
expected behavior
actual behavior
limitations
Enter fullscreen mode Exit fullscreen mode

That means a future verifier does not have to trust a sentence saying:

“This contribution worked.”

It can instead ask:

“Can I reproduce this exact checkpoint?”

That distinction matters.

The VPS became an independent verification node

We use a MyZubster VPS as one controlled environment for independent reproduction.

But there is an important architectural distinction.

The VPS is not automatically a production server for contributors.

It is not unrestricted shell access.

It is not a shared root account.

It is not proof that a contributor controls MyZubster infrastructure.

It is a controlled test environment.

The current model is:

Contributor repository
        ↓
public immutable commit
        ↓
contributor-specific verifier
        ↓
MyZubster VPS
        ↓
isolated reproducible test
        ↓
structured result
Enter fullscreen mode Exit fullscreen mode

Depending on the contribution, execution may be:

  • maintainer-run;
  • isolated in Docker;
  • performed in a dedicated directory;
  • read-only;
  • based on synthetic data;
  • or eventually executed using scoped, least-privilege, time-limited contributor access.

Our public VPS pilot is here:

https://github.com/MyZubster-Ecosystem/myzubster/issues/1518

The access model intentionally requires:

  • narrow test scope;
  • explicit success criteria;
  • security/privacy review;
  • synthetic or explicitly authorized data;
  • no secrets in public issues;
  • rollback/cleanup expectations;
  • least privilege;
  • revocable access.

Direct VPS access is therefore possible as part of the pilot, but never automatic.

Often a maintainer-run deployment is enough.

One contributor does not imply one architecture

This became one of the most useful lessons.

Our contributors are not all building the same thing.

So we should not force all of them into the same “node” implementation.

Instead, we created several interoperability patterns.

Pattern 1 — Independent runtime reproduction

Nicola / N4K48 maintains an independent MyZubster MVP.

We reproduced a specific checkpoint on the MyZubster VPS:

repository:
nicolaususnicola-lgtm/myzubster-mvp

commit:
87a1021
Enter fullscreen mode Exit fullscreen mode

The independent environment included:

Docker
MyZubster API
Qdrant
Ollama
Open WebUI
nomic-embed-text
zorgax:latest
Enter fullscreen mode Exit fullscreen mode

The bounded checks included:

Docker build
API health
observation retrieval
comics catalog
read-only Zorgax flow
Enter fullscreen mode Exit fullscreen mode

This allowed us to record:

TESTED
Enter fullscreen mode Exit fullscreen mode

for the independent reproduction of that software checkpoint.

It did not mean:

direct P2P communication established
production deployment certified
NFT rights verified
commercial settlement proven
Enter fullscreen mode Exit fullscreen mode

Those are separate claims.

Pattern 2 — Evidence and semantic interoperability

The Open Period Care contribution by khongten124 is very different.

It is primarily a research/evidence package containing structured material and Knowledge Cards.

The integration therefore did not require reproducing another Docker application.

Instead, we built a read-only contributor bridge that could normalize public source artifacts and retain provenance.

Two canonical Knowledge Cards were involved:

KC-OPC-001
Multi-Layer Biomaterial Architecture for Reusable Textile Absorbents
SUPPORTED
Enter fullscreen mode Exit fullscreen mode

and:

KC-OPC-002
Contributor Privacy, Data Minimization & Clinical Boundaries
SUPPORTED
Enter fullscreen mode Exit fullscreen mode

The important part is the last word:

SUPPORTED.

A successful software integration did not magically promote those research states to TESTED.

What became TESTED was the technical retrieval path.

That distinction is fundamental to our evidence model.

The bridge was ultimately merged in:

https://github.com/MyZubster-Ecosystem/myzubster/pull/1511

Merged SHA:

6061140f4ade01ab10211b2a6698cac03f326e55
Enter fullscreen mode Exit fullscreen mode

Our semantic search failed before it passed

Open Period Care also revealed one of the most important AI architecture problems we encountered.

At first we used semantic retrieval over a shared Qdrant collection.

That worked for discovery.

But when contributors shared the same vector store, semantic similarity could rank the wrong contributor record first.

For example, a query for a specific Open Period Care Knowledge Card could retrieve an unrelated H4X0R record.

The problem was not necessarily the LLM.

The wrong source had been selected before generation even started.

That led us to separate two different questions.

Semantic search answers:

What looks relevant?
Enter fullscreen mode Exit fullscreen mode

Metadata lookup answers:

Which exact record is this?
Enter fullscreen mode Exit fullscreen mode

Those should not be treated as the same operation.

Our resulting rule is:

Vector search
    → discovery

Deterministic metadata lookup
    → identity
    → structured IDs
    → contributor scope
    → evidence status
    → provenance
Enter fullscreen mode Exit fullscreen mode

For authoritative Open Period Care lookups we therefore use metadata such as:

bridge = open-period-care
knowledgeCardId = KC-OPC-001
Enter fullscreen mode Exit fullscreen mode

instead of trusting semantic ranking to establish identity.

That contributor-scoped path was independently tested.

Pattern 3 — Exact-commit policy verification

Shweta-singh24 contributed jurisdiction-capability work in MyZubsterGateway.

An unusual detail made this checkpoint especially useful for testing our evidence philosophy:

the source pull request was closed and unmerged.

Instead of hiding that fact, we made it part of the evidence.

The verifier reproduced the exact contributor checkpoint:

commit:
82461433e0c5bfee9aa369b4a71e9331261cf803
Enter fullscreen mode Exit fullscreen mode

and checked policy behavior such as:

GLOBAL       → ALLOW
HK           → ALLOW
CN_MAINLAND  → DENY
Enter fullscreen mode Exit fullscreen mode

plus fail-closed cases for unknown values.

It also checked Tari/XMR policy wiring.

The verifier was merged in:

https://github.com/MyZubster-Ecosystem/myzubster/pull/1509

Merged SHA:

aa54fd380e487c11ba39fb40a092212f412cf364
Enter fullscreen mode Exit fullscreen mode

The status therefore means:

TESTED — exact closed/unmerged checkpoint
Enter fullscreen mode Exit fullscreen mode

Not:

merged upstream
deployed in production
legal approval
security certification
Enter fullscreen mode Exit fullscreen mode

This is the type of precision we want contributors to be able to rely on.

Pattern 4 — Security regression reproduction

Next we tested a merged contribution by wasim-builds.

The original contribution was:

https://github.com/MyZubster-Ecosystem/myzubster/pull/860

Contributor commit:

d378adbbd9690cfbac081758000bb95d64fe7fb1
Enter fullscreen mode Exit fullscreen mode

The contribution added explicit regression coverage for fail-closed admin authentication.

We created an independent verifier and ran it on the VPS against current MyZubster code.

The four bounded cases were:

ADMIN_API_KEY unconfigured → 503
admin credential missing   → 401
admin credential incorrect → 401
correct configured key     → 200
Enter fullscreen mode Exit fullscreen mode

Result:

4 / 4 PASS
Enter fullscreen mode Exit fullscreen mode

The independent verifier was merged through:

https://github.com/MyZubster-Ecosystem/myzubster/pull/1523

Merged SHA:

a0faab53f817c3c6379d3ccaaad5d3fac3b6fb1b
Enter fullscreen mode Exit fullscreen mode

Contributor state:

TESTED — fail-closed admin-auth regression
Enter fullscreen mode Exit fullscreen mode

Again, bounded.

It is not a penetration test.

It is not a general security certification.

It means the specific regression was independently reproduced.

Pattern 5 — Signed webhook interoperability

Aming9303 had already contributed signed payment lifecycle webhooks.

Original contribution:

https://github.com/MyZubster-Ecosystem/myzubster/pull/891

Contributor commit:

cee464b6a69e621442b30a57d2d56933988827e2
Enter fullscreen mode Exit fullscreen mode

The contribution includes:

  • HMAC-SHA256 signatures;
  • delivery IDs;
  • retry behavior;
  • timestamp boundaries;
  • replay protection;
  • constant-time signature comparison.

Our VPS verifier targeted five specific behaviors:

1. HMAC-SHA256 signature over exact JSON body
2. transient retry keeps the same delivery ID
3. configured endpoint without secret is rejected
4. replay of the same delivery ID is rejected
5. stale signed events are rejected before replay-store claim
Enter fullscreen mode Exit fullscreen mode

Result:

5 / 5 PASS
Enter fullscreen mode Exit fullscreen mode

The independent verifier was merged through:

https://github.com/MyZubster-Ecosystem/myzubster/pull/1524

Merged SHA:

1154a87d27332a779e86d11e4b7952c22099d533
Enter fullscreen mode Exit fullscreen mode

Contributor state:

TESTED — signed payment-webhook regression
Enter fullscreen mode Exit fullscreen mode

This does not mean that every external receiver on the internet is reliable.

It verifies the bounded webhook contract in the tested software path.

Pattern 6 — Evidence frameworks need anti-overclaim tests too

foxxx009 contributed a KPI, baseline and evidence/provenance framework.

Original contribution:

https://github.com/MyZubster-Ecosystem/myzubster/pull/894

Contributor commit:

70cb32c6500525df4056859525fe215b95188a02
Enter fullscreen mode Exit fullscreen mode

This contribution was particularly interesting because testing the arithmetic alone was not enough.

We also wanted to know whether a reporting framework could preserve evidence boundaries.

The independent VPS verifier checked:

baseline records = 3
pilot records = 2
default KPIs = 11
Enter fullscreen mode Exit fullscreen mode

and reproduced the water KPI according to its documented aggregation policy:

ratio-of-totals

(3222.5 + 3098.7) / (9.95 + 9.51)

= 324.83042137718394
Enter fullscreen mode Exit fullscreen mode

Observed:

324.83042137718394
Enter fullscreen mode Exit fullscreen mode

Exact match.

But we also tested:

  • provenance references;
  • JSON report generation;
  • Markdown report generation;
  • missing-data handling;
  • synthetic-data disclaimers;
  • no fabricated EU funding statement;
  • no fabricated “official approval” statement.

This test itself failed twice before passing.

And that was useful.

Why we kept the failures

The first failure happened because our verifier assumed pip was installed on the VPS.

It was not.

That was an infrastructure/verifier failure.

Not a contributor failure.

So we removed the dependency and made the verifier run using only:

Python 3 standard library
+
repository modules
Enter fullscreen mode Exit fullscreen mode

The second failure was even more valuable.

Our verifier incorrectly assumed the expected KPI was the average of two ratios.

But the contributor framework explicitly uses:

ratio-of-totals
Enter fullscreen mode Exit fullscreen mode

The contribution was correct.

Our verifier was wrong.

We fixed the verifier.

Then the test passed.

That final verifier was merged through:

https://github.com/MyZubster-Ecosystem/myzubster/pull/1525

Merged SHA:

f0c477f563ab7e92a734b3042d44063794b7f81f
Enter fullscreen mode Exit fullscreen mode

Contributor state:

TESTED — KPI/evidence/report regression
Enter fullscreen mode Exit fullscreen mode

This is why we do not treat FAILED as an embarrassing state.

A failed checkpoint is information.

Sometimes it finds a contributor bug.

Sometimes it finds an integration bug.

Sometimes it finds a verifier bug.

All three are useful.

What our contributor network looks like now

We now have several very different contributions connected through the same evidence philosophy:

                    MyZubster
                        |
        +---------------+----------------+
        |               |                |
        v               v                v
     N4K48        Open Period Care     Shweta
 Docker node       Evidence/RAG       Policy verifier
        |               |                |
        +---------------+----------------+
                        |
                        v
                 Evidence contract
                        |
        +---------------+----------------+
        |               |                |
        v               v                v
      wasim           Aming            foxxx
 Security test     Signed webhook     KPI/evidence
Enter fullscreen mode Exit fullscreen mode

These are not identical nodes.

They do not need to be.

What they share is:

public provenance
immutable source checkpoint
bounded test objective
independent reproduction
expected vs actual result
explicit limitations
Enter fullscreen mode Exit fullscreen mode

That shared contract is the network layer.

So is this decentralized?

Partially.

And terminology matters.

What we have demonstrated is decentralization of contribution provenance and reproducibility.

Contributors can own:

  • their GitHub identity;
  • their repositories;
  • their branches and commits;
  • their artifacts;
  • their evidence;
  • potentially their own runtime/node.

The central MyZubster environment does not need to become the sole source of truth about whether their work exists.

The evidence can point back to contributor-owned sources.

What we have not yet fully demonstrated is:

direct contributor-to-contributor P2P exchange
fully federated execution
independent consensus
permissionless infrastructure access
fully distributed production state
Enter fullscreen mode Exit fullscreen mode

Those are later stages.

We would rather describe the current state precisely than call everything “decentralized” too early.

The next phase: contributor-to-contributor bridges

We have opened a separate opt-in path for contributors who want to connect directly to the N4K48 pilot network:

https://github.com/MyZubster-Ecosystem/myzubster/issues/1520

The state machine is intentionally explicit:

PROPOSED / CONSENT PENDING
        ↓
OPTED IN BY CONTRIBUTOR
        ↓
APPROVED BY BOTH SIDES
        ↓
TEST PLAN AGREED
        ↓
TESTED
        ↓
VERIFIED
Enter fullscreen mode Exit fullscreen mode

A similar technology stack does not automatically create collaboration.

A graph edge does not create consent.

A GitHub mention does not create a partnership.

Direct connections are opt-in.

How to contribute

If you are reading this and want to connect your own work to MyZubster, you do not need to reproduce everything described above.

You need one small, reviewable artifact.

That could be:

a test
a bug fix
a Docker service
a dataset validator
a webhook
a sensor adapter
a research package
a security regression
a documentation package
a reproducible workflow
a KPI implementation
an evidence format
an API integration
Enter fullscreen mode Exit fullscreen mode

The canonical public repository is:

https://github.com/MyZubster-Ecosystem/myzubster

A good contributor path looks like this.

Step 1 — Publish something reviewable

Use a public repository, branch or pull request.

Avoid making the first artifact huge.

A narrow contribution is much easier to review and reproduce.

Step 2 — Give us an immutable checkpoint

Prefer:

repository
branch
commit SHA
Enter fullscreen mode Exit fullscreen mode

rather than:

“latest version”
Enter fullscreen mode Exit fullscreen mode

We need to know exactly what is being tested.

Step 3 — Define one bounded objective

Bad:

Verify my whole project.
Enter fullscreen mode Exit fullscreen mode

Better:

Given this fixture,
run this command,
expect this output.
Enter fullscreen mode Exit fullscreen mode

Even better:

Expected:
invalid signature → reject

Expected:
valid signature → accept

Expected:
same delivery ID twice → reject replay
Enter fullscreen mode Exit fullscreen mode

Deterministic tests are easier to trust.

Step 4 — Document dependencies

Tell us:

runtime
CPU/RAM needs
ports
environment variable names
startup command
test command
cleanup command
Enter fullscreen mode Exit fullscreen mode

Never post:

passwords
tokens
private keys
wallet seeds
private endpoints
personal data
Enter fullscreen mode Exit fullscreen mode

Step 5 — Define the evidence boundary

Every contribution should answer:

If this test passes, what exactly can we say?

And equally:

What are we still not allowed to claim?

Example:

TESTED:
HMAC replay protection reproduced.

NOT ESTABLISHED:
production receiver reliability.
Enter fullscreen mode Exit fullscreen mode

That second line is as important as the first.

Step 6 — Run an independent checkpoint

Depending on the project, we can use:

maintainer-run VPS test
isolated Docker environment
read-only bridge
deterministic verifier
synthetic-data run
scoped contributor access
Enter fullscreen mode Exit fullscreen mode

The public external-contributor VPS pilot is here:

https://github.com/MyZubster-Ecosystem/myzubster/issues/1518

A successful pilot may later connect to:

Contributor Passport
Knowledge Graph
project/pilot relationships
public technical evidence
future scoped VPS tests
Enter fullscreen mode Exit fullscreen mode

A verifier should be boring

One architectural principle emerged very clearly today.

Verifier scripts should be boring.

A good verifier should mostly do:

read source
check immutable provenance
run command
capture result
compare expected vs actual
emit structured JSON
Enter fullscreen mode Exit fullscreen mode

Not:

guess
summarize creatively
reinterpret evidence
promote status automatically
Enter fullscreen mode Exit fullscreen mode

For example, the output shape can be as simple as:

{
  "contributor": "example-user",
  "source_pr": "#123",
  "source_commit": "abc123...",
  "scope": "bounded regression test",
  "checks": {
    "case_a": true,
    "case_b": true
  },
  "status": "TESTED",
  "boundary": "This does not establish production deployment."
}
Enter fullscreen mode Exit fullscreen mode

That structure can later feed:

Contributor Passport
Knowledge Graph
Zorgax
project dashboards
public evidence pages
Enter fullscreen mode Exit fullscreen mode

without requiring an LLM to invent the status.

AI should discover evidence, not rewrite reality

Zorgax and vector search are part of MyZubster.

But our recent contributor work reinforced an important rule:

AI should help discover and explain evidence. It should not silently redefine authoritative evidence.

We therefore separate:

semantic discovery
Enter fullscreen mode Exit fullscreen mode

from:

deterministic identity / state / provenance lookup
Enter fullscreen mode Exit fullscreen mode

When a field already exists as structured metadata:

status = SUPPORTED
commit = abc123
knowledgeCardId = KC-001
Enter fullscreen mode Exit fullscreen mode

we should not ask an LLM to reconstruct those values from prose.

This is especially important once many contributors share the same knowledge infrastructure.

Decentralization starts before consensus

There is a tendency to talk about decentralization only in terms of blockchains, consensus protocols and fully distributed networks.

Those technologies can matter.

But there is an earlier problem to solve.

Can independent people maintain ownership of their work?

Can somebody else verify it?

Can provenance survive integration?

Can a central project avoid rewriting contributor history?

Can a failed test stay failed?

Can an unmerged commit still have an accurately described reproducibility checkpoint?

Can structured evidence retain its original state after passing through AI?

Those are decentralization problems too.

For us, the current progression looks like:

central repository
      ↓
external contributors
      ↓
contributor-owned source history
      ↓
independent reproducibility
      ↓
controlled VPS interoperability
      ↓
contributor-specific verifier nodes
      ↓
Contributor Passport / Knowledge Graph
      ↓
direct contributor-to-contributor bridges
      ↓
more independent nodes
      ↓
federated / P2P experimentation
Enter fullscreen mode Exit fullscreen mode

We are somewhere in the middle of that path.

And that is exactly why this is a good time for more people to join.

What we want contributors to build next

Some useful areas for independent contributors are:

Docker / deployment reproducibility
observability
API integrations
signed webhooks
security regressions
sensor adapters
IoT telemetry
data validation
KPI frameworks
provenance
knowledge tooling
Contributor Passport integrations
RAG retrieval boundaries
Qdrant metadata filtering
privacy controls
Marketplace testing
payment-state correctness
developer documentation
accessibility
Enter fullscreen mode Exit fullscreen mode

You do not need to build a complete MyZubster node.

A narrow, reproducible improvement is enough to enter the graph.

What we will not promise automatically

Contributing code does not automatically imply:

employment
payment
a bounty
VPS shell access
production access
certification
partnership
EU/LIFE endorsement
professional credentials
Enter fullscreen mode Exit fullscreen mode

Payments and bounties require their own explicit agreement and evidence.

VPS access requires its own security scope.

Knowledge publication requires its own consent.

Technical TESTED status applies only to the technical test that actually passed.

These boundaries are intentional.

They protect contributors as much as they protect the project.

The architecture we are aiming for

The long-term picture is not one giant MyZubster server.

It is closer to this:

Contributor A                     Contributor B
own repo                          own repo
own history                       own history
own node                          own verifier
     |                                 |
     +-------------+   +---------------+
                   |   |
                   v   v
              shared evidence
                  contract
                     |
         +-----------+-----------+
         |                       |
         v                       v
   MyZubster node            other node
   verifier / bridge         verifier / bridge
         |                       |
         +-----------+-----------+
                     |
                     v
             Knowledge Graph
                     |
                     v
                  Zorgax
Enter fullscreen mode Exit fullscreen mode

The shared layer is not ownership.

It is interoperability.

Join the experiment

If you have an open-source component that could connect to MyZubster, start small.

Repository:

https://github.com/MyZubster-Ecosystem/myzubster

External Contributor VPS Pilot:

https://github.com/MyZubster-Ecosystem/myzubster/issues/1518

Contributor-to-contributor / N4K48 bridge:

https://github.com/MyZubster-Ecosystem/myzubster/issues/1520

Tell us:

GitHub username
repository / PR
exact commit
what you built
one bounded test objective
how to run it
expected output
resource requirements
what evidence may be public
Enter fullscreen mode Exit fullscreen mode

From there we can work toward:

PROPOSED
→ IMPLEMENTED
→ independently TESTED
→ optionally VERIFIED for reviewed evidence
→ connected to Contributor Passport / Knowledge Graph
Enter fullscreen mode Exit fullscreen mode

Closing thought

The biggest lesson from today was not about Docker, Qdrant, HMAC, Jest or Python.

It was about trust.

A centralized project can simply tell contributors:

“We verified your work.”

A better system can show them exactly:

what was tested
where it came from
which commit was used
which command was executed
what passed
what failed
what the result means
what the result does not mean
Enter fullscreen mode Exit fullscreen mode

That is the direction we want MyZubster to move in.

Not every contributor needs the same machine.

Not every contributor needs the same runtime.

Not every contributor needs the same expertise.

But every interoperability claim should be reproducible, attributable and bounded by evidence.

Decentralization does not start when every contributor runs an identical node.

It starts when no contributor has to trust a central claim about their work because the evidence can be independently reproduced.

If that architecture interests you, contribute a small piece.

We will try to reproduce it.

And if it passes, the evidence should speak for itself.

Top comments (0)