The traditional way of deploying an Onion Service is relatively simple:
one service → one node → one Onion address.
That model is useful, but it leaves an important architectural question open:
What happens when the service needs redundancy, multiple deployment locations, or institutional-grade resilience?
This is the direction we are exploring with MyZubster / Onion.
From a single Onion node to a distributed architecture
Our first milestone is intentionally simple:
Internet
|
HTTPS Gateway
|
Onion Service
|
Application
Before thinking about decentralization, replication or automatic failover, the single-node deployment has to be secure, reproducible and testable.
That gives us a reliable baseline.
The next step is to introduce multiple nodes:
Node A
/ \
Client → Gateway Service
\ /
Node B
But simply adding nodes isn't enough.
The system needs to understand which node exists, what it can provide, and whether it is currently available.
Node discovery
A future decentralized Onion infrastructure needs a discovery layer.
Conceptually, a node could expose metadata such as:
node_id
software_version
protocol_version
capabilities
services
health_status
last_seen
deployment_profile
This creates an important separation:
node identity ≠ service identity
A node can exist without hosting every service.
A service can potentially exist on multiple nodes.
That distinction becomes fundamental once replication enters the picture.
Selective service replication
We don't want to blindly replicate everything everywhere.
Instead, each service could declare a replication policy:
local-only
replicated
replicated-on-demand
primary/secondary
The scheduler/discovery layer could then determine which nodes are compatible with a particular service.
For example:
Node A
├── Service X ✓
├── Service Y ✓
└── Service Z ─ local
Node B
├── Service X ✓ replica
├── Service Y ─
└── Service Z ✓
This allows redundancy to be designed around services, rather than simply duplicating entire machines.
Health-aware routing
Once multiple nodes exist, availability becomes another dimension.
A future architecture could continuously evaluate node health:
Discovery
|
+---------+---------+
| | |
Node A Node B Node C
✓ ✓ ✗
| |
+----+----+
|
Select compatible
healthy node
|
Service
The goal isn't to promise perfect availability.
The goal is controlled degradation.
If one node disappears, the system should know what can continue operating and what cannot.
Why this matters for institutions
This architecture becomes particularly interesting when Onion Services are used in environments where organizations have different infrastructure constraints.
One institution might operate:
Institution A
└── Node A
while another operates:
Institution B
└── Node B
A future ecosystem could allow compatible services to operate across independently managed infrastructure without requiring every organization to deploy the entire platform.
That creates a different model from centralized hosting:
services become deployable units, while nodes become independent infrastructure providers.
Security comes first
Distributed infrastructure also introduces new security problems.
Node discovery creates questions around:
node authentication;
node impersonation;
metadata integrity;
authorization;
credential rotation;
malicious or compromised nodes;
service placement;
auditability.
Replication creates additional concerns around:
data integrity;
version compatibility;
synchronization;
stale replicas;
authorization of replication operations.
For this reason, decentralization cannot simply mean “add more nodes.”
It requires explicit trust boundaries.
A possible architecture
The long-term architecture we are exploring can be represented as:
Institutional Clients
|
HTTPS Gateway
|
Access Layer
|
Node Discovery
|
+-----------+-----------+
| | |
Node A Node B Node C
| | |
Services Services Services
\ | /
\---- Replication ----/
|
Health / Policy
The important components remain logically separated:
Access
→ who can connect?
Discovery
→ where are the nodes?
Health
→ which nodes are available?
Capabilities
→ what can each node provide?
Replication
→ which services should exist on multiple nodes?
Policy
→ under what conditions?
Audit
→ what happened and when?
The roadmap
Our current roadmap is deliberately incremental:
01 HTTPS Institutional Access
↓
02 Security Model
↓
03 Authentication & RBAC
↓
04 Single-node Reference Deployment
↓
05 Node Discovery & Health Registry
↓
06 Selective Service Replication
↓
07 Failover & Degraded Mode
The important part is the order.
We're not starting with a distributed network.
We're starting with a correct single node.
Then we add discovery.
Then controlled replication.
Then resilience.
The bigger idea
The future of Onion Services doesn't necessarily have to be:
“one hidden service running on one server.”
It could evolve toward:
a network of independently operated nodes capable of hosting, discovering and selectively replicating services according to explicit security and availability policies.
That doesn't eliminate the need for trusted infrastructure.
It changes where trust is placed and how it is expressed.
And that's the problem we're interested in exploring.
MyZubster / Onion is still early-stage.
The multi-node architecture described here is a future direction and research/development roadmap, not a claim that all of these capabilities are already implemented.
We're building it incrementally, testing each layer before moving to the next.
If you're working on Tor, privacy infrastructure, distributed systems, institutional networks, security or resilient service architectures, we'd be interested in hearing your thoughts.
