DEV Community

Daniel Ioni
Daniel Ioni

Posted on

Why Zorgax Matters: Connecting Independent Projects to MyZubster Without Centralizing Everything

#projects #zorgax #myzubster #centralizing

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
https://www.myzubster.com/?utm_source=devto&utm_medium=article&utm_campaign=zorgax_federated_nodes&utm_content=myzubster_home

Zorgax
https://www.myzubster.com/zorgax?utm_source=devto&utm_medium=article&utm_campaign=zorgax_federated_nodes&utm_content=zorgax

MyZubster GitHub
https://github.com/MyZubster-Ecosystem/myzubster?utm_source=devto&utm_medium=article&utm_campaign=zorgax_federated_nodes&utm_content=myzubster_github

Nicola / N4K48
https://github.com/nicolaususnicola-lgtm?utm_source=devto&utm_medium=article&utm_campaign=zorgax_federated_nodes&utm_content=n4k48_profile

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
Enter fullscreen mode Exit fullscreen mode

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?
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Zorgax can request:

GET /api/comics
Enter fullscreen mode Exit fullscreen mode

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"
    }
  ]
}
Enter fullscreen mode Exit fullscreen mode

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:
—
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

into:

VERIFIED
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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 ──────┘
Enter fullscreen mode Exit fullscreen mode

Each project remains independently maintained.

Each project can have its own:

repository
API
database
deployment
identity
documentation
evidence
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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"
  ]
}
Enter fullscreen mode Exit fullscreen mode

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?
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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 ─┘
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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

MyZubster
https://www.myzubster.com/?utm_source=devto&utm_medium=article&utm_campaign=zorgax_federated_nodes&utm_content=final_myzubster

Zorgax
https://www.myzubster.com/zorgax?utm_source=devto&utm_medium=article&utm_campaign=zorgax_federated_nodes&utm_content=final_zorgax

N4K48
https://github.com/nicolaususnicola-lgtm?utm_source=devto&utm_medium=article&utm_campaign=zorgax_federated_nodes&utm_content=final_n4k48

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

MyZubster Core
https://github.com/MyZubster-Ecosystem/myzubster?utm_source=devto&utm_medium=article&utm_campaign=zorgax_federated_nodes&utm_content=final_core

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

MyZubster #Zorgax #AI #OpenSource #API #DistributedSystems #SoftwareArchitecture #BuildInPublic #DigitalIdentity #AIEngineering

Top comments (0)