Beyond the Platform: Building MyZubster with Local AI, Independent Nodes, Comics and Verifiable Knowledge

How a collaboration between Daniel Ioni and Nicola (N4K48) is turning an independent software project into an experiment in distributed infrastructure, creative identity and evidence-based knowledge.

Project: MyZubster × N4K48

Authors and collaborators: Daniel Ioni and Nicola / N4K48

Technical checkpoint: October 4, 2026

Status: Working VPS Bridge, tested local software, independent-node integration in progress

Tags: #opensource #decentralization #ai #webdev

---

1. The Internet gave us platforms. What if the next step is giving people their own nodes?

Imagine two developers working together without having to merge their computers, surrender their databases or host every part of their software on the same platform.

One developer operates a server. The other develops an independent application on a personal computer.

They collaborate through a carefully controlled connection. Their applications exchange specific information, while the original software and its data remain under their respective owners' control.

Now imagine connecting that technical collaboration to creative projects, local artificial intelligence, educational progress and verifiable records of what people have actually built.

This is the direction we are exploring with MyZubster.

My name is Daniel Ioni, and I have been working with Nicola, also known as N4K48, to investigate a practical question:

Can an independent creator connect personal software, local AI and creative work to a shared digital ecosystem without giving up control of the original project?

Our answer is not a promise that everything is already decentralized.

It is a growing collection of working components, reproducible tests, documented limitations and increasingly ambitious experiments.

This article explains what we have built, what we have verified and what we intend to develop next.

2. Meet Nicola: an independent developer building his own software

Nicola did not join this experiment with an empty project.

He has been developing N4K48 / MyZubster MVP, an independent software prototype centered on an important principle:

Evidence first. AI second.

Instead of allowing an AI model to invent authoritative answers, the application maintains structured information that can be retrieved, inspected and used as the basis for responses.

Its architecture includes several components:

• A Python API and a Docker-based local environment.
• Persistent observations and local records.
• An internal ledger for recording and examining events.
• Economic simulations, explicitly separated from real financial activity.
• A local retrieval-augmented generation system using Qdrant and Ollama.
• An integration layer involving Zorgax, the MyZubster AI assistant.
• A catalog documenting Nicola's creative work.

The project has reached a publicly documented experimental release candidate, v0.1.0-rc2. It can be studied and run locally, but it is not presented as production-ready software.

This distinction matters.

A successful prototype demonstrates that a concept can work under defined conditions. It does not automatically demonstrate reliability, security, scalability or suitability for every user.

Explore Nicola's independent MVP

Why local AI matters

Many AI applications assume that the user's information must travel to an external provider.

We are interested in another possibility.

With local AI, the creator can retain the underlying data within their own environment and decide which capabilities or results to share.

Nicola's application uses Qdrant for vector retrieval and Ollama for local model execution. Its evidence-first approach distinguishes exact records from semantic search results.

An exact observation should not be replaced by a plausible AI-generated interpretation when the original evidence is already available.

This is an essential foundation for any future system that intends to connect knowledge, reputation, education or economic participation.

3. From software to a character: N4K48 enters MyZubster

A software project can be explained through documentation.

But can it also be understood through a story?

Nicola has created a visual identity, N4K48, and connected his technical journey to the cyberpunk-inspired creative world of MyZubster.

The narrative begins in Neon Plaza, a fictional environment representing entry into a larger digital ecosystem.

The project currently includes four published illustrated chapters:

1. Dall'idea software al metaverso — From a software idea to the metaverse.
2. Il software prende forma — The software takes shape.
3. Verso Neon Plaza — Towards Neon Plaza.
4. Il ponte da costruire — The bridge to be built.

These chapters connect creative storytelling to actual stages of the development process.

The fourth chapter is especially relevant.

It depicts the challenge of creating a connection between Nicola's independent application and the MyZubster infrastructure.

When it was documented, the complete authenticated connection had not yet been verified. That limitation became part of the story rather than something to hide.

This is the relationship we want to develop between technical evidence and creative expression.

A comic can illustrate a milestone, describe an unresolved problem or introduce an ambitious idea.

But an illustration is not evidence that the depicted technology already exists.

Likewise, Neon Plaza currently represents a creative direction and an evolving concept. It should not be confused with a fully operational, production-ready 3D metaverse.

Read the complete N4K48 comic series

4. Creativity, provenance and the future of digital ownership

Our work also raises an important question:

How can a creator document where a digital work came from, who contributed to it and what permissions apply?

Nicola's comic catalog uses structured metadata and links its assets to identifiable Git repository versions.

This allows readers and collaborators to inspect the project's recorded provenance.

However, provenance, copyright ownership and blockchain registration are three different things.

The first N4K48 comic, Dall'idea software al metaverso, is identified in the project manifest as an NFT_CANDIDATE and PROPOSED_FOR_REVIEW.

That is a proposal for future evaluation.

It does not mean that an NFT has already been minted.

The project's metadata also explicitly records that some rights and permissions still require verification.

We believe this separation is fundamental to responsible digital creativity.

An asset should not acquire an unsupported claim of ownership merely because someone has generated an image, uploaded it to a repository or written metadata describing it.

Our longer-term objective is to establish a transparent chain connecting creative direction, source material, documented permissions, development history and any future authorized publication.

Inspect the comics manifest and provenance metadata

5. The technical challenge: connecting two independent computers

The next part of our collaboration is the Node Bridge.

We operate a VPS running Ubuntu. Nicola develops and tests his application on a separate Windows computer using Docker.

The challenge is to exchange selected information without publishing his entire local API on the open Internet.

We designed a small, permission-controlled Bridge for this purpose.

Its architecture is deliberately straightforward.

              MYZUBSTER VPS
        ┌──────────────────────────┐
        │ Public HTTPS endpoint    │
        │ bridge.myzubster.com     │
        │            │             │
        │          Nginx           │
        │            │             │
        │  Node Bridge broker      │
        │  Local Docker container  │
        └────────────┬─────────────┘
                     │
           Authenticated HTTPS
             Outbound polling
                     │
        ┌────────────▼─────────────┐
        │ NICOLA'S COMPUTER        │
        │                          │
        │ Python Bridge agent      │
        │            │             │
        │     Local Zorgax API     │
        │     127.0.0.1:5000       │
        │            │             │
        │  Nicola's comics catalog │
        └──────────────────────────┘

The VPS provides a coordination point.

Nicola's agent initiates the connection.

His local application processes an authorized request.

The response travels back to the broker.

Under this design, Nicola does not need to expose his local catalog directly to the public Internet.

How the request flows

A typical authorized request follows six steps:

1. An administrator submits a permitted operation to the broker using a private administrative interface.
2. The broker places the request in a temporary queue.
3. Nicola's agent checks the broker periodically over HTTPS.
4. The broker assigns an available request to the agent.
5. The agent asks Nicola's local application to process it and returns a limited result.
6. The administrator retrieves the result from the broker.

The initial scope is deliberately narrow.

The Bridge supports selected read-only comic catalog operations rather than unrestricted access to Nicola's computer.

This is an important security decision: a connection between independent systems should grant only the capabilities required for the collaboration.

Why outbound connections?

Requiring every independent participant to open inbound network ports creates additional configuration and security challenges.

Outbound polling offers a practical starting point.

It allows a participant behind a typical home router or firewall to contact the public broker without exposing the participant's local development API.

This architecture also gives each participant a clear choice: start the agent to participate, or stop it to disconnect.

It does not, by itself, provide anonymity, eliminate every trust dependency or guarantee that the local application is secure.

6. What we have actually built and verified on the VPS

By October 4, 2026, we had progressed from an initial Node Bridge pilot to a tested and updated Docker deployment.

Our production broker runs inside a dedicated container.

Docker publishes its application port only on the VPS loopback interface, while Nginx provides the controlled public HTTPS entry point.

This separates the internal service from the Internet-facing reverse proxy.

We have verified the following controls:

Verification	Observed result
Local broker health endpoint	HTTP 200
Public node endpoint without credentials	HTTP 401
Public administrative endpoint	HTTP 403
Authenticated node request over HTTPS	HTTP 200
Updated Docker container health	Healthy
Unexpected container restarts after deployment	0
New node credential	Accepted
Previous node credential	Rejected

We also added per-client request-rate limits at the Nginx layer.

The rules are loaded, although a controlled test of the exact HTTP 429 threshold remains separate from these checks.

The implementation uses two distinct authentication credentials: one for the node and another for administrative operations.

Following the deployment, we rotated both credentials and verified that the previous node credential was no longer accepted.

We did not publish credentials, copy the production environment file into our source repository or include tokens in the agent distribution package.

A real bug we discovered: stale job results

One of the most valuable discoveries came from testing job reassignment.

Our initial broker used temporary job leases. If an assigned agent failed to complete its work before a lease expired, the broker could make the job available again.

That behavior is useful for recovering from disconnected agents.

But it revealed a problem.

An agent holding an expired lease could potentially submit an old result after the request had already been reassigned.

A stale response should never be mistaken for the result of the current assignment.

We reproduced this failure and corrected it by introducing a unique identifier for every lease.

The broker now requires the correct current lease_id when accepting a result.

The tests verify that outdated lease results are rejected, expired leases cannot submit results and duplicate submissions cannot overwrite a completed request.

This is a practical example of why decentralization-related engineering cannot be reduced to connecting two APIs.

Correctness depends on what happens during disconnections, delays, retries and conflicting responses.

Our test strategy

We used several layers of verification.

First, we tested the broker's basic behavior and authentication.

Second, we introduced an integration test combining the actual broker and agent with a simulated local catalog.

Third, we added regression tests for expired, reassigned and replayed leases.

Across these source-level checks, seven automated tests passed.

We then built the corrected application as a separate Docker image, without interrupting the existing production container.

A second broker ran on an isolated local port using fictional credentials. Its integration test verified the complete simulated flow, from request creation to agent processing and result retrieval.

Only after that test succeeded did we update the production container.

We retained the previous Docker image as a recovery option.

The production deployment now runs the corrected broker.

Our verified source checkpoint for this change is:

b1b38c151548ea18e88dc8f7e3a2efd31e038692

The updated agent was also transferred as a credentials-free ZIP package and independently checked after extraction on Windows.

Its SHA-256 digest is:

79ae718b1b9aad714fe7521e77bd2b5c9c3c2ff0ce248f0d7b03b3db67f5ea34

The next milestone is to establish the full authenticated connection to Nicola's real computer.

We have verified the deployment and simulated end-to-end behavior. We have not yet claimed successful production communication with Nicola's independent node.

7. Where Tor fits into the bigger picture

Our VPS is part of a broader infrastructure environment that includes experiments and services involving Tor.

That raises an interesting architectural question:

Can we provide multiple communication paths for a distributed ecosystem, allowing participants to choose the transport appropriate for their circumstances?

Tor's onion services offer one possible component of that strategy.

Unlike an ordinary public website, an onion service can be reached through the Tor network without publishing the service's underlying IP address to its clients.

Tor establishes a private introduction-and-rendezvous process for reaching an onion service.

This is valuable for applications that prioritize privacy, location protection or resilience against certain network restrictions.

It is important, however, not to confuse three different concepts:

HTTPS: encrypts a connection to an authenticated web endpoint.

Tor: provides network-level privacy properties through its routing architecture.

Decentralization: concerns how control, authority, storage, coordination and failure dependencies are distributed.

One does not automatically imply the others.

Our currently verified Node Bridge uses a conventional public HTTPS endpoint.

Although Tor is part of the broader VPS environment, we are not claiming that the tested Bridge traffic currently travels through Tor or that a dedicated onion endpoint for Nicola has been validated.

A future phase could evaluate a separately configured onion transport, authenticated access and alternative routes.

Such work would require additional tests, operational safeguards and a clear threat model.

Tor is not a replacement for authorization, safe application design or a careful decision about which information should be shared.

Our aim is to explore Tor as one possible infrastructure layer, not to use the word as a substitute for security evidence.

For readers interested in the underlying technology, the Tor Project's onion-service documentation explains its introduction points, rendezvous protocol and privacy properties.

8. Is MyZubster fully decentralized today?

No.

That answer is central to the credibility of this project.

Our current architecture has independent software environments, but the Node Bridge still depends on a central VPS broker.

If that broker becomes unavailable, the present coordination path becomes unavailable too.

The broker is also an important trust boundary because it authorizes requests and mediates the exchange.

A fully decentralized or substantially more resilient future architecture would need to examine several additional problems:

• Independent broker operation and alternative communication routes.
• Node identity and individual authorization rather than shared credentials.
• Cryptographic verification of messages and their origin.
• Discovery, consent and revocation between independent participants.
• Persistent queues and reliable recovery after failures.
• Data minimization and privacy-preserving logging.
• Replication and resilience without introducing uncontrolled access.
• Independent, reproducible tests performed by external contributors.

We are starting with a distributed pilot because real-world decentralization requires solving these underlying problems.

Calling an architecture decentralized before demonstrating the relevant properties would undermine the evidence-first philosophy on which the project is being built.

9. Knowledge should leave a verifiable trail

The collaboration with Nicola has another dimension beyond infrastructure.

What if we could document not only the final product, but also the knowledge acquired during its construction?

Traditional online profiles often present skills as unverified declarations.

A repository can show code, but a commit alone does not establish everything about the knowledge that produced it.

We want to connect several complementary kinds of evidence:

• A human-readable description of the work.
• The source files and revisions associated with it.
• Reproducible test procedures and observed results.
• A record of the participants and their stated contributions.
• Cryptographic digests linking evidence to a specific documented version.
• Explicit review, consent and acknowledgment where appropriate.

This forms the basis for the MyZubster knowledge-transfer experiment.

Nicola's public repository already documents a knowledge-transfer snapshot connected to MyZubster.

Its canonical manifest has a recorded SHA-256 commitment, with a documented match against an anchor on the Base Sepolia test network.

This is a useful cryptographic property: the evidence package can be compared with the commitment registered at a particular point in time.

But we must be precise.

A blockchain hash proves neither the truth of every statement nor that a particular individual mastered a skill.

It provides a way to establish the integrity and recorded existence of the committed material.

The human meaning of that material still depends on the underlying evidence, transparent attribution and appropriate acknowledgment.

Explore the documented knowledge-transfer record

Inspect the published Base Sepolia transaction

Turning this article into a knowledge artifact

This article is intended to become part of that process.

Our goal is to preserve a snapshot containing the article, its publication reference, the technical checkpoints, the available test evidence and a description of each participant's contributions.

We can then construct a canonical evidence manifest and compute its cryptographic digest.

If that manifest is subsequently recorded through the MyZubster knowledge-proof process, readers will be able to compare the published material with the committed evidence.

The article's publication must come first. We should not invent a publication URL or blockchain transaction before either exists.

We also want Nicola to review the description of his work and explicitly acknowledge any contribution claims attributed to him.

This is a practical form of knowledge provenance: a record that can evolve, receive corrections and be examined independently.

10. What changes when creators can bring their own infrastructure?

Our experiment is small, but the underlying architectural idea has broader implications.

Imagine a future in which independent developers can participate in a shared ecosystem without first moving all their data and applications into a single central service.

A creator could maintain a personal catalog.

A research group could retain its own datasets.

An educator could publish verifiable learning materials.

A local AI assistant could process information without automatically transferring every underlying record to an external provider.

An organization could choose which capabilities it makes available to others through a limited, revocable interface.

Creative work and technical achievements could be connected through documented evidence without pretending that every creative asset automatically becomes a token or that every record automatically establishes ownership.

The potential change is not simply technological.

It is about allowing cooperation without requiring total centralization.

That future would also introduce serious challenges: interoperability, governance, abuse prevention, reliability, accessibility, privacy and sustainable maintenance.

We do not expect one VPS, one blockchain or one protocol to solve all of them.

But working examples help us identify which problems must be solved next.

11. Our immediate roadmap

Our next milestone is deliberately concrete.

Nicola will verify the distributed agent package, confirm that his local application is functioning and prepare his Windows environment.

The new node credential will be provided through a separate private channel.

We will then perform the first live authenticated exchange between the VPS and Nicola's independent application.

That experiment must demonstrate more than a successful health check.

We intend to document the request, the permitted operation, the actual local processing, the returned result and the relevant timestamps, without exposing credentials or private information.

We also intend to test interruption, reconnection and credential revocation.

The results will determine what we can legitimately claim about the completed pilot.

After that, our development priorities include improving node-specific authorization, operational resilience, public reproducibility and further evaluation of privacy-oriented communication routes.

We will publish the successful results and any relevant limitations in a dedicated follow-up article.

This first chapter documents what exists today. The next chapter will document what the independent-node experiment actually proves.

12. A different kind of collaboration

The most meaningful aspect of this project is not any individual piece of technology.

It is the connection between people, their work and evidence that other people can inspect.

Nicola brings his own software, experimentation and creative direction.

MyZubster provides an evolving ecosystem in which independent contributions can potentially interact without losing their identity.

Our collaboration has already produced a local software prototype, documented tests, creative storytelling, provenance records and a working coordination service.

It has also produced failures, debugging sessions and corrections.

Those difficulties deserve to be included in the story.

We believe the next generation of digital ecosystems should provide more opportunities for people to learn in public, retain ownership of their independent work, exchange carefully defined capabilities and build on evidence instead of unsupported promises.

We are not claiming that tomorrow's Internet has already arrived.

We are building and testing some of the components that might help shape it.

And we are leaving a verifiable record of the process.

---

Explore the project

• MyZubster — main open-source ecosystem
• Nicola / N4K48 — independent MVP
• N4K48 comic gallery
• Nicola Comics provenance manifest
• N4K48 public pilot test evidence
• Evidence-first RAG development
• Knowledge-transfer record

A note on evidence: The VPS deployment results reported here come from our October 4 operational tests. The standalone Bridge release repository and its full reproducible test evidence should be published and linked once the source and security review is complete. Nicola's public repository provides separate evidence for his own software and creative work. The authenticated exchange between our two actual computers remains the next milestone.

If you're working on local-first software, distributed systems, verifiable learning or independent creative infrastructure, these are the kinds of engineering and governance questions we believe are worth exploring together.