From a Local MVP to an Independently Operated Node: N4K48 ↔ MyZubster Interoperability Is Now TESTED
Over the last few weeks, I have been working on a question that sounds simple but becomes much more interesting once you try to prove it:
Can an independently operated MyZubster MVP communicate with the wider MyZubster ecosystem without sharing its filesystem, database, or local administrative control?
Today, I can document a concrete answer:
Yes — for a bounded technical interoperability path, this has now been TESTED.
This is not a claim that the architecture is fully decentralized.
It is not yet direct peer-to-peer communication.
It is not a production-readiness or security-certification claim.
What we have instead is something I consider much more useful at this stage of development:
a reproducible technical checkpoint backed by code, hashes, tests, public evidence, and an explicit list of what remains unproven.
Where N4K48 started
My independent development repository is:
N4K48 / MyZubster MVP
https://github.com/nicolaususnicola-lgtm/myzubster-mvp
The wider MyZubster ecosystem is developed here:
MyZubster Ecosystem
https://github.com/MyZubster-Ecosystem/myzubster
My local MVP has gradually evolved into an evidence-first experimental environment combining several components:
- observation and provenance APIs;
- semantic retrieval with Qdrant;
- local AI through Ollama;
- an OpenAI-compatible RAG interface;
- Zorgax read-only interaction;
- a local experimental MYZ ledger;
- economic simulation;
- the Nicola Comics catalog;
- Docker-based service isolation;
- deterministic tests around evidence retrieval.
The principle behind the project has remained simple:
retrieval is not truth, generation is not evidence, and a successful demo is not automatically proof of a larger architectural claim.
That principle became particularly important when we started working on interoperability.
The interoperability challenge
Running software locally is one thing.
Running two environments under different administrative boundaries and proving that they can exchange a bounded job and result is something else.
The tested path is:
MyZubster VPS
→ authenticated Bridge / broker
→ contributor-controlled N4K48 Docker agent
→ local MyZubster catalog
The N4K48 environment remains independently administered.
The Bridge does not receive access to my local filesystem or database.
The agent communicates through a deliberately constrained interface and retrieves the required information from the local catalog API.
That distinction matters.
The objective was not to simulate decentralization by putting several containers on one machine.
The objective was to begin separating administrative control.
The live test
A controlled interoperability test was performed between the MyZubster VPS infrastructure and my N4K48 environment.
The remote Bridge created a bounded gallery job.
My independently running N4K48 agent received it, contacted the local catalog and returned four expected catalog entries.
The observed titles were:
- Dall’idea software al metaverso
- Il software prende forma
- Verso Neon Plaza
- Il ponte da costruire
The result reached the Bridge with:
state: done
Repeated reads during the permitted TTL returned the same result.
After expiration, the Bridge returned:
{"error":"expired"}
That TTL behavior is important because interoperability is not only about obtaining a successful response.
The lifecycle of the response must also behave predictably.
The upstream MyZubster checkpoint is publicly documented here:
https://github.com/MyZubster-Ecosystem/myzubster/pull/1545#issuecomment-6041485188
My detailed N4K48 interoperability record is here:
Verifying the software that actually ran
I did not want the test to depend only on statements such as “the container was running” or “it looked correct.”
The N4K48 agent used for the checkpoint has this SHA-256:
75ab34d21f668fa48383ac7070c717b074c868694c3042928e4532b5ccd34fa1
The hash was verified inside the running Docker container.
The agent ran without publishing network ports.
The local catalog remained behind the contributor-controlled environment.
This gives us a much more precise statement than simply saying two systems were “connected.”
We can identify the artifact that ran and compare it against the expected artifact.
Hardening the node after the interoperability test
Passing the first test created another question:
How should an independently operated node handle its Bridge credential?
The first rule was straightforward:
credentials do not belong in Git.
After the controlled live test, the plaintext token was removed.
The encrypted credential was moved outside the repository.
The test container was stopped.
The host environment variables used for the Bridge session were cleared.
The repository was then checked again to ensure that credential material had not accidentally become an untracked Git artifact.
But I wanted to go further.
Moving the local credential to Windows DPAPI
The N4K48 environment currently runs on Windows with Docker.
For the next local hardening step, I migrated the node token to Windows DPAPI using the CurrentUser protection scope.
The resulting credential is stored outside the Git repository.
The important boundary is:
the repository contains the launcher logic, not the credential.
The DPAPI-protected credential can be decrypted by the appropriate Windows user when the node needs to start.
No plaintext token file needs to live inside the project.
I then built a PowerShell launcher that:
- retrieves the DPAPI-protected credential;
- decrypts it for the current user;
- keeps the plaintext credential in memory;
- starts the N4K48 Docker agent;
- passes the required Bridge configuration;
- verifies the SHA-256 of
/app/agent.py; - clears the host environment variables afterward;
- clears the local byte buffer used for the decrypted credential;
- refuses to create a second agent when one already exists.
This was tested end-to-end.
The resulting node started successfully.
The agent hash matched.
No host port was published.
After startup, the Bridge token, Bridge URL and local catalog configuration were no longer present as environment variables in the parent PowerShell session.
The container was subsequently stopped and, because it runs with --rm, removed automatically.
This is not presented as the final secret-management architecture.
The running Docker container still requires access to its authentication material.
For a future persistent deployment I want explicit credential rotation, revocation and a more complete managed secret lifecycle.
But compared with storing a token in the repository or leaving plaintext credentials on disk, this is a meaningful operational improvement.
Testing the checkpoint
After the lifecycle changes, I reran the tests.
N4K48 Bridge agent tests:
13 / 13 passed
Complete MyZubster MVP test suite:
77 / 77 passed
I also ran Git whitespace/diff validation before creating the checkpoint.
The new checkpoint is:
89ca1b5 — feat: harden N4K48 bridge agent lifecycle
It contains:
bridge/Dockerfilebridge/agent.pybridge/test_agent.pyscripts/start-n4k48-agent.ps1
The checkpoint is available on:
pilot/n4k48-tested-checkpoint
Repository:
https://github.com/nicolaususnicola-lgtm/myzubster-mvp
What has actually been demonstrated?
I think this is the most important section.
Software projects — especially projects involving AI, distributed systems, blockchain or decentralization — can easily move from a successful experiment to claims much larger than the evidence supports.
So here is the boundary.
TESTED
We have tested technical interoperability between:
a MyZubster VPS-side Bridge and an independently administered N4K48 environment.
The test crossed an administrative boundary.
The N4K48 node processed an authenticated remote job.
It retrieved information from its own local environment.
It returned the expected result.
The Bridge observed the result lifecycle through expiration.
The agent artifact was hash-verified.
The implementation has automated tests.
The credential is not stored in the Git repository.
NOT YET PROVEN
This does not prove:
- complete decentralization;
- direct contributor-to-contributor P2P networking;
- elimination of the central Bridge/broker;
- Byzantine fault tolerance;
- production readiness;
- security certification;
- general scientific or clinical validity;
- unrestricted interoperability with every MyZubster contributor.
Those are separate checkpoints.
And they should remain separate until they are actually tested.
Why I think the administrative boundary matters
Docker alone does not make software decentralized.
Running five containers on one administrator's server is still one administrative domain.
For me, the more interesting transition begins when independently controlled environments can communicate using a defined protocol without requiring shared:
- filesystems;
- databases;
- operating-system privileges;
- administrator accounts;
- private infrastructure access.
That is why I consider this interoperability checkpoint important.
It is not the destination.
It is evidence that we can start moving toward it.
The next step: a second independent contributor
The next major checkpoint is intentionally harder.
I want to reproduce interoperability with a second independently administered contributor environment.
The proposed test is consent-gated.
No contributor should be silently enrolled into an experiment simply because their GitHub account appears somewhere in an ecosystem.
Before a second-node test, the participating contributor must explicitly opt in and the test must freeze:
- repository;
- branch;
- commit;
- protocol/fixture version;
- expected result;
- test commands;
- evidence format;
- limitations;
- rollback/stop procedure.
The environment must genuinely be independently administered.
It must not share the N4K48 filesystem, database or administrative privileges.
The proposed second-contributor test plan is public here:
The wider contributor discussion is here:
https://github.com/MyZubster-Ecosystem/myzubster/issues/1520
Only after a reproducible second-node PASS should I describe that checkpoint as tested.
Toward Bridge Protocol v1
There is another problem that becomes visible as soon as a second node enters the picture.
If interoperability depends on undocumented assumptions, it does not scale.
We therefore need to freeze the contract between Bridge and node.
I have started a draft for:
N4K48 Bridge Protocol v1
The current proposal covers concepts including:
- protocol versioning;
- job envelopes;
- job IDs;
- leases;
- actions;
- payloads;
- expiration;
- result envelopes;
- capability negotiation;
- error semantics;
- authentication boundaries;
- conformance fixtures;
- credential lifecycle.
The draft is here:
And the word DRAFT matters.
The exact wire contract still needs joint review and agreement before it should be called a stable protocol.
From interoperability toward federation
My longer-term technical path now looks approximately like this:
Local MVP
→ independently administered N4K48 node
→ authenticated Bridge interoperability — TESTED
→ stable Bridge protocol
→ second independent node
→ cross-node evidence verification
→ redundant delivery routes
→ broker failure testing
→ federation
→ measurable decentralization criteria
This is a slower way to use the word “decentralized.”
I think it is also a more useful one.
Instead of starting with the claim and trying to justify it afterward, I want each architectural property to correspond to an observable test.
If the broker remains a single point of dependency, document it.
If nodes cannot discover each other, document it.
If evidence cannot be independently verified, document it.
If failure recovery has not been tested, document it.
Then build the next experiment.
MyZubster and the evidence-first approach
The wider MyZubster project is available here:
https://github.com/MyZubster-Ecosystem/myzubster
The public repository describes an ecosystem involving evidence and provenance, Zorgax-assisted workflows, participant pilots, community infrastructure and several experimental technical paths.
My N4K48 repository is an independently operated MVP and contributor-side experimentation environment:
https://github.com/nicolaususnicola-lgtm/myzubster-mvp
The relationship I am trying to build between these environments is therefore not “trust everything because it belongs to the same project.”
It is closer to:
produce → identify → exchange → verify → reproduce → then make the claim.
That distinction also matters for AI.
An AI-generated answer is not automatically evidence.
Semantic retrieval is not automatically truth.
A hash proves integrity relative to some bytes; it does not automatically prove that the underlying real-world statement is true.
A blockchain transaction proves that something was recorded according to the properties of that chain; it does not magically validate every semantic claim attached to it.
And a successful distributed-system test proves the bounded behavior that was actually exercised — not every future property of the architecture.
This is the engineering philosophy I want to continue applying to N4K48.
An open invitation to developers
If you work on distributed systems, local-first software, agent interoperability, provenance, verifiable evidence, Docker isolation or decentralized architectures, I would be interested in technical review.
In particular, I would value feedback on:
How should independently administered contributor nodes negotiate capabilities and verify results without turning the central broker into a permanent trust anchor?
That is one of the questions behind the next phase.
You can inspect the code and evidence directly:
N4K48 / MyZubster MVP
https://github.com/nicolaususnicola-lgtm/myzubster-mvp
MyZubster Ecosystem
https://github.com/MyZubster-Ecosystem/myzubster
N4K48 interoperability evidence
https://github.com/nicolaususnicola-lgtm/myzubster-mvp/blob/main/docs/N4K48_INTEROPERABILITY_2026-10-07.md
Public VPS ↔ N4K48 PASS checkpoint
https://github.com/MyZubster-Ecosystem/myzubster/pull/1545#issuecomment-6041485188
Bridge Protocol v1 draft
https://github.com/nicolaususnicola-lgtm/myzubster-mvp/blob/main/docs/N4K48_BRIDGE_PROTOCOL_V1_DRAFT.md
Second contributor interoperability test plan
https://github.com/nicolaususnicola-lgtm/myzubster-mvp/blob/main/docs/SECOND_CONTRIBUTOR_INTEROPERABILITY_TEST_PLAN.md
Contributor interoperability discussion
https://github.com/MyZubster-Ecosystem/myzubster/issues/1520
Final thought
This checkpoint is small compared with the architecture I ultimately want to test.
But it is real.
A remote authenticated job crossed from the MyZubster infrastructure into an independently administered N4K48 environment.
The local agent processed it.
The expected catalog result came back.
The lifecycle behaved as expected.
The artifact was hash-verified.
The tests passed.
The credential lifecycle was hardened afterward.
And the remaining limitations are documented rather than hidden.
That is enough for me to call this milestone:
TESTED.
Not “fully decentralized.”
Not “finished.”
Not “production certified.”
Tested. Reproducible. Inspectable. Ready for the next experiment.
And the next experiment is where things become even more interesting:
one Bridge, multiple independently administered nodes — and eventually, no single Bridge that has to be trusted at all.
Top comments (0)