From One Onion Address to a Decentralized MyZubster Network
Today we took another step in the evolution of MyZubster: moving from a single Onion access point toward a model based on multiple independent nodes.
The goal is not simply to create a .onion address.
The goal is to build a network where MyZubster services can remain accessible even when individual nodes disappear, change, or go offline.
The starting point
Our current architecture already has a working Onion Service:
Tor
↓
MyZubster Onion Service
↓
MyZubster Gateway
↓
MyZubster Services
We verified the complete path end-to-end.
Tor reached 100% bootstrap, the Onion Service became reachable, and the request travelled all the way to the MyZubster Gateway and returned HTTP 200.
The current node is therefore more than a concept: it is a working prototype.
The next evolution
The next step is to stop thinking about the Onion Service as a single endpoint.
Instead, imagine multiple MyZubster nodes:
┌── Node A ── Onion ── Gateway
│
Tor Network ────────┼── Node B ── Onion ── Gateway
│
├── Node C ── Onion ── Gateway
│
└── Node D ── Onion ── Gateway
↓
MyZubster Network
Each node could have its own Onion identity and provide its own local services.
That creates a more resilient architecture because the ecosystem no longer has to depend on a single entry point.
Decentralization is more than Tor
This distinction is important.
A Tor Onion Service provides a privacy-oriented way to reach a service through the Tor network.
It does not automatically make the application decentralized.
Real decentralization requires multiple independent nodes, distributed services, and an architecture that does not require one central machine to remain permanently online.
That is where the MyZubster design becomes interesting.
A layered architecture
The long-term architecture can be viewed as four layers:
Onion
↓
Access Layer
Gateway
↓
Service Layer
Metatron / Pytho
↓
Local Intelligence Layer
Blockchain
↓
Coordination & Value Layer
Onion
The Onion layer provides private access to individual MyZubster nodes.
Gateway
The Gateway exposes the actual application services running on that node.
Metatron and Pytho
Metatron is being developed as a local context and knowledge layer.
Pytho remains the AI interaction layer, using local Ollama/Mistral for generation.
The important design principle is separation: local context should not become an authorization layer for payments, deployments, merges, or access to private credentials.
Blockchain
The blockchain layer can provide coordination, ownership and value-transfer mechanisms where appropriate.
Node discovery
A future version of the network could allow nodes to discover other MyZubster nodes.
For example:
Node A
↓
discovers Node B
↓
checks availability
↓
discovers Node C
↓
selects an available service
This opens the door to redundancy and alternative paths.
If one node goes offline, another node could remain available.
Replicated services
Another future step is selective replication.
Not everything needs to be replicated.
Some services can remain completely local to a node.
Other data or application state could be synchronized between trusted nodes.
This allows us to build a system that is distributed without forcing every machine to contain the entire ecosystem.
Autonomous nodes
The long-term vision is a collection of MyZubster nodes that can operate independently while remaining interoperable.
A node could provide:
- its own Onion identity
- its own Gateway
- local databases
- local AI/context services
- selected MyZubster services
- synchronization with other nodes
The network would become a collection of cooperating infrastructure rather than a single server exposed to the Internet.
What we have today
The prototype already demonstrates several important pieces:
MyZubster Gateway ✅
Tor Onion Service ✅
Tor bootstrap 100% ✅
End-to-end Onion test ✅
Pytho AI ✅
Ollama ✅
Mistral ✅
Metatron local context ✅
Dockerized services ✅
We also created a dedicated Onion repository to keep the Tor infrastructure, scripts and documentation separate from the main application.
Where we are going
The evolution can be summarized like this:
Single Gateway
↓
Single Onion Service
↓
Multiple Onion Nodes
↓
Node Discovery
↓
Service Redundancy
↓
Selective Replication
↓
Autonomous MyZubster Network
The .onion address is only the beginning.
The real objective is a network where access, services, intelligence and value can be distributed across independent nodes.
That is the direction we are exploring with MyZubster.
🌱 👽 🧅 🚀
