Building Evidence-First Contributor Interoperability with VPS Checkpoints, GitHub Provenance and Independent Verifiers
Open-source projects are good at collecting contributions.
They are much less good at answering a harder question:
Can somebody independently reproduce what a contributor actually built?
A merged pull request tells us that code entered a repository.
It does not automatically tell us:
- which exact contributor commit was independently tested;
- whether that behavior still works on the current codebase;
- what environment was used;
- what was expected;
- what actually happened;
- what failed;
- and what the result does not prove.
At MyZubster, we have been experimenting with a contributor model built around evidence-first interoperability.
Instead of treating every external contribution as something that simply disappears into the main repository, we are trying to preserve the contributor's provenance and connect their work to reproducible technical checkpoints.
Today we pushed that model further by connecting multiple contributors through GitHub, contributor-specific verifier scripts and an independent VPS execution environment.
The result is not full P2P decentralization yet.
But it is a concrete step toward a network where contributors can own their code while sharing a common verification protocol.
The core idea
Our current contributor flow looks like this:
Contributor
↓
Public repository / pull request
↓
Immutable commit SHA
↓
Contributor-specific verifier
↓
Independent VPS execution
↓
Expected vs actual result
↓
Structured evidence
↓
TESTED checkpoint
Different contributors may use:
Node.js
Python
Docker
Qdrant
Ollama
Jest
webhooks
policy engines
research artifacts
KPI frameworks
They do not need the same runtime.
They need the same evidence discipline.
That distinction matters.
Git history is part of the evidence
Branches are convenient for development.
They are not ideal as evidence anchors because they move.
So when we verify a contribution we prefer to record:
GitHub username
repository
pull request
contributor commit
merge commit, if applicable
verifier commit
test objective
expected result
actual result
limitations
That gives us an immutable checkpoint.
Instead of saying:
This feature was tested.
we can say:
This exact contribution, from this exact commit, was reproduced under these exact conditions.
That is much more useful.
Why use a VPS?
We currently use a MyZubster VPS as an independent technical reproduction environment.
It is important to describe what that means correctly.
The VPS is not:
unrestricted contributor access
production control
shared root access
security certification
automatic bounty approval
It is a controlled execution environment.
Depending on the contribution, we can:
- clone the public repository;
- check out an exact branch or commit;
- run a bounded verifier;
- use synthetic fixtures;
- run a Docker stack;
- collect sanitized output;
- compare expected and observed behavior.
In some cases direct contributor VPS access may eventually be appropriate.
In others, a maintainer-run test is safer and more reproducible.
Our public contributor VPS pilot is tracked here:
https://github.com/MyZubster-Ecosystem/myzubster/issues/1518
The rules include:
least privilege
time-limited access
no public secrets
explicit scope
synthetic or authorized data
rollback expectations
reproducible commands
Contributor checkpoint 1: N4K48 as an independent Docker node
One of our earliest practical contributor-node experiments was Nicola / N4K48.
The external project runs independently from the MyZubster core repository.
We reproduced a specific contributor checkpoint:
repository:
nicolaususnicola-lgtm/myzubster-mvp
commit:
87a1021
The environment included:
Docker
MyZubster API
Qdrant
Ollama
Open WebUI
nomic-embed-text
Zorgax
We checked bounded behaviors such as:
container startup
API health
observation retrieval
read-only contributor flows
semantic retrieval
That produced a technical:
TESTED
checkpoint for the independent reproduction.
It did not mean:
full P2P established
production deployment certified
commercial settlement proven
The distinction between what passed and what remains unproven is part of the evidence itself.
Contributor checkpoint 2: Open Period Care
Open Period Care presented a completely different type of contribution.
Instead of a standalone runtime, the contribution contained structured research and evidence artifacts.
Two example Knowledge Cards were:
KC-OPC-001
Multi-Layer Biomaterial Architecture for Reusable Textile Absorbents
SUPPORTED
and:
KC-OPC-002
Contributor Privacy, Data Minimization & Clinical Boundaries
SUPPORTED
Notice the status:
SUPPORTED
That state belongs to the research content.
Running a successful software integration did not magically change it to TESTED.
What became TESTED was the technical bridge that retrieves and scopes the contributor evidence.
The read-only bridge was merged through:
https://github.com/MyZubster-Ecosystem/myzubster/pull/1511
Merge SHA:
6061140f4ade01ab10211b2a6698cac03f326e55
This separation between:
technical interoperability
and:
research/evidence status
is one of the most important parts of the architecture.
Semantic search is not identity
During the Open Period Care work we hit a useful retrieval failure.
A semantic query over a shared Qdrant collection returned the wrong contributor record.
The vector search was doing what vector search does:
find semantically similar content
But we were asking it to do something stricter:
identify the authoritative record
Those are not the same problem.
We now separate:
semantic/vector retrieval
→ discovery
from:
deterministic metadata lookup
→ authoritative IDs
→ status
→ provenance
→ contributor scope
For example:
bridge = open-period-care
knowledgeCardId = KC-OPC-001
is a much stronger lookup constraint than:
"find something similar to this card"
The general lesson is simple:
Embeddings are excellent for finding candidates. Structured metadata should decide identity.
Contributor checkpoint 3: Shweta and an unmerged commit
Shweta-singh24 gave us another interesting case.
The contribution we wanted to verify came from a pull request that had been closed without merging.
That does not make the code disappear.
It simply changes the claim we are allowed to make.
We reproduced the exact contributor commit:
82461433e0c5bfee9aa369b4a71e9331261cf803
The bounded policy checks covered behavior such as:
GLOBAL → ALLOW
HK → ALLOW
CN_MAINLAND → DENY
plus fail-closed behavior for unknown policy values.
The verifier bridge was merged through:
https://github.com/MyZubster-Ecosystem/myzubster/pull/1509
Merge SHA:
aa54fd380e487c11ba39fb40a092212f412cf364
The evidence therefore says:
TESTED — exact closed/unmerged contributor checkpoint
It does not say:
merged upstream
deployed
legally approved
This is exactly why immutable provenance matters.
Contributor checkpoint 4: wasim-builds
wasim-builds contributed explicit regression coverage for fail-closed admin authentication.
Original contribution:
https://github.com/MyZubster-Ecosystem/myzubster/pull/860
Contributor commit:
d378adbbd9690cfbac081758000bb95d64fe7fb1
The independent VPS verifier reran four bounded behaviors:
ADMIN_API_KEY not configured → 503
missing admin key → 401
incorrect admin key → 401
correct admin key → 200
Result:
4 / 4 PASS
The verifier was merged through:
https://github.com/MyZubster-Ecosystem/myzubster/pull/1523
Merge SHA:
a0faab53f817c3c6379d3ccaaad5d3fac3b6fb1b
Contributor checkpoint:
TESTED — fail-closed admin-auth regression
This is not a security certification.
It is an independent reproduction of four defined security regression cases.
That boundary matters.
Contributor checkpoint 5: Aming9303
Aming9303 contributed signed payment lifecycle webhooks.
Original PR:
https://github.com/MyZubster-Ecosystem/myzubster/pull/891
Contributor commit:
cee464b6a69e621442b30a57d2d56933988827e2
The contribution included:
HMAC-SHA256 signatures
delivery IDs
retry behavior
timestamp windows
replay protection
constant-time signature comparison
We created a targeted VPS verifier for five behaviors:
1. signed event has correct HMAC
2. retry preserves the delivery ID
3. endpoint without secret is rejected
4. replayed delivery ID is rejected
5. stale event is rejected before replay claim
Result:
5 / 5 PASS
The verifier was merged through:
https://github.com/MyZubster-Ecosystem/myzubster/pull/1524
Merge SHA:
1154a87d27332a779e86d11e4b7952c22099d533
Checkpoint:
TESTED — signed payment-webhook regression
Again, this does not imply that every production webhook receiver is reliable.
It proves the tested contract.
Contributor checkpoint 6: foxxx009
foxxx009 contributed a KPI, baseline and evidence/provenance framework.
Original PR:
https://github.com/MyZubster-Ecosystem/myzubster/pull/894
Contributor commit:
70cb32c6500525df4056859525fe215b95188a02
This verifier was especially useful because it needed to check more than code execution.
We tested:
3 baseline records
2 pilot records
11 KPI outputs
evidence references
JSON output
Markdown output
missing-data handling
synthetic-data disclaimers
anti-overclaim behavior
One KPI uses a documented:
ratio-of-totals
aggregation.
The expected value was:
(3222.5 + 3098.7) / (9.95 + 9.51)
which equals:
324.83042137718394
The independently observed value was:
324.83042137718394
Exact match.
The verifier failed twice
And this is where the process became interesting.
The first run failed because our verifier tried to install pytest.
The VPS had Python 3 but no pip.
Result:
FAILED
But that was not a contributor failure.
It was a verifier dependency failure.
So we removed the dependency.
The verifier became:
Python 3
+
standard library
+
repository modules
The second run failed because our expected KPI formula was wrong.
We had calculated:
average of ratios
while the contributor implementation correctly used:
ratio-of-totals
Our verifier was wrong.
Not the contributor.
We corrected the expectation and reran.
Final result:
TESTED
The verifier was merged through:
https://github.com/MyZubster-Ecosystem/myzubster/pull/1525
Merge SHA:
f0c477f563ab7e92a734b3042d44063794b7f81f
This reinforced a rule we want to keep:
A failed verifier run is evidence too.
Do not rewrite it into success.
Find out what actually failed.
Why a verifier should be intentionally boring
A good verifier should avoid cleverness.
Its job should be something like:
read known source
check provenance
run deterministic operation
compare result
emit JSON
For example:
{
"contributor": "example-user",
"source_commit": "abc123",
"scope": "bounded webhook regression",
"checks": {
"valid_signature": true,
"invalid_signature": true,
"replay_rejected": true
},
"status": "TESTED",
"boundary": "Production delivery reliability was not tested."
}
That output can later feed:
Contributor Passport
Knowledge Graph
Zorgax
public evidence pages
project dashboards
without requiring an AI model to invent the underlying state.
What we mean by decentralization
We are deliberately careful with this word.
Today MyZubster is not claiming:
fully decentralized production
permissionless VPS access
distributed consensus
fully federated execution
complete direct P2P contributor communication
What we have demonstrated is something earlier and more practical:
Decentralized provenance
Contributors retain public ownership of their own:
GitHub identity
repository
commit history
artifact
technical evidence
Independent reproducibility
A central maintainer does not have to be the only authority saying:
This contributor's work works.
A third environment can rerun the checkpoint.
Interoperability through evidence
Different contributors can use different architectures while speaking a common evidence language.
That gives us:
different code
different runtime
different domain
different repository
↓
shared verification contract
That is the decentralization layer we are currently building.
Contributor-to-contributor links come next
We have also opened an opt-in contributor bridge around the N4K48 node:
https://github.com/MyZubster-Ecosystem/myzubster/issues/1520
The intended state machine is:
PROPOSED / CONSENT PENDING
↓
OPTED IN
↓
APPROVED BY BOTH SIDES
↓
TEST PLAN AGREED
↓
TESTED
↓
VERIFIED
This is important because similar interests do not automatically create collaboration.
A graph edge should not imply consent.
A shared technology stack should not imply partnership.
Contributor-to-contributor interoperability should also be evidence-based.
How to join MyZubster as a contributor
You do not need to build an entire platform.
A useful contribution can be small.
Examples include:
bug fix
test suite
Docker setup
sensor adapter
webhook
API integration
security regression
dataset validator
KPI function
evidence schema
documentation
accessibility improvement
reproducible deployment
privacy control
RAG retrieval improvement
Qdrant metadata strategy
The main repository is:
https://github.com/MyZubster-Ecosystem/myzubster
A practical contributor workflow is:
1. Build something narrow
A contribution should ideally solve one clear problem.
A 20-line reproducible fix can be more valuable than a huge branch nobody can evaluate.
2. Publish the source
Give us:
GitHub username
repository
branch
pull request
commit SHA
The commit SHA is especially important.
3. Define the test contract
Bad:
Check whether my project works.
Good:
Run command X.
Input:
fixture Y.
Expected:
HTTP 401.
Negative case:
invalid token must not reach protected route.
The narrower the test contract, the easier independent reproduction becomes.
4. List dependencies
Document:
runtime
minimum CPU/RAM
ports
environment variable names
network requirements
startup command
test command
cleanup command
Never publish:
passwords
tokens
wallet seeds
private keys
personal information
private infrastructure addresses
5. Define what success means
Every verifier should have an explicit boundary.
Example:
TESTED:
delivery replay protection reproduced.
NOT ESTABLISHED:
production payment settlement.
This prevents successful technical tests from becoming exaggerated project claims.
6. Run the independent checkpoint
Depending on the contribution, we may use:
Docker
maintainer-run VPS execution
read-only integration
synthetic fixtures
zero-dependency verifier
scoped contributor VPS access
Our external contributor pilot is here:
https://github.com/MyZubster-Ecosystem/myzubster/issues/1518
What successful contribution can connect to
A useful independently reproduced contribution may later be connected to:
Contributor Passport
Knowledge Graph
related projects
related contributors
public evidence records
scoped VPS experiments
university/research demonstrations
future agreed bounties
But those are separate state transitions.
A technical test does not automatically mean payment.
A merge does not automatically mean deployment.
A graph connection does not automatically mean partnership.
This is intentional.
A note about AI
MyZubster also uses AI and semantic search.
That makes provenance even more important.
An LLM should help us:
discover
summarize
explain
compare
navigate
It should not silently change:
commit IDs
structured statuses
evidence states
authorship
verification results
If the metadata says:
status = SUPPORTED
the AI should not decide:
status = VERIFIED
because the text sounds convincing.
Structured evidence should stay authoritative.
The architecture we are working toward
Long term, we imagine something closer to this:
Contributor A Contributor B
| |
v v
own repo own repo
own node own service
own evidence own evidence
| |
+------------+-------------+
|
v
common evidence protocol
|
+----------+----------+
| |
v v
MyZubster verifier contributor verifier
| |
+----------+----------+
|
v
Knowledge Graph
|
v
Zorgax
The shared layer is not central ownership.
It is interoperability.
Lessons from today's work
A few practical lessons became very clear.
1. Immutable commits beat moving branches
A branch is for development.
A SHA is for evidence.
2. FAILED must remain meaningful
Do not hide failed runs.
Investigate them.
3. A verifier can be wrong
Independent validation applies to our own assumptions too.
4. Semantic search is discovery, not identity
Use deterministic metadata for authoritative lookups.
5. TESTED must remain bounded
A passing regression test is not certification.
6. Contributors do not need identical infrastructure
They need interoperable evidence.
Want to contribute?
Start with one small, reproducible artifact.
Repository:
https://github.com/MyZubster-Ecosystem/myzubster
VPS contributor pilot:
https://github.com/MyZubster-Ecosystem/myzubster/issues/1518
Contributor bridge:
https://github.com/MyZubster-Ecosystem/myzubster/issues/1520
When proposing a test, include:
GitHub username
repository / PR
commit SHA
test objective
run command
expected result
dependencies
resource requirements
public evidence you authorize
Then we can try to reproduce it independently.
Final thought
We often describe decentralization in terms of networks and consensus.
But before you can decentralize execution, you need to decentralize trust.
A contributor should not need to rely on a central maintainer saying:
Trust us, we tested your work.
The system should be able to show:
source
author
commit
environment
command
expected result
actual result
limitations
That is the direction we are exploring with MyZubster.
Different people.
Different repositories.
Different technologies.
One reproducible evidence protocol.
And eventually, more independent nodes talking directly to each other.
That is where contributor interoperability starts.
