From Onion Services to Digital Identity: What We Are Building with MyZubster
Over the last months, MyZubster has stopped looking like a single application.
It is becoming a collection of connected experiments around one question:
How can we build digital infrastructure where privacy, identity, evidence and human creativity reinforce each other instead of competing with each other?
Some of the pieces now exist.
We have built a Tor v3 Onion Service architecture.
We have created a canonical visual repository for the ecosystem.
We have started separating verified identity from assumptions made from usernames, repositories and directories.
We have created independent repositories for several LIFE entities.
And we are connecting all of this to a wider philosophy:
privacy first, evidence first, human responsibility always.
This article explains what we have built so far — and, just as importantly, what we have not built yet.
1. A Tor v3 Onion entrance to MyZubster
One of the most interesting infrastructure experiments is the MyZubster Onion Service.
The architecture is intentionally simple:
text
Tor Network
|
v
MyZubster Onion Service :80
|
v
frontend:3000
Docker internal network only
The Onion component runs as an isolated Docker container.
The frontend does not need to be published directly through the Onion container to the host.
Tor becomes another possible access layer to the application.
The important part is not simply having a .onion address.
The important part is how its identity is handled.
The Tor v3 hostname is generated from the Onion Service identity and stored inside a persistent Docker volume.
That means container recreation does not automatically mean identity destruction.
container recreated
|
v
persistent onion_data volume
|
v
same intended Onion identity
The private Onion key stays inside that persistent storage.
It must never be committed to Git.
It must never appear in logs.
It must never become part of an image layer or CI artifact.
This creates an interesting principle:
Infrastructure also has identity.
A .onion endpoint is not just a random URL.
Its address is connected cryptographically to the Onion Service key material.
2. What we mean by "decentralized"
This word requires precision.
MyZubster is not claiming that every component is currently fully decentralized.
A Docker frontend connected through Tor can still depend on infrastructure controlled by one operator.
What Tor gives us is something more specific:
decentralized network routing;
privacy-oriented access;
a self-authenticating Onion address;
reduced dependence on conventional DNS for that endpoint;
the possibility of reaching a service without directly exposing its public network location.
That is already important.
But decentralization should be treated as an architecture composed of layers, not as a marketing checkbox.
For us the direction looks more like:
PRIVATE ACCESS
+
VERIFIABLE EVIDENCE
+
PORTABLE IDENTITY
+
DISTRIBUTED SERVICES
+
OPEN SOURCE
Not every layer is complete yet.
And that is fine.
The important thing is being explicit about the difference between what exists and what is planned.
3. MyZubster Visual: evidence becomes a visual language
A second experiment became its own repository:
MyZubster Visual.
It is the canonical visual repository of the MyZubster ecosystem.
But it is not supposed to be just a folder containing images.
The idea is to connect:
REAL-WORLD DISCOVERY
↓
MYZUBSTER OBSERVATION
↓
PUBLIC-SAFE EVIDENCE
↓
CONTEXT
↓
VISUAL INTERPRETATION
↓
COMIC / DIAGRAM / STORY
↓
HUMAN REVIEW
This is where the cyberpunk dimension of MyZubster becomes useful.
Science fiction is not being used to replace evidence.
It is being used to communicate evidence.
A technical architecture diagram and a cyberpunk comic can describe the same ecosystem from two different angles.
One is optimized for engineers.
The other is optimized for imagination.
Both can point back to the same real-world context.
4. Why visual provenance matters
AI makes generating images extremely easy.
That creates a new problem:
Where did this image come from?
What does it represent?
Was it accepted?
Is it canonical?
Is it related to a real observation or only fictional?
So MyZubster Visual is gradually becoming more than a gallery.
The repository already separates different classes of assets:
assets/bots/
assets/brand/
assets/ecosystem/
assets/ui/
assets/maps/
assets/social/
assets/hardware/
assets/icons/
assets/roadmap/
assets/comic/
assets/milestones/
metadata/
There is also a deliberate distinction between:
assets/comic/
for binary artwork,
and:
comics/
for narrative canon, series structures and contributor documentation.
That distinction might look small.
Architecturally, it is important.
It separates the artifact from the knowledge describing the artifact.
5. Then we hit the identity problem
While building our local AI and repository knowledge systems, another problem became obvious.
Suppose an AI sees:
/home/Daniel/project
github.com/Daniel/example
repository-name-containing-Daniel
What can it conclude?
Almost nothing about the real identity, ownership or authorship of a human being.
A username is not proof of identity.
A folder name is not proof of ownership.
A Git commit is not automatically proof of legal authorship.
A GitHub account name is not enough to establish someone's complete identity.
This sounds obvious.
But language models are extremely good at turning weak correlations into confident sentences.
So we changed the architecture.
6. Identity must come from canonical evidence, not inference
Our local MyZubster knowledge system now follows a stricter principle:
Identity cannot be inferred from repository names, paths, accounts, commits or services.
If the knowledge base does not contain explicit verified information establishing who a person is or what role they have, the system must say that it does not have enough verified data.
This changes the role of AI.
Instead of:
repository name
↓
AI assumption
↓
identity claim
we want:
canonical identity record
+
verified evidence
+
provenance
↓
permitted identity statement
That is the beginning of what we call our Verified Digital Identity Foundation.
And the word foundation is intentional.
7. This is not yet a complete decentralized identity system
We have not reached the point where we should claim a complete DID architecture.
A future cryptographically verifiable identity layer could include things such as:
Identity
|
+-- public key
|
+-- signed statements
|
+-- verifiable credentials
|
+-- canonical identifier
|
+-- provenance
|
+-- revocation / rotation
But today our achievement is one layer earlier.
We have started establishing the rules that prevent an AI system from inventing identity.
That is essential.
Cryptography cannot repair an architecture whose data model already confuses assumptions with facts.
Before decentralized identity comes identity discipline.
8. Digital identities for ecosystem entities
We have also started giving important MyZubster entities dedicated repositories.
Among them:
Zorgax
Oruun
Selya-9
Khar-Vel
Nythera
This does not magically make them decentralized identities.
But it gives each entity a stable namespace where its future:
documentation;
capabilities;
history;
verified metadata;
visual identity;
public keys;
attestations;
releases;
can eventually live.
A repository can therefore become part of an identity architecture without pretending that the repository itself is the identity.
That distinction matters.
9. Zorgax and verified knowledge
Zorgax is another piece of this architecture.
We are experimenting with a local AI assistant connected to a verified knowledge base.
The goal is not:
Give the AI access to everything and hope it answers correctly.
The goal is closer to:
Question
↓
verified local knowledge
↓
retrieval
↓
policy / deterministic guards
↓
local model
↓
answer constrained by evidence
An especially important lesson has been that prompt engineering alone is not always enough.
When a claim is dangerous to infer — such as someone's identity or authorship — deterministic rules can be more reliable than simply telling the language model to "be careful".
This leads to a broader design principle:
Some truths should be constrained by architecture, not etiquette.
10. The milestone
In August 2026 we decided to mark this moment visually.
The visual became an official asset inside MyZubster Visual.
For us it represents the convergence of several experiments:
MYZUBSTER
|
+------------+-------------+
| | |
v v v
TOR ONION VERIFIED VISUAL
ACCESS KNOWLEDGE LAYER
| | |
+------------+-------------+
|
v
DIGITAL IDENTITY
FOUNDATION
These systems were initially separate experiments.
Now they are beginning to form an architecture.
11. Privacy without evidence is not enough
Privacy is essential.
But privacy alone creates another possible failure mode:
anonymous information with no way to evaluate its provenance.
Evidence without privacy creates the opposite problem:
a system that can verify everything by exposing everyone.
The architecture we are exploring tries to find another path.
Privacy
+
Evidence
+
Identity
+
Selective disclosure
+
Human control
The objective is not universal surveillance.
And it is not universal anonymity.
It is the ability to decide what must be proven, what can remain private and who controls that decision.
12. Why the Onion Service and digital identity belong together
At first these projects may appear unrelated.
Tor is networking.
Digital identity is authentication.
Visual repositories are content.
AI retrieval is knowledge infrastructure.
But they share a common question:
How do we create trust without requiring blind trust in a central intermediary?
The Onion Service explores network privacy.
The identity foundation explores factual identity.
MyZubster Visual explores provenance and communication.
Zorgax explores evidence-constrained artificial intelligence.
Together they start to form something much more interesting than any individual component.
13. The MyZubster model we are exploring
One possible long-term architecture looks like this:
HUMAN
|
v
+----------------+
| DIGITAL ID |
| user-controlled|
+-------+--------+
|
+------------+-------------+
| |
v v
PUBLIC INTERNET TOR / ONION
| |
+------------+-------------+
|
v
MYZUBSTER
|
+----------------+----------------+
| | |
v v v
REAL-WORLD VERIFIED VISUAL
OBSERVATION EVIDENCE STORY
| | |
+----------------+----------------+
|
v
KNOWLEDGE LAYER
|
v
AI
/ ZORGAX
|
v
EVIDENCE-BOUND OUTPUT
This is not a finished architecture.
It is a direction.
And we prefer publishing that direction openly instead of pretending the destination has already been reached.
14. Open source as a memory system
GitHub is also becoming something else for MyZubster:
project memory.
A commit records that something changed.
A pull request records why it changed.
A README explains how it should work.
Metadata records what an artifact represents.
A visual records the cultural meaning of a milestone.
Together these produce something richer than source code alone.
They produce history.
And history is a critical component of identity.
15. What we are actually inventing
None of the individual technologies described here were invented by MyZubster.
Tor exists.
Docker exists.
Git exists.
AI exists.
Digital identity technologies exist.
Visual storytelling exists.
The experiment is in how we combine them.
We are exploring a system where:
Tor provides privacy-oriented access;
open source provides inspectability;
canonical repositories provide project memory;
verified knowledge limits AI hallucination;
identity is established from evidence instead of usernames;
visuals translate technical events into culture;
real-world observations remain connected to their provenance;
AI assists humans without becoming the source of truth.
That combination is what we are building.
16. What comes next
There is still a lot to do.
For the Onion layer:
complete external Tor end-to-end validation;
strengthen container hardening;
document backup and identity recovery;
perform security review.
For digital identity:
define canonical identity documents;
introduce cryptographic public-key relationships;
explore signed attestations;
evaluate verifiable credentials;
design key rotation and recovery;
define what information must remain private.
For MyZubster Visual:
continue attaching provenance metadata to assets;
connect visuals to technical milestones;
preserve original assets and optimized publication versions;
expand the Cyberpunk Discovery Series.
For AI:
keep improving verified retrieval;
expand deterministic safety guards;
clearly separate facts from inference;
make provenance visible to the user.
Conclusion
The interesting part of building MyZubster is no longer any single application.
It is the relationship between the layers.
A Tor Onion Service asks:
How can a service be reached without exposing more infrastructure than necessary?
Digital identity asks:
How can a claim about someone be proven instead of inferred?
MyZubster Visual asks:
How can technical history become understandable and memorable?
Zorgax asks:
How can AI reason over evidence without pretending to know what it does not know?
And MyZubster asks the larger question:
Can privacy, evidence, identity, decentralization, AI and human creativity exist inside the same architecture?
We don't have the complete answer yet.
But now we have working pieces.
And they are beginning to connect.
Privacy first. Evidence first. Humans remain responsible.
MyZubster — August 2026
Top comments (0)