MyZubster Update: Comics, the Time Machine and a Decentralized Onion Architecture

A lot has happened inside the MyZubster ecosystem.

What started as a collection of experimental services is increasingly becoming an interconnected architecture combining:

• open-source software
• decentralized services
• local AI
• research and provenance
• verifiable events
• digital identity
• environmental use cases
• visual storytelling
• comics
• and experimental interfaces for navigating the history of the ecosystem itself

This development cycle introduced several important pieces.

Among them:

MyZubster Comics, the Time Machine MVP, a more decentralized onion architecture, the MYZ ledger, new Workshop and Bounty components, and further integration of Zorgax.

This post explains what these pieces mean and how they fit together.

---

1. MyZubster is becoming a universe, not just a repository

MyZubster contains code.

But code is only one part of the project.

Over time the ecosystem accumulated:

• repositories
• entities
• observations
• research documents
• environmental projects
• infrastructure
• milestones
• visual assets
• characters
• public events
• development history

That creates an interesting problem:

How do you explain a technical ecosystem that has its own history?

A README alone eventually stops being enough.

So MyZubster is experimenting with multiple representations of the same ecosystem.

text
CODE
  ↓
DOCUMENTATION
  ↓
TIMELINE
  ↓
VISUALS
  ↓
COMICS
  ↓
INTERACTIVE EXPERIENCES
The objective is not to replace technical documentation with fiction.

The objective is to make the history and architecture accessible from different perspectives.

2. MyZubster Comics

One of the newest layers is the comic system.

The idea is simple:

real milestones can inspire visual stories.

A repository merge can become a scene.

A new entity can become a character introduction.

An infrastructure milestone can become a chapter.

A research experiment can become part of the visual universe.

This creates two parallel layers.

REAL PROJECT HISTORY
        │
        ├── commits
        ├── pull requests
        ├── releases
        ├── documents
        └── infrastructure
        │
        ▼
STORY REPRESENTATION
        │
        ├── comics
        ├── characters
        ├── cyberpunk scenes
        └── visual timelines

The distinction is important.

The comic is a representation.

Git history remains the technical record.

3. The MyZubster Time Machine

Another recent experiment is the Time Machine MVP.

No, it does not violate causality.

At least not yet. 👽

The Time Machine is an interface concept for navigating the history of MyZubster.

Instead of asking:

What does MyZubster look like today?

we can ask:

What did the ecosystem look like at a specific moment?

Conceptually:

TODAY
  │
  ▼
TIME MACHINE
  │
  ├── milestone
  ├── repository state
  ├── public timeline
  ├── entity
  ├── visual
  ├── event
  └── documentation
  │
  ▼
HISTORICAL VIEW

The project can progressively connect public milestones with verifiable repository history.

That opens interesting possibilities.

A visitor could eventually navigate:

2024
 ↓
2025
 ↓
early 2026
 ↓
identity milestone
 ↓
Zorgax
 ↓
Research RAG
 ↓
LIFE 2026 work
 ↓
decentralized services
 ↓
today

Instead of presenting development history as a flat changelog, it becomes something that can be explored.

4. Why build a Time Machine?

Open-source projects generate enormous amounts of history.

But most of that history becomes difficult to understand.

It gets distributed between:

Git commits
GitHub issues
Pull requests
Documentation
Screenshots
Announcements
Infrastructure
Experiments

A Time Machine can become a navigation layer over those artifacts.

The long-term idea is:

EVENT
  ↓
TIMESTAMP
  ↓
EVIDENCE
  ↓
REPOSITORY / DOCUMENT / ASSET
  ↓
TIMELINE
  ↓
TIME MACHINE

This also connects naturally with another recent MyZubster component:

the MYZ ledger.

5. The MYZ ledger

MyZubster has also started experimenting with a ledger for ecosystem events.

The goal is not to create another cryptocurrency.

The goal is much simpler:

make important events easier to verify.

Conceptually:

event
 ↓
canonical representation
 ↓
hash
 ↓
ledger entry
 ↓
verification

This can eventually provide a bridge between the Time Machine and verifiable project history.

Instead of displaying only:

“This happened.”

the ecosystem can move toward:

“This happened, here is the associated record, and here is how it can be verified.”

That distinction matters.

6. Decentralizing the onion architecture

Another important development concerns MyZubster's onion infrastructure.

A single onion endpoint is useful.

But a single endpoint is also a single dependency.

The architectural direction is therefore moving away from:

ONE SERVICE
    ↓
ONE ONION
    ↓
ONE HOST

toward something closer to:

             MyZubster
                 │
       ┌─────────┼─────────┐
       ▼         ▼         ▼
    Node A     Node B     Node C
       │         │         │
       ▼         ▼         ▼
    Onion A    Onion B    Onion C

The purpose is resilience.

Not anonymity theater.

Not “dark web” branding.

Not uncontrolled crawling.

The interesting engineering questions are:

service discovery
redundancy
failover
node independence
verification
health monitoring
canonical service records
7. Onion Root Record

A decentralized system needs a way to understand what services belong to the ecosystem.

This leads to the idea of an Onion Root Record.

Conceptually it can describe:

SERVICE
 ├── identity
 ├── endpoint
 ├── role
 ├── status
 ├── verification information
 └── ecosystem relationship

The important part is that decentralization should not mean losing the ability to understand what is canonical.

The challenge becomes:

DECENTRALIZATION
        +
DISCOVERABILITY
        +
VERIFICATION

rather than simply creating more addresses.

8. Decentralization does not mean autonomous crawling

This boundary is worth making explicit.

MyZubster's decentralized onion work should not be confused with giving an AI autonomous access to Tor.

Zorgax currently follows a controlled model.

ZORGAX
  ↓
AUTHORIZED CAPABILITY
  ↓
MYZUBSTER SERVICE
  ↓
RESULT

Not:

ZORGAX
  ↓
DO WHATEVER YOU WANT
  ↓
INTERNET / TOR

For example, the Research RAG implementation currently exposes boundaries such as:

{
  "research_crawl_autonomous": false,
  "research_crawl_requires_admin": true
}

That distinction is intentional.

9. Zorgax keeps evolving

Zorgax is the local AI entity being developed inside MyZubster.

Current architecture includes support for:

Local AI
+
Persistent Memory
+
Observation Registry
+
Research RAG
+
Provenance

A typical architecture looks like:

User
  ↓
MyZubster Gateway
  ↓
Zorgax
  ├── memory
  ├── observations
  ├── research retrieval
  └── local model
        ↓
      Ollama

The Research RAG layer can retrieve bounded context from a research index before generating an answer.

That gives Zorgax something extremely important:

sources.

10. From AI answers to provenance

A normal LLM interaction often looks like:

QUESTION
   ↓
MODEL
   ↓
ANSWER

The Zorgax research architecture moves toward:

QUESTION
   ↓
RETRIEVAL
   ↓
SOURCE R1
SOURCE R2
SOURCE R3
   ↓
BOUNDED CONTEXT
   ↓
LOCAL MODEL
   ↓
ANSWER
   +
PROVENANCE

Research records can retain information such as:

source URL
source type
crawl timestamp
content hash
retrieval label

The goal is not to claim that provenance magically makes every AI answer correct.

It does something more practical:

it makes the context behind an answer more inspectable.

11. Comics meet Zorgax

This is where the technical and visual sides of MyZubster start becoming interesting together.

Zorgax is both:

a software entity

and

a character in the visual MyZubster universe

Those roles should remain distinguishable.

The technical Zorgax has actual capabilities defined by software.

The visual Zorgax can represent those developments through comics and artwork.

For example:

TECHNICAL EVENT
Zorgax gains Research RAG
        ↓
PUBLIC TIMELINE
        ↓
VISUAL EVENT
        ↓
Zorgax comic chapter

The comic does not prove the technical event.

The repository does.

But the comic can make the event understandable.

12. A visual ecosystem

MyZubster's visual repository is also expanding.

Recent visual work includes representations around:

Zorgax
MyZubster entities
environmental projects
Urban Lab
LIFE 2026 concepts
roadmaps
cyberpunk characters
comics
Time Machine

This produces a visual vocabulary for the ecosystem.

An architecture diagram explains relationships technically.

A roadmap explains sequence.

A comic communicates a story.

A photograph can document a real location.

They serve different purposes.

13. Real-world environmental observations

The visual layer is also beginning to meet the physical world.

MyZubster's LIFE-related work includes exploration around circular water, environmental monitoring, territorial observations and potential pilot scenarios.

This introduces another information path:

PHYSICAL WORLD
      ↓
PHOTOGRAPH / OBSERVATION
      ↓
DOCUMENTATION
      ↓
REGISTRY
      ↓
RESEARCH
      ↓
ZORGAX

This is particularly interesting because the source is no longer only software.

It can begin with an observation of a real place.

Any institutional, scientific or partnership claims must of course remain distinct from exploratory project documentation unless formally confirmed.

14. Urban Lab

The Urban Lab work provides another bridge between software and real-world use cases.

Recent development includes a Pilot 0 concept around:

repair
circularity
mobility
diagnostics
workshop workflows

At the software level, MyZubster is also developing workshop components and diagnostic structures.

Conceptually:

PHYSICAL OBJECT
      ↓
DIAGNOSTIC
      ↓
WORKSHOP
      ↓
SERVICE EVENT
      ↓
MYZUBSTER
      ↓
VERIFIABLE HISTORY

This can eventually connect to reputation and bounty mechanisms as well.

15. The Bounty Engine

Another recent component is the MyZubster bounty architecture.

The objective is to formalize tasks and contributions.

Instead of:

someone did something

we can progressively model:

BOUNTY
  ↓
TASK
  ↓
CONTRIBUTOR
  ↓
RESULT
  ↓
VALIDATION
  ↓
EVENT
  ↓
REPUTATION

This connects naturally with the ledger.

And with the Time Machine.

And eventually with Zorgax.

16. The emerging architecture

Put the recent pieces together and something larger starts appearing.

                     MYZUBSTER
                         │
       ┌─────────────────┼──────────────────┐
       │                 │                  │
       ▼                 ▼                  ▼
   SERVICES          KNOWLEDGE          EXPERIENCE
       │                 │                  │
       │             Research RAG           │
       │             Observations           │
       │             Documents              │
       │                 │                  │
       └──────────────► ZORGAX ◄────────────┘
                         │
                         ▼
                    TOOL LAYER
                         │
          ┌──────────────┼──────────────┐
          ▼              ▼              ▼
       Workshop        Bounty         Ledger
          │              │              │
          └──────────────┼──────────────┘
                         ▼
                    EVENT HISTORY
                         │
                         ▼
                    TIME MACHINE
                         │
               ┌─────────┴─────────┐
               ▼                   ▼
           TECHNICAL             VISUAL
            HISTORY              STORY
                                   │
                                   ▼
                                 COMICS

And underneath the network layer can progressively become less dependent on individual endpoints.

MyZubster
    │
    ├── Web
    ├── APIs
    ├── local services
    └── decentralized onion services
17. Why comics belong in an open-source project

At first, comics and infrastructure engineering may seem unrelated.

But open-source projects have always needed storytelling.

A project has to explain:

where it came from
what changed
why something was built
who or what its components are
what could happen next

Documentation handles precision.

Code provides implementation.

Git provides history.

Visual storytelling provides accessibility.

So the MyZubster approach is becoming:

CODE tells you HOW.


DOCS tell you WHAT.


GIT tells you WHEN.


PROVENANCE tells you WHERE IT CAME FROM.


COMICS tell you the STORY.
18. The rule: fiction must not overwrite reality

This is especially important for a project mixing technical development and cyberpunk storytelling.

The project should always preserve a boundary between:

implemented

experimental

planned

visual/narrative

For example:

A cyberpunk illustration of a decentralized city is not evidence that the infrastructure depicted exists.

A comic showing Zorgax controlling an enormous network does not grant Zorgax those permissions.

A LIFE-themed visual does not imply LIFE funding or institutional approval.

A partner concept document does not establish a partnership.

The canonical evidence remains the underlying technical and documentary record.

19. Where the project is heading

The interesting part is not any individual feature.

It is how they can connect.

Imagine navigating the Time Machine to a milestone.

You see:

EVENT
  ↓
Git commit
  ↓
ledger verification
  ↓
documentation
  ↓
associated entities
  ↓
visual
  ↓
comic chapter

Then Zorgax can help explain the event using indexed source material.

The onion architecture can make selected services less dependent on a single infrastructure endpoint.

The Workshop can produce service events.

The Bounty Engine can represent contributions.

The ledger can preserve verifiable relationships between events.

And the Time Machine can provide a human interface over the resulting history.

That is the direction.

20. Not a finished system

MyZubster is experimental.

Some components are operational.

Some are MVPs.

Some are architecture work.

Some are documentation.

Some are visual storytelling.

Some are future directions.

That is intentional.

The repository history should remain the place where implementation status can actually be verified.

The goal isn't to pretend the future already exists.

The goal is to build it incrementally.

The current MyZubster stack

The ecosystem is progressively bringing together:

Open Source
Local AI
Zorgax
Research RAG
Provenance
Persistent Memory
Observations
Digital Identity
MYZ Ledger
Bounty Engine
Workshop
Environmental Use Cases
LIFE 2026 project work
Visual Storytelling
Comics
Time Machine
Decentralized Onion Services

Different components.

One evolving ecosystem.

The next chapter

The most interesting question now isn't:

What feature should MyZubster add next?

It is:

What happens when all these components begin talking to each other?

A research agent that can understand verifiable ecosystem history.

A Time Machine built over real open-source events.

Comics generated from actual milestones.

Environmental observations connected to provenance.

Bounties connected to contribution history.

Services distributed across independent nodes.

And a virtual entity capable of navigating those layers without automatically receiving authority over them.

That's the experiment.

That's MyZubster.

👽

MyZubster Ecosystem

GitHub:

https://github.com/MyZubster-Ecosystem

Current development themes:

Zorgax · Time Machine · Comics · Onion Decentralization · Research RAG · MYZ Ledger · Workshop · Bounty Engine · LIFE 2026 · Visual Ecosystem

Build the infrastructure.
Preserve the history.
Verify the evidence.
Tell the story.