By Daniel Ioni | MyZubster Ecosystem
In collaboration with Nicola / N4K48
What if the next Internet belonged to its participants?
Most of today's digital experiences follow a familiar model.
We create an account, upload our information, develop our projects and build our identities inside someone else's infrastructure.
Platforms have made collaboration easier, but they have also created dependencies. The tools we use, the information we publish and the communities we build frequently depend on decisions made by centralized service providers.
What would happen if we approached digital collaboration differently?
What if a developer could maintain independent software on a personal computer, use local artificial intelligence and selectively connect to a wider ecosystem without exposing the entire application?
What if artists could document the history of their work, while learners could connect their achievements to inspectable technical evidence?
These questions inspired an ongoing collaboration between myself, Daniel Ioni, and Nicola, an independent developer known as N4K48.
Together, we are exploring this direction through MyZubster.
And our journey has already taken us from local AI and an experimental software product to illustrated storytelling, server infrastructure, distributed communication and cryptographically verifiable knowledge.
This is the story of what we have built so far.
1. Two developers, two independent environments, one shared experiment
Our collaboration started with a simple principle: participation in an ecosystem should not require abandoning your own project.
Nicola has been developing an independent application called N4K48 / MyZubster MVP.
Rather than creating another interface that simply asks an AI model to answer questions, he has been experimenting with structured information, local storage and evidence-based retrieval.
His application combines several technologies and ideas:
- Python APIs and Docker-based development.
- Persistent observations and recorded events.
- Qdrant and Ollama for local artificial intelligence and retrieval-augmented generation.
- An internal ledger and experimental economic simulations.
- A creative catalog connected to his N4K48 identity.
- Integration with Zorgax, the AI assistance concept within MyZubster.
An important principle guides this development:
An AI-generated answer should not replace an authoritative record when that record already exists.
If an application stores an exact observation, it should be capable of retrieving that observation without inventing an alternative version.
This approach becomes increasingly important when AI systems participate in education, research, economic applications or reputation systems.
Nicola's project is available as an experimental open-source MVP, including a public release candidate.
It is not presented as production-ready software.
That distinction is part of our philosophy: development should be documented through actual evidence rather than ambitious claims.
Explore Nicola's independent software on GitHub
2. When software development becomes a comic
Something unexpected happened during our collaboration.
We began connecting Nicola's technical journey to the visual universe of MyZubster.
His digital identity, N4K48, became the protagonist of an illustrated story set in an evolving cyberpunk-inspired world.
Neon Plaza represents a place where independent projects, digital identities and knowledge might eventually meet.
The comic series currently contains four chapters:
Chapter 1: From a Software Idea to the Metaverse
N4K48 begins with an independent software idea and discovers the possibility of connecting it to something larger.
Chapter 2: The Software Takes Shape
The story follows the work of development: authentication, persistent information, experiments and technical verification.
Chapter 3: Towards Neon Plaza
N4K48 approaches the creative vision of a shared digital environment.
Chapter 4: The Bridge to Be Built
The narrative returns to an unresolved engineering challenge: how can independent software establish a secure connection to the MyZubster infrastructure?
This final chapter is particularly meaningful because it connects our creative vision to the technical problem we are currently solving.
The illustrations were produced with AI assistance under Nicola's documented creative direction.
We have also recorded the provenance of the images through repository references and Git metadata. Rights relating to certain external visual elements and potential commercial uses still require verification.
One original N4K48 comic has been proposed as a possible NFT candidate. It has not been presented as an already minted NFT.
For us, creativity and technical documentation should support each other without becoming confused.
A comic can tell the story of an idea.
The corresponding code, tests and development records can show how far that idea has actually progressed.
Discover the N4K48 comic series
3. Building the bridge between two independent computers
We eventually arrived at the most practical question in our collaboration.
How could Nicola connect his locally running software to MyZubster while maintaining control of his own development environment?
We did not want to require him to expose his entire local API to the public Internet.
Instead, we began constructing a limited, authenticated communication bridge.
Our current architecture includes two separate environments.
The first is the MyZubster VPS, running Ubuntu, Docker and Nginx. It hosts a small Node Bridge broker accessible through a controlled HTTPS endpoint.
The second is Nicola's Windows computer, where his application and local catalog run independently.
A lightweight Python agent is designed to initiate an outbound HTTPS connection to the VPS.
When an authorized request becomes available, the agent retrieves it, contacts Nicola's local application and returns an appropriate response.
The important distinction is that the connection originates from the independent node.
Nicola does not have to publish his development API directly to the Internet merely to participate in the experiment.
The initial Bridge supports a deliberately restricted set of catalog operations.
This is a modest architecture, but it addresses a real problem: how to exchange selected capabilities between independently controlled systems.
The bug that changed our implementation
During testing, we discovered a problem with temporary job assignments.
Our broker could reassign a request when an earlier assignment expired. Unfortunately, the original version could still accept an outdated result from the previous assignment.
That created a risk of confusing an old response with the current result.
We reproduced the problem, corrected the assignment protocol and introduced a unique identifier for each lease.
The updated implementation requires the current lease identifier before accepting a result.
Our regression tests now verify rejection of expired, outdated and duplicate submissions.
This experience reinforced an important lesson:
Distributed software must be designed for interruptions, delays and unexpected responses—not just successful connections.
The corrected broker passed our automated tests and a separate Docker integration test using an agent and simulated catalog.
We subsequently deployed the updated Docker image on the VPS, verified its health and rotated its authentication credentials.
The previous node credential was rejected after rotation.
These are concrete achievements.
However, there is still one essential step ahead of us: validating the complete authenticated connection with Nicola's actual Windows computer.
We have prepared and independently verified his updated agent package. The live VPS-to-PC test remains our next milestone.
We prefer to report that distinction clearly rather than describe an unfinished experiment as a completed decentralized network.
4. Where Tor enters our vision
Our infrastructure experiments also involve Tor.
Tor is particularly interesting when discussing independent communication, privacy and alternatives to conventional Internet exposure.
Its onion services can provide access to applications through the Tor network without requiring the underlying service to publish its location to clients.
But Tor and decentralization are not interchangeable concepts.
Tor provides specific network privacy properties.
Decentralization concerns the distribution of control, authority and infrastructure dependencies.
And application security still requires authentication, carefully restricted operations and responsible management of credentials.
Our currently verified Node Bridge operates through conventional HTTPS. We have not yet demonstrated the complete connection over a dedicated Tor onion service.
A potential future direction is to investigate alternative communication routes, including appropriate Tor-based access.
The purpose would be to offer participants more choices regarding how their independently managed nodes connect.
It would not eliminate the need to understand and secure the underlying software.
5. Decentralization is not a switch
There is a temptation to describe any application running on multiple computers as fully decentralized.
We think this oversimplifies the challenge.
Our present system consists of independent environments communicating through a central VPS broker.
That already creates a useful degree of software and data independence.
But the VPS remains a coordination dependency.
If it becomes unavailable, the current communication path stops working.
A more decentralized future will require additional work: independent node identities, alternative brokers, stronger message verification, reliable recovery, consent management and additional communication paths.
These are difficult engineering and governance problems.
We are approaching them incrementally.
Our intention is to develop a system in which independent participants can decide what to share, retain control over their own resources and contribute to a shared ecosystem through well-defined interfaces.
That ambition is larger than our current implementation.
And we believe documenting the distance between an ambition and its demonstrated realization is part of responsible open-source development.
6. The missing piece in digital collaboration: proof of knowledge
There is another question underlying our work.
When two people collaborate, how do they document what was learned and created?
A finished application reveals something about the result.
A Git repository reveals parts of its development history.
Tests provide evidence of particular software behavior.
But the complete human story also includes research, failed experiments, mentoring, decisions, corrections and acquired understanding.
We are exploring ways to connect these elements through MyZubster's knowledge-proof approach.
The objective is to construct inspectable evidence packages containing documentation, source revisions, test results and explicitly acknowledged contributions.
A cryptographic hash can then identify a particular version of that material.
Nicola's repository already documents an earlier knowledge-transfer snapshot associated with a confirmed commitment on the Base Sepolia test network.
This demonstrates an important technical capability: the published evidence package can be checked against a previously recorded cryptographic commitment.
However, a blockchain commitment does not independently certify someone's competence, establish legal authorship or prove that every statement in a document is true.
Those questions require supporting evidence and appropriate human acknowledgment.
We see cryptographic verification as one component of a larger knowledge-provenance system—not as a replacement for critical evaluation.
Explore our documented knowledge-transfer experiment
7. What could this paradigm change tomorrow?
Imagine a world in which participating in a digital ecosystem does not automatically mean surrendering control over your software or data.
Independent developers could connect their applications through limited interfaces.
Artists could associate their work with transparent creation histories.
Students could support their knowledge records with actual projects and test results.
Researchers could share approved findings while retaining control of underlying datasets.
Communities could develop alternative forms of coordination rather than relying entirely on one company's infrastructure.
Local AI could help people work with their own information while reducing unnecessary dependence on remote processing.
These possibilities are compelling.
But they are not inevitable consequences of deploying a blockchain, installing an AI model or connecting a server to Tor.
They require open standards, interoperable implementations, responsible governance and sustained collaboration.
The most important transformation may therefore be cultural rather than purely technical.
Instead of asking people to trust an impressive announcement, we could increasingly provide them with a way to inspect the evidence behind it.
Instead of requiring every creator to abandon an independent project, we could design systems that allow carefully controlled participation.
Instead of treating learning as an invisible process, we could build better records of the work through which knowledge is acquired and shared.
This is the future we want to investigate.
8. Our next milestone
Our immediate goal is not to announce a fully decentralized Internet.
It is much more concrete.
We want to demonstrate a successful round trip between the MyZubster VPS and Nicola's independent application.
A request should originate from our VPS, travel through the authenticated Bridge, be processed by Nicola's local software and return a verifiable result.
After that, we intend to document what happens during interruptions and reconnections, and evaluate the next architectural improvements.
We will then publish a dedicated technical follow-up containing the actual results.
Meanwhile, this article, our earlier technical report and the public development history form part of our evolving knowledge record.
They document not just an idea, but the engineering process through which we are investigating it.
9. One ecosystem, independent creators
I believe the future of the Internet should create more opportunities for people to build together without requiring them to become dependent on the same centralized system.
My collaboration with Nicola demonstrates how this process can begin.
One person develops independent software.
Another maintains shared infrastructure and works on integration.
Artificial intelligence helps organize and retrieve information.
Creative storytelling communicates ideas that technical documentation alone might not convey.
Tests, source history and cryptographic commitments provide different kinds of evidence.
And an unfinished technical challenge becomes the subject of the next experiment.
Our goal is not to remove human collaboration from technology. It is to build technology that makes independent human collaboration more powerful.
That is the direction we are exploring with MyZubster.
The bridge is being built.
The next chapter will show what happens when Nicola's independent node actually crosses it.
Follow the journey
MyZubster ecosystem:
https://github.com/MyZubster-Ecosystem/myzubster
Nicola's independent software:
https://github.com/nicolaususnicola-lgtm/myzubster-mvp
N4K48 comics:
https://github.com/nicolaususnicola-lgtm/myzubster-mvp/tree/main/docs/n4k48-comics
Our detailed technical article on DEV Community:
https://dev.to/danielioni/beyond-the-platform-building-myzubster-with-local-ai-independent-nodes-comics-and-verifiable-kcm
Knowledge-transfer evidence:
https://github.com/nicolaususnicola-lgtm/myzubster-mvp/blob/main/knowledge/KNOWLEDGE-TRANSFER-2026-09-18-DANIEL-NICOLA.md
Technical status: October 4, 2026. This article describes an ongoing experimental project. The updated VPS broker and simulated integration have been verified; the authenticated end-to-end test with Nicola's independent computer is still pending.