Why Zorgax Matters: Connecting Independent Projects to MyZubster Without Centralizing Everything
While working on the Nicola / N4K48 × Nicola Comics × MyZubster pilot, we realized that the most interesting part of the experiment is not the comics themselves.
It is the architecture behind the connection.
The question we are exploring is:
How can an independent project become part of MyZubster without moving its entire application, database and logic inside MyZubster?
Our current answer is based on three layers:
Independent Project → Zorgax → MyZubster
Nicola Comics is becoming our first concrete case for testing this idea.
The Projects
MyZubster GitHub
https://github.com/MyZubster-Ecosystem/myzubster?utm_source=devto&utm_medium=article&utm_campaign=zorgax_federated_nodes&utm_content=myzubster_github
N4K48 × MyZubster
https://github.com/nicolaususnicola-lgtm/myzubster?utm_source=devto&utm_medium=article&utm_campaign=zorgax_federated_nodes&utm_content=n4k48_myzubster
Nicola Comics / N4K48 MVP
https://github.com/nicolaususnicola-lgtm/myzubster-mvp?utm_source=devto&utm_medium=article&utm_campaign=zorgax_federated_nodes&utm_content=nicola_mvp
Public integration tracking
https://github.com/MyZubster-Ecosystem/myzubster/issues/1176?utm_source=devto&utm_medium=article&utm_campaign=zorgax_federated_nodes&utm_content=integration_issue
The Basic Idea
Imagine three separate systems.
1. MyZubster
MyZubster is the wider ecosystem.
It can provide things such as:
- users;
- community;
- projects;
- marketplace;
- discovery;
- interfaces;
- collaboration.
2. Nicola / N4K48
Nicola maintains his own project.
His environment can contain:
N4K48 identity
+
Nicola Comics
+
Project Planner
+
API
+
GitHub repositories
+
technical evidence
+
future verified digital assets
The important point is:
Nicola's project does not have to become part of the MyZubster codebase.
It can remain independently maintained.
3. Zorgax
Zorgax sits between the user, MyZubster and the external project.
Its job is not necessarily to own Nicola's data.
Its job is to understand:
What is the user asking?
↓
Which project can answer?
↓
Which capability is required?
↓
Which API should be called?
↓
What does the returned data mean?
↓
What evidence supports the answer?
That makes Zorgax closer to an AI orchestration and interaction layer.
A Simple Example
Imagine a user entering MyZubster and asking Zorgax:
"Show me Nicola's comics."
Zorgax should not invent the catalog.
And MyZubster does not necessarily need to keep a duplicate copy of Nicola's database.
Instead:
USER
↓
MYZUBSTER
↓
ZORGAX
↓
NICOLA COMICS API
Zorgax can request:
GET /api/comics
Nicola's service could return structured information:
{
"creator": "Nicola",
"identity": "N4K48",
"comics": [
{
"id": "n4k48-comic-001",
"title": "Dall'idea software al metaverso",
"status": "NFT_CANDIDATE"
}
]
}
Zorgax can then turn those structured data into a useful response:
Nicola / N4K48 currently has three comic pages available. The first one is proposed as an NFT candidate. Would you like to inspect it?
The source of truth remains Nicola's service.
Zorgax provides the interaction.
MyZubster provides the ecosystem where the interaction happens.
What Happens When the User Asks About an NFT?
This is where the architecture becomes even more useful.
Suppose the user asks:
"Has Nicola's comic already been minted as an NFT?"
Zorgax queries the project.
The current project state could be:
NFT_CANDIDATE
PROPOSED_FOR_REVIEW
RIGHTS:
TO_VERIFY
CONTRACT:
—
TOKEN ID:
—
TRANSACTION HASH:
—
Zorgax should therefore answer:
No. The comic is currently an NFT candidate proposed for review. There is not yet verified on-chain evidence of a mint.
This is important.
Zorgax is not supposed to turn:
PROPOSED
into:
VERIFIED
just because an AI model generated a confident sentence.
AI Should Navigate Evidence, Not Replace It
This principle is becoming increasingly important for MyZubster.
Different claims require different evidence.
Git commit
→ code evidence
Test result
→ testing evidence
Deployment
→ deployment evidence
Analytics event
→ usage evidence
Rights document
→ provenance evidence
Transaction hash
→ blockchain evidence
Zorgax can connect and explain these pieces.
But it should not silently manufacture them.
The architecture we are exploring therefore looks more like:
USER QUESTION
↓
ZORGAX
↓
PROJECT API
↓
STRUCTURED DATA
↓
EVIDENCE
↓
INTERPRETATION
↓
USER
N4K48 as an Identity Node
There is another interesting part of this experiment.
N4K48 does not have to remain only a cyberpunk avatar.
It could become a persistent digital identity associated with Nicola's project.
Conceptually:
N4K48
│
├── creator
│ └── Nicola
│
├── projects
│ ├── Nicola Comics
│ └── Project Planner
│
├── assets
│ └── comic pages
│
├── capabilities
│ ├── gallery
│ ├── detail
│ ├── candidate
│ └── next_steps
│
├── evidence
│ ├── commits
│ ├── tests
│ └── deployments
│
└── blockchain
└── verified assets, if they exist
Now N4K48 starts becoming something different.
Not just:
"This is Nicola's avatar."
But:
"This is a discoverable identity connected to projects, capabilities and evidence."
From One Integration to Many Nodes
This is where the Nicola experiment becomes relevant to the larger MyZubster architecture.
Today we have:
NICOLA COMICS
│
▼
ZORGAX
│
▼
MYZUBSTER
But imagine applying the same model to other projects:
Nicola Comics ───────────┐
│
Agriculture ─────────────┤
│
Research Lab ────────────┤
│
Animal Rescue ───────────┤
│
Circular Economy ────────┼── ZORGAX ── MYZUBSTER
│
Local Services ──────────┤
│
Student Projects ────────┤
│
Community Projects ──────┘
Each project remains independently maintained.
Each project can have its own:
repository
API
database
deployment
identity
documentation
evidence
Zorgax becomes the layer that knows how to interact with those projects.
The Problem With Hard-Coding Every Integration
There is an obvious problem.
We don't want Zorgax to become thousands of rules such as:
if Nicola:
call Nicola API
if Agriculture:
call Agriculture API
if Research:
call Research API
if Animal Rescue:
call Animal Rescue API
That would become difficult to maintain.
So the next architectural idea is more interesting.
What if every compatible project could describe itself?
A MyZubster Node Manifest
Imagine that an independent project publishes a small machine-readable description.
For example:
{
"node": "N4K48",
"creator": "Nicola",
"services": {
"comics": "/api/comics",
"zorgax": "/api/zorgax/ask"
},
"capabilities": [
"gallery",
"detail",
"candidate",
"next_steps"
]
}
This could become something like a MyZubster Node Manifest.
Instead of teaching Zorgax every integration manually, Zorgax could discover:
WHO ARE YOU?
↓
WHAT SERVICES DO YOU PROVIDE?
↓
WHAT CAN I ASK YOU TO DO?
↓
WHERE ARE YOUR ENDPOINTS?
↓
WHAT EVIDENCE DO YOU EXPOSE?
Then the integration becomes much more generic.
Service Discovery Instead of Hard-Coded Integrations
The future interaction could become:
ZORGAX
↓
DISCOVER NODE
↓
READ MANIFEST
↓
DISCOVER CAPABILITIES
↓
SELECT CAPABILITY
↓
CALL ENDPOINT
↓
VALIDATE RESPONSE
↓
CHECK EVIDENCE STATE
↓
RESPOND TO USER
That is a very different architecture from a traditional monolithic application.
MyZubster as a Federated Ecosystem
The traditional model would be:
EVERY USER
EVERY PROJECT
EVERY DATABASE
EVERY SERVICE
EVERY ASSET
↓
ONE CENTRAL APPLICATION
We are exploring something different:
PROJECT A ─ API ─┐
│
PROJECT B ─ API ─┤
│
PROJECT C ─ API ─┤
│
PROJECT D ─ API ─┼── ZORGAX
│ │
PROJECT E ─ API ─┤ ▼
│ MYZUBSTER
PROJECT F ─ API ─┘
This is closer to a federated ecosystem.
The projects don't disappear inside MyZubster.
They remain independent nodes.
Why This Matters
There are several potential advantages.
Independence
A contributor can maintain their own repository and service.
Interoperability
The project exposes a documented interface instead of requiring direct database access.
AI Discovery
Zorgax can potentially discover capabilities dynamically.
Evidence
The node can expose the state and evidence associated with its claims.
Scalability
New projects could eventually integrate without requiring a complete rewrite of the MyZubster core.
Human Control
Sensitive or irreversible operations can remain outside the automatic AI workflow.
What We Are Actually Building Today
It is important to separate the architectural direction from the current implementation.
We do not currently have a complete universal federation protocol.
We are testing the idea through a concrete pilot.
The current path is:
NICOLA COMICS LOCAL MVP
↓
READ-ONLY ZORGAX ADAPTER
↓
LOCAL VALIDATION
↓
PUBLIC HTTPS DEPLOYMENT
↓
PUBLIC ZORGAX CONNECTION
↓
END-TO-END TEST
↓
DOCUMENT RESULTS
Nicola Comics is therefore useful because it gives us something real to learn from before designing a generic standard.
The Bigger Goal
If this experiment works, the long-term contributor journey could become:
CREATE IDENTITY
↓
BUILD PROJECT
↓
PUBLISH REPOSITORY
↓
DEPLOY SERVICE
↓
EXPOSE API
↓
DECLARE CAPABILITIES
↓
CONNECT TO ZORGAX
↓
CONNECT TO MYZUBSTER
↓
PRODUCE EVIDENCE
↓
VERIFY
At that point, joining MyZubster would not necessarily mean:
"Move your application into our application."
It could mean:
"Keep control of your project. Expose a safe and documented interface. Tell the ecosystem what your node can do. Let Zorgax help users interact with it."
That is the idea we are now testing with N4K48.
The Final Vision
The final goal is not to create an AI that controls everything.
It is almost the opposite.
We want independent systems with clear boundaries:
CREATOR
↓
INDEPENDENT PROJECT
↓
CONTROLLED API
↓
CAPABILITIES
↓
EVIDENCE
↓
ZORGAX
↓
MYZUBSTER
↓
USER
Zorgax becomes the intelligence connecting the network.
MyZubster becomes the ecosystem connecting the participants.
Independent projects remain independent.
And evidence determines what the system is allowed to claim as verified.
Nicola Comics is a small pilot.
But the question behind it is much larger:
Can we build an AI-assisted ecosystem where independent projects can discover and interact with each other without centralizing everything?
That is what we are trying to find out.
Connect → Discover → Interact → Measure → Verify → Replicate.
Explore the Experiment
N4K48 × MyZubster
https://github.com/nicolaususnicola-lgtm/myzubster?utm_source=devto&utm_medium=article&utm_campaign=zorgax_federated_nodes&utm_content=final_n4k48_myzubster
Nicola Comics / MVP
https://github.com/nicolaususnicola-lgtm/myzubster-mvp?utm_source=devto&utm_medium=article&utm_campaign=zorgax_federated_nodes&utm_content=final_nicola_mvp
Follow the Nicola integration — issue #1176
https://github.com/MyZubster-Ecosystem/myzubster/issues/1176?utm_source=devto&utm_medium=article&utm_campaign=zorgax_federated_nodes&utm_content=final_issue
