DEV Community: Daniel Ioni

# DEV Guide: Building ZORGAX Party Mode, Realtime Sessions and Moderation in MyZubster

Daniel Ioni — Sun, 06 Sep 2026 03:53:06 +0000

DEV Guide: Building ZORGAX Party Mode, Realtime Sessions and Moderation in MyZubster

Over the last development cycle, we pushed a significant part of the MyZubster Social Life / Metaverse architecture forward.

What started as a social metaverse prototype is gradually becoming a structured system where:

communities can connect to virtual environments;
live sessions have authoritative lifecycle state;
AI can understand operational context without receiving unrestricted access;
creator actions can pass through bounded capability checks;
moderation has persistent policy and audit primitives;
realtime communication can use short-lived authenticated socket sessions;
live experiences can transition into post-event archives.

This guide explains what we built, why we designed it this way, and what still remains.

1. The Starting Point: Neon Plaza

The MyZubster Metaverse currently exposes Neon Plaza, our shared social environment:

https://www.myzubster.com/metaverse

Before this development cycle, Neon Plaza already had some important foundations:

MongoDB-backed shared presence;
browser and touch movement;
public chat and emotes;
proximity awareness;
guest and authenticated characters;
portals to other areas of the MyZubster ecosystem;
session and browser capability diagnostics.

The existing presence model is intentionally ephemeral.

Presence records expire after approximately:

90 seconds

Public chat has also been designed around limited retention rather than indefinite persistence.

The current shared-presence implementation uses a serverless-compatible polling architecture.

That remains useful, but it is not enough for the architecture we want next.

2. The Goal: ZORGAX Party Mode

The next layer is ZORGAX Party Mode.

The idea is not:

put a chatbot inside a metaverse.

The real objective is:

create a bounded AI orchestration layer that can understand a live social environment, reason about it, and eventually trigger authorized actions without becoming the source of truth.

The high-level architecture is:

Community
   ↓
Public Event
   ↓
Virtual Room / Virtual Twin
   ↓
Live Session
   ↓
ZORGAX Party Mode
   ↓
Moderation / Creator Actions
   ↓
Archive / Replay
   ↓
Community

The central architectural rule is:

System state first.
AI reasoning second.

ZORGAX can explain state.

ZORGAX can reason about state.

ZORGAX can eventually request actions.

But the backend defines what is true and what is authorized.

3. Z1 — PartyContext

The first Party Mode component was PartyContext.

Before giving an AI access to a live application, we need to answer a basic security question:

What information is the model allowed to know?

Instead of sending raw database objects into an LLM, the backend builds a bounded context.

Conceptually:

Authenticated Actor
        ↓
Server Authorization
        ↓
PartyContext
        ↓
ZORGAX

PartyContext can represent authorized information such as:

Actor
Community
Event
Room
Session
Capabilities
Restrictions

But it intentionally excludes information that the model does not need.

Examples include:

authentication tokens;
authorization headers;
private keys;
internal account identifiers;
email addresses;
private location data;
raw session identifiers;
permanent movement history.

One important lesson from implementation was that context itself is part of the security boundary.

During review, we caught an early version exposing an internal account identifier.

That field was removed and covered by a regression test.

4. Z2 — Grounded Community and Event Assistant

Once PartyContext existed, we implemented the first Party Mode assistant.

Endpoint:

POST /api/zorgax/party-assistant

The key design decision was not how much the assistant could answer.

It was how it behaved when information was unavailable.

For example, if the backend does not contain an authoritative lineup for an event, ZORGAX must not invent one.

Instead of:

"DJ X is playing at midnight."

the correct behavior is:

event information unavailable

The same applies to:

private locations;
account data;
restricted system information;
unverified event details.

This gave us another core rule:

Missing product state must remain missing product state.

An LLM should never convert absence of data into fictional application state.

5. Z3 — Room and Session Telemetry

The next step was giving ZORGAX operational awareness.

We introduced a Party Mode telemetry adapter:

GET /api/zorgax/party-telemetry

The purpose is to expose useful live-system information without exposing user-level surveillance data.

The telemetry model includes concepts such as:

Room health
Transport state
Aggregate presence
Storage state
Reconnect metadata
Retention metadata

For example:

room: healthy
presence: available
storage: shared

or:

room: degraded
presence: unavailable
storage: degraded

That distinction matters.

A degraded database or realtime service does not necessarily mean a party has ended.

We explicitly distinguish states such as:

healthy
degraded
offline
ended
not-modeled

6. Why `not-modeled` Matters

At the time Z3 was implemented, the full production WebXR session lifecycle did not yet exist.

So Party Mode was not allowed to pretend that stage, media or portal state already existed.

Instead of saying:

{
  "stage": "offline"
}

we used the more accurate concept:

{
  "stage": "not-modeled"
}

This may seem like a small detail, but for AI-integrated software it is extremely important.

These are not equivalent:

false
offline
unknown
unavailable
not implemented

An AI orchestration layer should preserve those differences.

7. Z4 — Creator Capability Gateway

Once Party Mode could understand state, the next question was:

What should ZORGAX be allowed to do?

This became the Creator Capability Gateway.

Endpoints include:

GET /api/zorgax/party-capabilities
POST /api/zorgax/party-command

The model is:

Creator
   ↓
ZORGAX
   ↓
Capability Gateway
   ↓
Server-side Authorization
   ↓
Approved Action

The important part is that Party Mode does not receive unrestricted tool execution.

Capabilities are allowlisted.

The first implemented capabilities were deliberately small.

For example:

request_session_status
publish_notice

publish_notice requires elevated authorization and explicit confirmation.

We also introduced:

idempotency keys;
audit records;
bounded action scopes;
expiry semantics;
role checks.

At that stage the backend only had a concrete admin authorization model.

So instead of inventing a new creator role, mutating operations remained admin-gated until a richer role system exists.

8. Z5 — Moderation Assistance

Party Mode also needs trust and safety.

But the model is not:

AI detects something
       ↓
AI bans user

Instead:

Signal / Report
      ↓
ZORGAX
      ↓
Moderation Queue
      ↓
Human / Authorized Moderator
      ↓
Action

The first Party Mode moderation layer introduced:

POST /api/zorgax/party-reports
GET /api/zorgax/party-moderation-summary
POST /api/zorgax/party-moderation-action

Initially, supported moderator operations were intentionally limited to workflow actions such as:

mark-reviewed
escalate
dismiss

Permanent sanctions were not exposed to ZORGAX.

This keeps the AI in an assistance role rather than making it the final enforcement authority.

9. Z6 — Post-Event Archive Handoff

A social experience should not necessarily disappear when the live session ends.

We therefore added the post-event handoff model:

LIVE
 ↓
ENDED
 ↓
ARCHIVE
 ↓
REPLAY / HIGHLIGHTS
 ↓
COMMUNITY

Endpoints:

POST /api/zorgax/party-archive-handoff
GET /api/zorgax/party-archive

At that stage, the actual replay engine was not implemented yet.

So the API explicitly represented:

replayEngine: not-modeled

What we did implement was the important state boundary.

When archive handoff becomes active:

live-only capabilities expire;
public archive assets require approval;
asset consent must be verified;
unsafe URLs are rejected;
private/unlisted archive content is not exposed publicly.

This means a live capability such as:

publish_notice

should no longer remain valid once the event has transitioned into archive state.

10. Z7 — Safety and End-to-End Acceptance

The final Party Mode stage was a dedicated safety and acceptance gate.

The tests cover scenarios including:

identity spoofing;
private-field leakage;
prompt injection;
attempts to obtain secrets or private locations;
unauthorized creator commands;
missing confirmation;
idempotency replay;
unauthorized moderation actions;
unsafe archive URLs;
missing asset consent;
anonymous access to privileged routes;
degraded telemetry behavior.

We also documented the boundary between what Party Mode implements and what still depends on upstream infrastructure.

At that point, the ZORGAX Party Mode core reached:

Z1 PartyContext             ✅
Z2 Community Assistant      ✅
Z3 Telemetry Adapter        ✅
Z4 Capability Gateway       ✅
Z5 Moderation Assistance    ✅
Z6 Archive Handoff          ✅
Z7 Safety / E2E Gate        ✅

But some upstream product layers were still incomplete.

11. Building the Real Room/Session Lifecycle

The next major step was implementing the server-authoritative room/session lifecycle.

This work was tracked as:

MYZ-88

The system now models:

draft
 ↓
published
 ↓
scheduled
 ↓
live
 ↓
ended
 ↓
archive

We introduced persistent concepts such as:

VirtualRoom
VirtualSession

and server-side operations for:

room creation;
room updates;
session creation;
session start;
join;
leave;
session end;
short-lived session token issuance.

The lifecycle also supports:

access policy;
capacity limits;
allowlists;
blocklists;
host/admin checks;
scene manifest versioning.

12. Short-Lived Session Tokens

Joining a room does not mean handing a browser unlimited access.

Clients receive a short-lived realtime/session credential.

The principle is:

Authenticated browser
        ↓
Server checks room/session policy
        ↓
Short-lived token
        ↓
Realtime / session capability

This reduces the lifetime and scope of exposed credentials.

It also gives the backend a clean place to reject:

ended sessions;
blocked users;
full rooms;
unauthorized private-room access.

13. Persistent Lifecycle Event Stream

MYZ-88 also required reliable state broadcasting.

Instead of depending only on in-memory sockets, we implemented a persistent event stream.

Endpoint:

GET /api/metaverse/sessions/:id/events?after=<cursor>&limit=<n>

Events include:

session_created
session_started
participant_joined
participant_left
session_ended

Events are persisted in MongoDB.

Consumers poll incrementally using a cursor based on:

lifecycleVersion

This gives us:

resumability;
serverless compatibility;
ordering;
idempotent writes;
shared state across instances.

The public event payload remains aggregate-focused and does not expose:

participant account identifiers;
host IDs;
tokens;
chat;
movement history.

This persistent event stream is the authoritative state history.

WebSockets can later become a faster delivery mechanism, but they do not need to become the source of truth.

14. Moderation Foundation: Block, Mute, Report

After the room lifecycle was complete, we moved into deeper realtime safety.

The first moderation foundation introduced persistent interaction controls.

API surface:

POST /api/moderation/controls/:kind
POST /api/moderation/delivery-check
POST /api/moderation/reports
POST /api/moderation/actions
GET /api/moderation/events?after=<timestamp>

Supported control concepts include:

block
mute

We also introduced a server-side:

deliveryDecision()

hook.

This gives future messaging code a single policy boundary:

message candidate
      ↓
deliveryDecision()
      ↓
allowed / denied

That is better than duplicating block logic in every realtime transport.

15. Contextual Reports

Reports can carry bounded context relating to:

message
user
session

Inputs are sanitized and rate-limited.

The system also creates a durable moderation event/audit stream with a retention policy.

Moderator actions currently include concepts such as:

warn
remove_content
mute
suspend
escalate

Privileged operations are recorded.

The system is designed to fail closed when moderation storage is unavailable.

16. Why MYZ-82 Is Not Finished Yet

The moderation foundation exists, but full realtime enforcement depends on actual realtime messaging delivery.

Two upstream tasks are involved:

MYZ-78 — realtime gateway
MYZ-80 — direct messages and community channels

Without those layers, we cannot truthfully claim:

block/mute instantly affects all live socket delivery

or:

moderation.action propagates immediately to connected clients

The policy layer is ready.

The transport and messaging layer must now consume it.

17. MYZ-78 — Realtime Gateway and Socket Authentication

We are now implementing that missing transport layer.

The realtime gateway introduces:

POST /api/realtime/token

and a Socket.IO endpoint mounted at:

/realtime

Instead of sending the browser's normal JWT directly into a long-lived realtime session, the backend exchanges it for a dedicated short-lived realtime token.

Conceptually:

Browser JWT
    ↓
POST /api/realtime/token
    ↓
5-minute realtime token
    ↓
Socket.IO handshake

The realtime token includes dedicated checks for:

issuer;
audience;
purpose;
expiry.

18. Server-Side Channel Authorization

The gateway uses three planned namespace types:

user:{id}
community:{id}
session:{id}

Authorization happens on the server.

For user channels:

user:123

the authenticated user must be 123, unless a specific privileged policy says otherwise.

For session channels:

session:abc

the caller must be:

a participant;
the host;
or an authorized admin.

For community channels, authorization currently fails closed for normal users.

Why?

Because the authoritative community membership system belongs to MYZ-80 and is not implemented yet.

Rather than guessing membership:

community subscription denied

until the backend has a real authority source.

19. Reconnect Without Duplicate Presence

Realtime reconnect introduces another common distributed-system problem:

What happens when the browser reconnects?

The gateway uses a restore flow through:

realtime.resume

But subscriptions are not blindly restored.

Every requested channel is re-authorized.

Conceptually:

disconnect
   ↓
reconnect
   ↓
send previous subscriptions
   ↓
server re-authorizes every channel
   ↓
restore approved subscriptions

The gateway also does not directly mutate persistent presence during reconnect.

This helps prevent duplicate presence records.

20. Heartbeat and Connection Lifecycle

Socket.IO provides ping/pong heartbeat behavior.

The gateway also includes connection metadata and correlation identifiers useful for observability.

A ready event can include a request/session correlation ID so backend logs can associate:

token issuance
connection
subscription
resume
disconnect

without logging authentication secrets.

21. An Important Deployment Constraint

One major architectural point became clear during implementation:

Vercel serverless should not be treated as the production WebSocket host for this gateway.

The current MyZubster frontend and many HTTP APIs can continue using Vercel.

But a persistent Socket.IO/WebSocket service requires:

long-lived Node runtime

or a compatible managed realtime platform.

That means our architecture separates:

Frontend / serverless HTTP
        +
Persistent realtime transport

rather than pretending every deployment environment has the same connection model.

22. Current State

At the moment the architecture looks roughly like this:

                    MyZubster
                        │
            ┌───────────┴───────────┐
            │                       │
        Social Life              Metaverse
            │                       │
        Community                Neon Plaza
            │                       │
            └──────────┬────────────┘
                       │
                 Virtual Rooms
                       │
                 Live Sessions
                       │
             Persistent Event Stream
                       │
                  Realtime Gateway
                       │
       ┌───────────────┼───────────────┐
       │               │               │
   user:{id}     community:{id}   session:{id}
                       │
                  PartyContext
                       │
                    ZORGAX
                       │
       ┌───────────────┼───────────────┐
       │               │               │
   Telemetry        Commands       Moderation
                                       │
                                 Archive Handoff

23. What Still Needs to Be Built

There are still several important layers.

The immediate next sequence is:

MYZ-78
Realtime gateway
      ↓
MYZ-80
DM + community channels
      ↓
MYZ-82
Complete realtime moderation

After MYZ-80 exists, the gateway can authorize:

community:{id}

from real membership data.

Messaging can call:

deliveryDecision()

before persisting or emitting a message.

And moderation events can propagate immediately to the affected realtime clients.

24. The Longer-Term Architecture

Once these blocks are complete, the MyZubster Social Life experience moves closer to:

Community
   ↓
Event
   ↓
Virtual Twin / Neon Plaza
   ↓
Authenticated Realtime
   ↓
ZORGAX Party Mode
   ↓
Creator Actions
   ↓
Live Moderation
   ↓
Event Ends
   ↓
Archive / Replay
   ↓
Community

Eventually, additional systems can connect around the same authorization boundaries:

Identity
Marketplace
LIFE environmental projects
Robotics
Space Station
Creators
AI agents
Real-world data

25. The Main Engineering Lesson

The most important lesson from this work is not about AI.

It is about boundaries.

Every feature forced us to answer questions like:

Who is authoritative?

What can this component know?

What can this component do?

What happens when data is missing?

What happens when storage fails?

What happens after reconnect?

How long does a capability remain valid?

Who approved the action?

What is recorded in the audit trail?

The AI layer becomes safer and more useful when those answers exist before the prompt reaches the model.

That is the direction we're taking with ZORGAX.

Not:

AI controls everything

but:

Authoritative systems
        ↓
bounded context
        ↓
bounded capabilities
        ↓
AI orchestration
        ↓
auditable outcome

Links

MyZubster Metaverse:

https://www.myzubster.com/metaverse

MyZubster Space Station:

https://www.myzubster.com/space-station

GitHub:

https://github.com/MyZubster-Ecosystem/myzubster

Current development sequence

ZORGAX Party Mode Z1–Z7          ✅
Room/session lifecycle MYZ-88    ✅
Persistent lifecycle stream      ✅
Moderation foundation MYZ-82     ✅ partial
Realtime gateway MYZ-78          🚧 current
DM/community channels MYZ-80     ⏳ next
Realtime moderation completion   ⏳
Replay/highlights engine          ⏳

We're building the project publicly and deliberately separating production functionality, experimental infrastructure and roadmap ideas.

If you're working on realtime systems, WebXR, AI agents, authorization or multiplayer infrastructure, I'd be interested in your perspective:

Would you make the socket layer authoritative, or keep persistent state authoritative and treat realtime as a delivery optimization?

Building ZORGAX Party Mode: Giving Our Metaverse an Intelligent Orchestration Layer

Daniel Ioni — Sun, 06 Sep 2026 02:49:13 +0000

Building ZORGAX Party Mode: Giving Our Metaverse an Intelligent Orchestration Layer

We're building a new layer inside the MyZubster open-source ecosystem called ZORGAX Party Mode.

The idea sounds simple:

What if an AI system could understand the current state of a social/virtual experience without becoming an unrestricted agent with access to everything?

That's the engineering problem we're working on.

ZORGAX Party Mode is being designed as the orchestration layer connecting:

Community → Public Event → Virtual Twin → Live Session → Archive/Replay → Community

But we're deliberately building it one capability at a time.

No fake "AI-powered metaverse" claims.

No pretending roadmap features already exist.

Here's where we are.

What Is ZORGAX Party Mode?

ZORGAX is not intended to be just another chatbot inside a virtual world.

We're designing Party Mode as a bounded orchestration layer.

It should eventually understand things such as:

Which community is associated with an experience
Which public event is active
Which virtual room is involved
Whether a session is live
Whether infrastructure is healthy or degraded
Which creator actions are permitted
Which moderation workflows are available
What happens when a live experience becomes an archive

The important word is bounded.

ZORGAX does not become the authority for identity, authorization or unrestricted system access.

Those decisions remain server-side.

The Current Architecture

The current flow looks like this:

MyZubster Identity
        ↓
   PartyContext
        ↓
 Community Assistant
        ↓
 Room Telemetry
        ↓
 Creator Capabilities
        ↓
 Moderation
        ↓
 Archive / Replay

We're implementing this as seven development blocks:

Z1 — Party Context
Z2 — Community & Event Assistant
Z3 — Room/Session Telemetry
Z4 — Creator Commands
Z5 — Moderation Assistance
Z6 — Archive & Replay
Z7 — Safety + End-to-End Acceptance

The first two are now implemented and merged.

We're currently building Z3.

Z1 — PartyContext

The first problem was surprisingly fundamental.

Before an AI can help with an event or virtual environment, we need to answer:

What is it actually allowed to know?

We introduced a server-generated PartyContext.

Conceptually, it represents:

Actor
Community
Public Event
Room
Session
Capabilities
Restrictions

But it is intentionally not a dump of our database.

The server decides what enters the context.

Client claims are never automatically considered verified.

Sensitive/private information is excluded.

That means PartyContext does not become a convenient way of exposing:

Authentication tokens
Internal account IDs
Email addresses
Private keys
Raw session identifiers
Sensitive/private coordinates
Financial information
Permanent movement history

During our pre-merge review we actually caught an early version exposing an internal account identifier.

We removed it and added a regression test.

That's exactly why we're building this incrementally.

Z2 — A Grounded Community Assistant

Once PartyContext existed, we could build the first ZORGAX assistant.

The endpoint is currently:

POST /api/zorgax/party-assistant

The interesting part isn't that it can answer questions.

The interesting part is what happens when it doesn't know the answer.

For example, the production repository does not yet have the complete public-event data layer required for Party Mode.

So if someone asks:

Who is playing at the event?

ZORGAX doesn't invent a lineup.

It reports that authorized event information is unavailable.

Similarly, requests for private coordinates, account information or other restricted data are rejected by the Party Mode boundary.

This gives us a useful principle:

Missing context should produce "unavailable", not hallucinated product state.

That becomes increasingly important once an assistant can interact with live infrastructure.

Z3 — Teaching ZORGAX to Understand the Room

This is what we're implementing now.

Our current MyZubster Metaverse environment, Neon Plaza, already has shared presence infrastructure.

You can see it here:

https://www.myzubster.com/metaverse

Today it uses MongoDB-backed shared presence and a serverless-compatible polling model.

Presence records expire after 90 seconds.

We're now connecting this operational state to ZORGAX through a bounded telemetry adapter.

The new endpoint under development is:

GET /api/zorgax/party-telemetry

Instead of exposing individual users or raw session information, it produces operational information useful to Party Mode.

For example:

Room
 ├── health
 ├── transport
 ├── aggregate presence
 ├── storage state
 ├── reconnect information
 └── retention metadata

This allows ZORGAX to distinguish situations such as:

ROOM HEALTHY
     ↓
shared presence available
     ↓
Party Mode can report live state

from:

ROOM DEGRADED
     ↓
shared storage unavailable
     ↓
Party Mode reports degraded state

That's very different from simply saying:

"The party is offline."

Infrastructure degradation and an intentionally ended session are two different things.

ZORGAX needs to understand that distinction.

We Are Not Pretending WebXR Is Finished

This is another important part of how we're approaching the project.

Our roadmap includes:

WebXR rooms
3D environments
Spatial audio
Avatars
Live media
Stage state
Interactive portals
Virtual Twins

But the production room/session lifecycle required for all of those capabilities is not finished yet.

So our telemetry adapter does not invent those states.

Where a production model doesn't exist yet, Party Mode explicitly reports:

not-modeled

For example, stage/media/portal telemetry stays unavailable until the corresponding WebXR data layer exists.

This might seem like a small implementation detail.

I think it's actually an important architectural principle for AI-integrated products:

Your AI layer should know the difference between false, offline, unavailable and not implemented.

Those are four very different states.

Why Telemetry Matters for an AI Agent

Eventually, we want ZORGAX to answer questions like:

Is the room live?

How many participants are currently present?

Is the realtime service healthy?

Is the stage available?

Which portals are active?

Has this session ended?

Is there an archive available?

But those answers cannot come from an LLM guessing based on conversation history.

They need to come from authoritative system state.

The model can explain the state.

The infrastructure must provide the truth.

So we're separating:

SYSTEM STATE
      ↓
PartyContext / Telemetry
      ↓
ZORGAX reasoning
      ↓
Human-readable response

rather than:

User question
      ↓
LLM guesses what's happening

Privacy Is Part of the Telemetry Design

Telemetry can easily become surveillance if you don't define boundaries early.

For Party Mode, we're deliberately focusing on operational state rather than behavioral tracking.

The current design does not require ZORGAX to receive permanent movement history.

It doesn't need raw authentication tokens.

It doesn't need chat content in infrastructure logs.

It doesn't need to expose raw session identifiers.

And aggregate presence is usually enough for questions such as:

"How active is the room?"

rather than exposing unnecessary information about individual participants.

The objective is:

Give ZORGAX enough information to understand the experience without giving it everything the infrastructure knows.

What Comes Next: Z4 Creator Commands

Telemetry makes ZORGAX aware of the environment.

The next step will make it capable of performing bounded actions.

That's Z4.

We're designing a capability gateway where creator/host commands are explicitly allowlisted.

Conceptually:

Creator
   ↓
ZORGAX
   ↓
Capability Gateway
   ↓
Server Authorization
   ↓
Approved Action

Possible actions could eventually include:

publish approved notice
surface approved media
open configured portal
close configured portal
request session status
trigger approved room action

But the key is that ZORGAX does not receive unrestricted tool execution.

A command must pass server-side authorization.

Consequential actions can require confirmation.

Privileged actions must be auditable.

And certain capabilities remain outside Party Mode entirely without dedicated authorization.

Then Comes Moderation

Z5 will connect ZORGAX to trust and safety workflows.

The goal isn't:

AI automatically bans people.

Instead, ZORGAX can help surface signals and organize workflows.

For example:

spam signal
     ↓
ZORGAX
     ↓
report / moderation queue
     ↓
moderator
     ↓
review

Block and mute state should also affect what Party Mode surfaces.

Material enforcement decisions retain a human-review path.

What Happens After the Party?

This is one of the parts I'm most interested in.

A real or virtual experience doesn't necessarily have to disappear when the live session ends.

Z6 introduces the post-event transition:

LIVE
 ↓
ENDED
 ↓
ARCHIVE
 ↓
REPLAY / HIGHLIGHTS
 ↓
COMMUNITY

ZORGAX should understand that transition too.

Live-only commands must expire.

Approved media can become archive content.

The community can remain connected to the historical event.

That gives us the larger Social Life model we're working toward:

Community
   ↓
Public Event
   ↓
Physical Experience + Virtual Twin
   ↓
ZORGAX Party Mode
   ↓
Live Social Experience
   ↓
Archive / Replay
   ↓
Community

The party ends.

The community doesn't have to.

The Final Gate: Z7

Before calling Party Mode complete, we're planning an end-to-end safety and acceptance phase.

That includes testing scenarios such as:

Identity spoofing
Unauthorized creator commands
Restricted/private data requests
Expired capability replay
Prompt/context injection
Audit completeness
Retention boundaries
Logging boundaries
Safe degradation when infrastructure fails

The complete test path should eventually look like:

Public Event
    ↓
PartyContext
    ↓
Assistant
    ↓
Room Telemetry
    ↓
Authorized Creator Action
    ↓
Moderation / Reporting
    ↓
Event Ends
    ↓
Archive / Replay

Only then does Party Mode become a complete system rather than a collection of AI demos.

Where We Are Today

So the current status is:

Z1 PartyContext             ✅ merged
Z2 Community Assistant      ✅ merged
Z3 Telemetry Adapter        🚧 in development
Z4 Creator Commands         ⏳ next
Z5 Moderation               ⏳
Z6 Archive / Replay         ⏳
Z7 Safety + E2E             ⏳

The Z3 implementation is currently being developed against the real Neon Plaza infrastructure available today.

We are deliberately not marking future WebXR functionality as complete before the underlying room/session models exist.

The Bigger Idea

The long-term goal isn't simply to put an AI chatbot inside a metaverse.

We're exploring a different model:

AI as a bounded orchestration layer between community, software and shared digital environments.

Eventually the wider MyZubster ecosystem could connect:

People
+
Communities
+
AI Agents
+
Metaverse
+
Creators
+
Robotics
+
Real-world data

But each connection needs an authority boundary.

Who knows what?

Who can do what?

Who authorized the action?

What gets logged?

How long does the data live?

What happens when a service fails?

Those questions are less exciting than saying "AI Metaverse."

They're also the questions that determine whether the system can actually work.

We're building those foundations now.

MyZubster Metaverse / Neon Plaza

https://www.myzubster.com/metaverse

MyZubster Space Station

https://www.myzubster.com/space-station

Open-source repository

https://github.com/MyZubster-Ecosystem/myzubster

If you're working on AI agents, WebXR, realtime systems, authorization or virtual-world infrastructure, I'd be interested in your perspective:

How much operational context should an AI agent receive before context itself becomes a security boundary?

opensource #ai #webdev #metaverse

Building Social Life: From a Metaverse Concept to an Execution-Ready Product Roadmap

Daniel Ioni — Sun, 06 Sep 2026 02:17:24 +0000

Building Social Life: From a Metaverse Concept to an Execution-Ready Product Roadmap

Over the last development cycle, we moved Social Life / MyZubster Metaverse from a broad concept into a structured, execution-ready product roadmap.

The vision is ambitious but simple to explain:

Connect social communities, real-world cultural experiences, creators, and persistent digital spaces through an open, browser-accessible metaverse layer.

Instead of treating the metaverse as a separate destination, Social Life is being designed as part of the social experience itself.

A community can exist in the feed, organize a public cultural event, open a virtual twin of that experience, meet inside a WebXR environment, communicate in real time, and preserve parts of the experience as an archive or replay.

Here's what we've built and defined so far.

1. The Product Architecture

The first major step was turning the concept into an actual technical architecture.

The current direction is based on:

Next.js / React
TypeScript
PostgreSQL
Redis
Object storage + CDN
WebSockets for presence and realtime messaging
WebRTC / SFU for live media
Three.js or Babylon.js
WebXR for immersive environments

The key architectural decision is that the metaverse is not a separate application.

It is another surface of the Social Life platform.

Users move between:

Feed → Communities → Events → Rooms → Live Sessions → Archives

while maintaining the same identity, permissions and social graph.

2. Social Foundation

The first development phase focuses on the social platform itself.

We broke this into eight implementation areas:

Database schema
Authentication and session security
Profiles and onboarding
Social graph
Communities and permissions
Posts, comments and reactions
Personalized Feed and Discover
End-to-end and API contract testing

The onboarding flow is designed around:

Handle → Avatar → Interests → Privacy → Recommendations → Feed

Privacy is part of onboarding rather than something hidden deep inside settings.

The initial social graph and community layer then become the foundation for everything else.

3. Realtime Social Layer

Once the social foundation is available, Social Life becomes realtime.

The architecture includes a WebSocket gateway with short-lived authentication tokens and channels representing:

Users
Communities
Virtual sessions

The realtime layer covers:

Presence
Direct messaging
Community channels
Notifications
Block and mute
Reporting
Moderation
Rate limiting
Anti-spam controls
Realtime observability

Server-side authorization remains authoritative.

A client cannot simply claim that a user belongs to a community or has permission to join a protected session.

4. The WebXR Metaverse

This is where the project becomes particularly interesting.

We decomposed the metaverse into eight engineering areas:

WebXR Runtime

The browser becomes the primary runtime.

Users should be able to enter an environment from a modern browser without installing a dedicated metaverse client.

XR devices receive the immersive experience, while desktop and mobile users get a compatible non-XR version.

Scene Manifest

Virtual environments use versioned scene manifests.

Assets can be distributed through the existing CDN pipeline, with formats such as glTF forming the basis of the 3D asset workflow.

Avatars

Users receive lightweight avatars connected to the same Social Life identity.

Avatar transforms and presence are synchronized through the realtime layer.

Room Lifecycle

Rooms follow an explicit lifecycle:

Draft → Published → Scheduled → Live → Ended → Archive

This makes virtual spaces manageable as actual product objects instead of arbitrary 3D worlds.

Spatial Media

Live environments combine:

Spatial audio
WebRTC
SFU infrastructure
Stage audio/video
Media screens

Interactive Environments

Rooms can contain:

Portals
Media surfaces
Interactive zones
Social spaces
Stage areas

Performance

Performance budgets, LOD strategies and graceful degradation are part of the architecture from the beginning.

A metaverse experience that only works on expensive hardware isn't the product we're trying to build.

5. Physical Experiences Meet Virtual Twins

Another major part of the roadmap connects public cultural events with virtual spaces.

A creator or community can publish a public event and optionally associate it with a virtual room.

The lifecycle becomes:

Public Event → Virtual Twin → Live Session → Replay / Archive

This creates an interesting bridge between physical and digital culture.

Someone unable to attend physically may still participate through the virtual environment.

Afterwards, the experience can continue through highlights, media and archived virtual spaces.

Importantly, the public event architecture is intentionally designed around lawful, intentionally public event information.

The platform does not require concealed or sensitive real-world coordinates or covert logistics.

Privacy and safety validation are explicit parts of the event model.

6. Creator Studio

Creators and community administrators need their own operational layer.

The roadmap therefore includes a Creator Studio where authorized users can:

Manage communities
Create public events
Publish virtual rooms
Attach rooms to events
Manage sessions
Control archives
Manage media
Review engagement

This turns the metaverse from something developers manually construct into something communities can eventually operate themselves.

7. Creator Economy — But Not Yet

We also designed the next-stage creator economy.

Possible capabilities include:

Memberships
Community subscriptions
Digital goods
Avatar cosmetics
Room decorations
Paid virtual sessions
Creator/community revenue sharing
Platform fees

But we deliberately placed a gate before implementation.

Before production payments or payouts are introduced, the project requires review covering:

Legal requirements
Consumer protection
Refunds and cancellations
Tax and VAT
Creator payouts
KYC requirements where applicable
Payment-provider requirements
Financial-data privacy

Only after that review does the roadmap reach a formal:

GO / NO-GO

decision.

Another important architectural choice:

The MVP does not require a custom blockchain or speculative token.

Digital ownership and entitlements can initially be represented through normal server-side records.

Blockchain should only enter the architecture if a future use case genuinely requires it.

8. From Documents to an Engineering Backlog

One of the biggest changes wasn't technical.

It was organizational.

We converted the architecture into a structured Linear roadmap.

The project is now divided into five milestones:

Milestone A — Social Foundation

Identity, profiles, communities, content and discovery.

Milestone B — Realtime Social

Presence, messaging, notifications and moderation.

Milestone C — WebXR Metaverse

Rooms, avatars, scenes, live media and interactions.

Milestone D — Public Events & Virtual Twins

The bridge between public physical experiences and virtual environments.

Milestone E — Creator Economy Gate

Business-model validation, payments architecture and compliance review.

Across those phases, the architecture has been decomposed into implementation-level issues with acceptance criteria and dependencies.

9. The First Execution Block

The first candidate development block is intentionally not the flashy metaverse part.

It starts with:

Database → Authentication → Profiles → Social Graph

That foundation matters.

Before building immersive rooms, we need to know:

Who is the user?

What can they access?

Who do they follow?

Which communities do they belong to?

What privacy rules apply?

What happens when access is revoked?

Once identity and authorization are reliable, realtime communication and immersive environments can safely build on top of them.

10. What Social Life Is Becoming

The original idea started around connecting digital culture, social communities and immersive experiences.

The architecture now looks more like this:

Identity

↓

Social Graph

↓

Communities

↓

Content & Discovery

↓

Realtime Communication

↓

Public Experiences

↓

WebXR Spaces

↓

Virtual Twins

↓

Creator Tools

↓

Creator Economy

The important part is that these aren't separate products.

They share one identity system, one permission model, one social graph and one community layer.

That's the architecture we're now building toward.

What's Next

The next stage is implementation.

The immediate engineering sequence starts with the Social Foundation before moving progressively into realtime infrastructure and WebXR.

We'll continue sharing the technical decisions behind the project as the architecture moves from Linear issues to running code.

Social Life / MyZubster Metaverse is moving from concept to build.

And now the roadmap is ready.

From Social Networks to an Open Network: What We Are Building with MyZubster

Daniel Ioni — Sat, 05 Sep 2026 15:36:37 +0000

From Social Networks to an Open Network: What We Are Building with MyZubster

Over the last few days, we have been doing something important with MyZubster.

Not simply advertising a website.

We started taking the architecture and philosophy of the project outside GitHub and explaining it directly to communities through social networks.

In particular, we opened a conversation around free-party culture, underground communities, DIY infrastructure, open source, GitHub, Docker, the Metaverse, circular economy and digital independence.

And something became increasingly clear:

MyZubster is evolving from a collection of projects into a connected ecosystem.

Why talk about MyZubster in underground communities?

Free-party and underground cultures have historically understood something that is extremely relevant to technology today:

If the infrastructure you need does not exist, build it.

People built sound systems.

Vehicles became workshops.

Temporary spaces became cultural spaces.

Artists, technicians, makers and communities created networks without waiting for a centralized institution to create them first.

Information moved through flyers, telephone numbers, word of mouth, forums, mailing lists and eventually social media and messaging platforms.

In many ways, these communities were already distributed networks.

With MyZubster, we are asking a new question:

Can the same DIY philosophy be applied to digital infrastructure?

From DIY Culture to Open Source

This is the connection we started explaining publicly:

DIY CULTURE
     ↓
OPEN SOURCE
     ↓
GITHUB
     ↓
SELF-HOSTING
     ↓
DOCKER
     ↓
INDEPENDENT NODES
     ↓
MYZUBSTER NETWORK

Instead of asking people only to become users of another platform, we want to explore whether communities can gradually become operators of their own digital infrastructure.

GitHub is therefore not just where the code is stored.

It is part of the architecture.

People can inspect the project, understand its evolution, report problems, propose changes, fork code and contribute through pull requests.

MyZubster repository:

https://github.com/MyZubster-Ecosystem/myzubster

Social Networks Are Channels, Not the Network

This was one of the central ideas we shared.

Facebook, Telegram, Instagram and other platforms are extremely useful for reaching people.

We are using them too.

But a community should not necessarily have to place its entire identity, history and infrastructure inside a single commercial platform.

Our model is closer to this:

                 COMMUNITY
                     │
                     ↓
                  MYZUBSTER
                     │
       ┌─────────────┼─────────────┐
       ↓             ↓             ↓
     GITHUB       METAVERSE     INFOPOINT
       │             │             │
       └─────────────┼─────────────┘
                     ↓
               SOCIAL CHANNELS
                     │
        ┌────────────┼────────────┐
        ↓            ↓            ↓
     Facebook     Telegram     other channels

The social network becomes a distribution channel.

The community remains the actual network.

What Does the MyZubster Metaverse Do?

We also explained that our idea of a Metaverse is not about replacing physical culture.

A free party, workshop, cultural gathering or community project happens in the real world.

That matters.

The Metaverse can instead become a persistent digital map connecting what exists around those experiences.

For example:

PHYSICAL EVENT
      ↓
ARTISTS
      ↓
CULTURAL DOCUMENTATION
      ↓
WORKSHOPS
      ↓
MATERIALS
      ↓
INFOPOINT
      ↓
METAVERSE

The physical event may last one night.

The knowledge generated around it does not have to disappear the next morning.

Documentation, artist profiles, visual material, technical knowledge, projects and connections can remain accessible.

That is the role we are exploring for the MyZubster Metaverse.

Events Become Structured Information

Another part of the system is the event layer.

Instead of treating an event as only a flyer containing a date and location, we can represent it as structured information:

EVENT
├── artists
├── sound
├── visual / flyer
├── public information
├── Telegram
├── location state
├── welfare
├── hospitality
├── workshops
└── materials

Once information has been validated and authorized, different interfaces can use the same source.

                 EVENT DATA
                     ↓
                  MYZUBSTER
                     ↓
       ┌─────────────┼─────────────┐
       ↓             ↓             ↓
     WEBSITE      METAVERSE     INFOPOINT
       ↓             ↓             ↓
     SOCIAL       TELEGRAM        BOT

This reduces duplicated work.

More importantly, it creates a common information layer.

The Infopoint

Imagine arriving at a cultural event and scanning a QR code.

Instead of finding only a promotional page, the MyZubster Infopoint could eventually connect you to:

artists;
timetable;
workshops;
cultural documentation;
welfare information;
public transport information;
recycling instructions;
Marketplace resources;
Telegram;
Metaverse spaces;
contributor pages.

The same Infopoint can have a digital counterpart inside the Metaverse.

REAL WORLD
    ↕
INFOPOINT
    ↕
MYZUBSTER
    ↕
METAVERSE

One information architecture connecting two environments.

Then Comes the Circular Marketplace

This is where another part of MyZubster starts connecting to cultural infrastructure.

Events consume physical resources.

Timber.

Metal.

Electronics.

Lighting.

Cables.

Furniture.

Decoration.

Fabric.

Construction elements.

Many DIY communities already have a strong tradition of recovering, repairing and transforming materials.

Why not connect that process digitally?

RECOVERED MATERIAL
       ↓
CIRCULAR MARKETPLACE
       ↓
MAKER / ARTIST / COMMUNITY
       ↓
CULTURAL PROJECT
       ↓
EVENT
       ↓
RECOVERY
       ↓
NEXT PROJECT

Instead of treating an object as disposable, we can start thinking about its lifecycle.

Where did it come from?

Was it repaired?

Where was it used?

Can it be reused?

Can its provenance be documented?

That creates a bridge between culture and circular economy.

GitHub Becomes Public Memory

There is another reason GitHub is important.

It creates a trace.

A change can become:

IDEA
 ↓
BRANCH
 ↓
COMMIT
 ↓
PULL REQUEST
 ↓
REVIEW
 ↓
MERGE
 ↓
PUBLIC HISTORY

We have been using exactly this workflow while expanding MyZubster.

A recent small example was the contributor profile work around Yassen Mainardi.

We generated a dedicated visual, added it to the main MyZubster repository, created a pull request, cleaned the branch when we found an unrelated asset inside it, merged the corrected contribution and then connected the visual to Yassen's identity documentation.

That may sound like a small operation.

Architecturally, however, it demonstrates an important principle:

identity changes should leave a trace.

Consent Matters

The Yassen workflow also exposed another important distinction.

Human authorization and technical authorization are not the same thing.

Yassen explicitly communicated that he approved automatic compilation/work by Zorgax.

But his personal GitHub repository still does not currently expose write access through the GitHub connection we are using.

That means:

HUMAN CONSENT
      ≠
TECHNICAL PERMISSION

Both are necessary.

We therefore contacted him with instructions for granting the required repository permission.

And we deliberately did not ask him to send passwords, personal access tokens or 2FA codes.

This is part of the governance model we want:

AI CAN PREPARE
AI CAN ORGANIZE
AI CAN PROPOSE
AI CAN AUTOMATE

BUT

IDENTITY
CONSENT
PERMISSIONS
PUBLICATION
SENSITIVE ACTIONS

REMAIN HUMAN-GOVERNED

Where Zorgax Fits

Zorgax is becoming the coordination layer between these components.

Not an autonomous ruler of the ecosystem.

A tool for helping humans manage complexity.

For example:

                  ZORGAX
                     │
       ┌─────────────┼─────────────┐
       ↓             ↓             ↓
   DOCUMENTATION   GITHUB        EVENTS
       ↓             ↓             ↓
   EVIDENCE       PROFILES       INFOPOINT
       │             │             │
       └─────────────┼─────────────┘
                     ↓
                 MYZUBSTER

The AI can help classify information, prepare documentation, detect missing elements, organize contributions and connect different parts of the ecosystem.

Humans retain authority over consequential actions.

Docker and Digital Independence

We also introduced another idea to the community:

you should eventually be able to run infrastructure yourself.

This is where Docker becomes interesting.

The conceptual model is:

YOUR COMPUTER
      ↓
    DOCKER
      ↓
OPEN-SOURCE SERVICES
      ↓
YOUR NODE
      ↓
OPTIONAL CONNECTION
      ↓
MYZUBSTER ECOSYSTEM

Digital independence does not mean disconnecting from everyone.

It means having more choices.

Being able to inspect your software.

Being able to run it.

Being able to back it up.

Being able to modify it.

Being able to move it.

And being able to decide what you connect to the wider network.

The long-term idea is therefore not:

ONE PLATFORM
     ↓
EVERY COMMUNITY

but potentially:

COMMUNITY A ── NODE A ──┐
                        │
COMMUNITY B ── NODE B ──┼── OPEN NETWORK
                        │
MAKERSPACE ─── NODE C ──┤
                        │
PROJECT D ──── NODE D ──┘

Independent nodes.

Shared protocols.

Voluntary interconnection.

Why the Free-Party Connection Matters

This is why the conversation with underground and free-party communities is interesting.

There is a cultural similarity between:

building your own sound system

and

running your own server.

Between:

creating an independent event infrastructure

and

creating an independent digital node.

Between:

sharing technical knowledge inside a DIY community

and

sharing code through open source.

The technologies are different.

The principle is surprisingly similar.

A Note About Spiral Tribe and Other Historical Communities

We have also discussed cultural references connected to Spiral Tribe/SP23 and the wider underground/free-party history.

It is important to be precise here.

MyZubster is not claiming an official partnership, endorsement, representation or membership relationship with Spiral Tribe/SP23, Mutoid Waste, Bedlam or other historical collectives unless such a relationship is explicitly established and verifiable.

We are documenting and exploring cultural connections, personal testimony, DIY principles and historical influences.

That distinction matters.

Open infrastructure also requires accurate provenance.

Culture deserves the same standard.

What Did We Actually Do on Social Media?

So what happened when we started sharing all of this?

We did not "connect the entire rave community to MyZubster."

That would be an unsupported claim.

What we actually did was much more concrete:

we introduced the architecture to the community and opened the possibility of participation.

The sequence is now:

SOCIAL POST
     ↓
COMMUNITY DISCOVERY
     ↓
INTEREST
     ↓
MYZUBSTER
     ↓
GITHUB
     ↓
CONTRIBUTION
     ↓
OPTIONAL LOCAL NODE
     ↓
INTERCONNECTION

The next evidence we need is adoption.

Someone reading the post.

Someone visiting the project.

Someone opening the repository.

Someone contributing.

Someone running the software.

Someone creating an independent node.

Someone connecting a real cultural or circular project.

That is when communication becomes infrastructure.

MyZubster Is Becoming a System of Systems

The architecture now looks increasingly like this:

                         MYZUBSTER
                             │
              ┌──────────────┼──────────────┐
              ↓              ↓              ↓
           PEOPLE         CULTURE        PROJECTS
              │              │              │
              └──────────────┼──────────────┘
                             ↓
                     DIGITAL IDENTITY
                             ↓
                          ZORGAX
                             ↓
        ┌────────────────────┼────────────────────┐
        ↓                    ↓                    ↓
      GITHUB              METAVERSE          MARKETPLACE
        │                    │                    │
   OPEN SOURCE           INFOPOINT         CIRCULARITY
        │                    │                    │
        └────────────────────┼────────────────────┘
                             ↓
                       SOCIAL / BOTS
                             ↓
                       PHYSICAL WORLD
                             ↓
                  EVENTS / MATERIALS / PILOTS
                             ↓
                          EVIDENCE
                             │
                             └──────────→ MYZUBSTER

This is why MyZubster is becoming difficult to describe as simply a website.

It is moving toward an open coordination infrastructure connecting digital identity, communities, culture, circular materials, AI, GitHub and the physical world.

What Comes Next?

The challenge now is not adding endless new concepts.

The challenge is making the existing pieces work together.

A meaningful test would look like this:

PERSON
  ↓
MYZUBSTER IDENTITY
  ↓
COMMUNITY
  ↓
EVENT / PROJECT
  ↓
METAVERSE + INFOPOINT
  ↓
CIRCULAR MATERIAL
  ↓
REAL-WORLD USE
  ↓
DOCUMENTED EVIDENCE
  ↓
PUBLIC CONTRIBUTION

And another important test would be:

COMMUNITY
   ↓
CLONE GITHUB
   ↓
DOCKER
   ↓
RUN LOCALLY
   ↓
CREATE OWN NODE
   ↓
CONNECT VOLUNTARILY

If external people can complete those flows without depending on the original developers for every step, we will have moved from an ambitious ecosystem toward something much more important:

replicable infrastructure.

Social networks helped us start the conversation.

GitHub gives the conversation a technical home.

Docker can give communities operational independence.

The Metaverse can give the network a spatial interface.

The Circular Marketplace can connect physical resources.

Zorgax can help coordinate information.

And humans remain responsible for identity, consent and real-world decisions.

Build locally.
Connect globally.
Document everything.
Keep humans in control.

🌍 MyZubster
https://myzubster.com

💻 GitHub
https://github.com/MyZubster-Ecosystem/myzubster

🌐 MyZubster Comic Universe
https://myzubster.com/fumetto.html

opensource #github #docker #metaverse #selfhosting #diy #freeparty #soundsystem #circulareconomy #community #ai #myzubster

From Free-Party Culture to a Circular Metaverse: Building the MyZubster Cultural Network

Daniel Ioni — Sat, 05 Sep 2026 14:56:20 +0000

From Free-Party Culture to a Circular Metaverse: Building the MyZubster Cultural Network

What happens when the philosophy of DIY sound systems, free-party culture, independent art, recycling, digital identity, social networks and AI-assisted coordination meet inside the same open-source ecosystem?

That is one of the experiments we are building with MyZubster.

The idea is not to digitize a free party and replace the physical experience with a virtual world.

The opposite.

The idea is to build a digital infrastructure that can help independent cultural communities connect:

people
artists
sound systems
venues
materials
recycled products
workshops
cultural events
marketplaces
information points
social channels
bots
digital identities
environmental evidence
physical places
Metaverse spaces

into one interoperable network.

The starting point is culture.

The destination is infrastructure.

The DIY and free-party connection

Free-party and sound-system cultures historically developed around a very particular idea:

if the infrastructure does not exist, build it.

Sound systems were assembled.

Generators were found.

Vehicles became workshops.

Old industrial materials became stages.

Warehouses became temporary cultural spaces.

People shared technical knowledge outside traditional institutions.

Art, engineering, music, mechanics and community mixed together.

MyZubster documents a cultural dialogue around this historical DIY ecosystem, including personal testimony connected to people and scenes associated with Spiral Tribe, Mutoid Waste and Bedlam.

This is cultural documentation and personal testimony.

It is not an official affiliation, membership claim, endorsement or partnership with those collectives.

Repository documentation:

https://github.com/MyZubster-Ecosystem/myzubster/tree/main/docs/culture

From sound-system networks to digital networks

The interesting part is not nostalgia.

It is the architecture.

A traditional independent event already behaves like a distributed system.

ARTISTS
   │
SOUND SYSTEM
   │
CREW
   │
VEHICLES
   │
LOCATION
   │
ENERGY
   │
MATERIALS
   │
COMMUNICATION
   │
COMMUNITY

Today we can extend this model.

ARTISTS
   │
SOUND / CULTURAL CREWS
   │
EVENT SYSTEM
   │
METAVERSE
   │
CIRCULAR MARKETPLACE
   │
RECYCLED MATERIALS
   │
SOCIAL NETWORKS
   │
TELEGRAM / BOTS
   │
INFOPOINT
   │
EVIDENCE + PROVENANCE

This is the cultural layer MyZubster is exploring.

The MyZubster Metaverse as a cultural map

The MyZubster Metaverse is not intended only as a collection of avatars.

It can become a navigable map of communities and resources.

A cultural space could have its own virtual room or district containing:

its history
visual archives
artists
sound-system documentation
event information
public links
Marketplace products
circular materials
workshops
related projects
physical-event information
contribution opportunities

The repository already contains a neutral subculture profile model intended not only for Spiral Tribe-related documentation but also for independent sound systems, free-party communities, teknival scenes, punk/DIY networks, maker cultures, art collectives and other contributor-defined subcultures.

Documentation:

https://github.com/MyZubster-Ecosystem/myzubster/blob/main/docs/culture/ZORGAX-SUBCULTURE-PROFILES.md

The important principle is that the system should represent culture without inventing relationships.

An artist profile is not automatically membership.

A historical reference is not endorsement.

A visual is not evidence of partnership.

A possible cultural journey

Imagine entering the Metaverse and finding an independent cultural district.

METAVERSE DISTRICT
       ↓
SUBCULTURE PROFILE
       ↓
ARTISTS / CREWS
       ↓
MUSIC / VISUAL ARCHIVE
       ↓
UPCOMING EVENT
       ↓
INFOPOINT
       ↓
MARKETPLACE
       ↓
RECYCLED MATERIALS
       ↓
REAL-WORLD CULTURAL ACTIVITY

The Metaverse becomes an interface connecting information that already exists across different systems.

It does not need to replace websites, Telegram or social networks.

It can connect them.

Events as modular systems

Inside MyZubster, cultural events are being modeled as modular entities.

The architecture already separates modules such as:

events/
├── sound/
├── artists/
├── flyer/
├── telegram/
├── location/
├── welfare/
└── hospitality/

This is important because an event is more than a date and a location.

An event can be represented as a system.

Documentation:

https://github.com/MyZubster-Ecosystem/myzubster/blob/main/docs/culture/ZORGAX-MODULAR-FREE-PARTY-OPERATIONS.md

The event model can include things like:

title
artists
sound
visual identity
flyer
information channels
welfare resources
hospitality
organizer information
location state
publication state

That means one event object could eventually feed multiple surfaces.

EVENT DATA
    │
    ├── Website
    ├── Metaverse
    ├── Telegram
    ├── Social post
    ├── Infopoint
    └── Public API

One source.

Many interfaces.

Telegram and the digital infopoint

Traditional free-party culture often relied on decentralized information channels.

Phone calls.

Flyers.

Word of mouth.

Mailing lists.

Forums.

SMS.

Then social networks and messaging platforms.

MyZubster explores a modern version of the same principle.

The documented cultural discovery flow already contains:

ARTIST / CREW
      ↓
FLYER
      ↓
TELEGRAM / INFO POINT
      ↓
EVENT

Documentation:

https://github.com/MyZubster-Ecosystem/myzubster/blob/main/docs/culture/ZORGAX-TEKNO-TRIBES-ARTIST-DISCOVERY.md

Telegram can therefore become one channel among several.

A bot could help distribute authorized public information such as:

event announcement
time
public meeting point
lineup
workshop
transport information
venue rules
welfare information
schedule changes
recycling instructions
links to Marketplace resources

The system should never publish private or sensitive locations automatically.

Physical events require organizer authorization, legal compliance, appropriate permissions and safety controls.

The social-network bridge

The next logical layer is social distribution.

Instead of manually rewriting the same event announcement ten times, a validated event object can become the source for multiple outputs.

CULTURAL EVENT
      ↓
STRUCTURED DATA
      ↓
ZORGAX
      ↓
┌──────────┬──────────┬──────────┐
│ Telegram │ Website  │ Metaverse│
├──────────┼──────────┼──────────┤
│ Social   │ Infopoint│ API      │
└──────────┴──────────┴──────────┘

Zorgax can help prepare the information.

Humans retain publication authority.

The bot should not invent artists.

It should not invent locations.

It should not invent partnerships.

It should distribute information coming from an authorized source.

Circular materials for cultural events

This is where the system becomes especially interesting.

Events consume materials.

For example:

timber
metal
cables
fabrics
barriers
furniture
signage
lighting structures
stage elements
decoration
containers
reusable cups
repair components

Many cultural scenes already reuse materials informally.

The Circular Marketplace can make this flow more visible and traceable.

The MyZubster Metaverse already contains a Circular Marketplace direction where visitors can move between sellers, manufacturers, producers, community contributors and recycling operators, discover items and follow their circular lifecycle.

Documentation:

https://github.com/MyZubster-Ecosystem/myzubster/blob/main/docs/metaverse/CIRCULAR-MARKETPLACE-WORLD.md

Imagine building a stage through the Circular Marketplace

An event organizer could search for:

RECOVERED TIMBER
      +
REUSED METAL
      +
SECOND-HAND LIGHTING
      +
REPAIRED CABLES
      +
RECYCLED DECORATION

Instead of treating them only as products, the ecosystem could connect every object to its lifecycle.

ORIGINAL MATERIAL
      ↓
RECOVERY
      ↓
REPAIR / TRANSFORMATION
      ↓
MARKETPLACE LISTING
      ↓
CULTURAL EVENT USE
      ↓
RECOVERY AGAIN

This is the circular-economy connection.

A stage does not necessarily become waste after one night.

A decoration does not necessarily need to be produced again.

A cable does not automatically need replacing.

A piece of metal can move through multiple cultural projects.

The Marketplace can help record that movement.

Circular passports

A particularly useful concept is the circular item passport.

A material or object could carry structured information describing:

what it is
origin
material
repair history
previous use
current owner or custodian
Marketplace history
recovery route
future reuse

For example:

WOOD PANEL #A120
      ↓
Recovered from previous installation
      ↓
Marketplace listing
      ↓
Used for cultural stage
      ↓
Returned to material pool
      ↓
Used for community workshop

The object becomes part of the story.

Not only the event.

Culture and recycling can reinforce each other

This creates a possible circular cultural economy.

RECYCLING OPERATOR
       ↓
RECOVERED MATERIAL
       ↓
MYZUBSTER MARKETPLACE
       ↓
ARTIST / MAKER / CREW
       ↓
EVENT INSTALLATION
       ↓
CULTURAL USE
       ↓
RECOVERY
       ↓
NEW PROJECT

A maker could discover materials.

A sound-system crew could find repair components.

An artist could find recycled construction material.

A workshop could teach how to transform it.

An event could expose the provenance publicly.

A recycling operator could show where recovered materials went.

Makers and workshops

The same infrastructure can connect cultural events with practical education.

An event does not need to contain only music.

It can contain:

repair workshops
electronics
speaker building
woodworking
metal fabrication
recycling labs
visual arts
permaculture
environmental education
open-source software
digital identity
AI workshops

The Metaverse can maintain a persistent version of those activities.

Someone discovers a workshop virtually.

They participate physically.

They later contribute documentation.

The documentation becomes reusable by another community.

DISCOVER
   ↓
LEARN
   ↓
BUILD
   ↓
DOCUMENT
   ↓
SHARE
   ↓
REPLICATE

That is much closer to the original DIY spirit than simply selling digital collectibles.

Artists and digital identities

Artists and contributors can also have persistent identities.

Nicola / N4K48 is one example of how MyZubster is experimenting with a character identity connected to a contributor journey.

A similar model could eventually work for:

DJs
live performers
VJs
technicians
sound engineers
makers
visual artists
photographers
researchers
recycling contributors

An identity could link:

PROFILE
  +
PUBLIC WORK
  +
EVENTS
  +
CONTRIBUTIONS
  +
METAVERSE SPACE
  +
MARKETPLACE

But again:

identity must be attributable.

The system should not assign a person to a crew without evidence or consent.

The Infopoint

One of the most interesting concepts is the Infopoint.

Think of it as a bridge between the physical and digital event.

A physical event might contain a QR/NFC/public terminal.

Scanning it could open:

EVENT INFOPOINT

→ lineup
→ timetable
→ cultural history
→ artists
→ workshops
→ welfare
→ recycling
→ Marketplace
→ transport
→ Metaverse
→ Telegram
→ contributor page

The same Infopoint could exist inside the Metaverse.

One identity.

Two worlds.

PHYSICAL EVENT
      ↕
   INFOPOINT
      ↕
METAVERSE

Bots as connectors, not rulers

Bots are useful when they remove repetitive work.

For example:

Organizer creates event
        ↓
Human validates
        ↓
Zorgax structures data
        ↓
Telegram bot prepares message
        ↓
Social content prepared
        ↓
Metaverse event card updated
        ↓
Infopoint updated

But MyZubster's governance model is deliberately human-gated.

Bots can:

prepare
classify
synchronize
notify
recommend

Humans should retain control over:

publication
sensitive locations
legal commitments
partnerships
financial actions
real-world activation

Welfare and safety

A modern cultural infrastructure also needs to make welfare visible.

An event information system can include:

water information
weather information
accessibility
emergency contacts
medical/welfare point
hearing protection
transport information
waste separation
environmental rules

The objective is not to control independent culture.

It is to make useful information easier to find.

Privacy-first event locations

Free-party culture has historically had a complicated relationship with location information.

A digital system needs to handle that carefully.

The architecture should distinguish:

PUBLIC EVENT LOCATION

AUTHORIZED PARTICIPANT LOCATION

APPROXIMATE AREA

PRIVATE LOCATION

NOT YET RELEASED

A bot should never decide to expose a private location automatically.

The organizer controls the publication state.

That same principle applies to participant data.

The Cultural Graph

The larger vision is what we could call a Cultural Graph.

                    MYZUBSTER

        ┌──────────────┼──────────────┐
        ↓              ↓              ↓
     CULTURE        METAVERSE      MARKETPLACE
        │              │              │
   ┌────┼────┐         │         ┌────┼────┐
   ↓    ↓    ↓         ↓         ↓    ↓    ↓
Artists Crew Events  Worlds   Reuse Repair Recycle
   │         │         │              │
   └─────────┴─────────┴──────────────┘
                     │
                   ZORGAX
                     │
       ┌─────────────┼─────────────┐
       ↓             ↓             ↓
   Telegram       Social        Infopoint
                     │
                     ↓
               PHYSICAL WORLD

Every layer can remain independent.

But when connected, they become more useful.

Where LIFE-oriented work fits

The circular-economy side also connects with the environmental research direction of MyZubster.

Candidate LIFE-oriented work currently explores concepts such as:

material provenance
recovery
reuse
baselines
measurable environmental indicators
evidence trails

That means future cultural pilots could potentially study questions such as:

how much event material was reused?
how much material avoided disposal?
how many objects were repaired?
how many items entered another lifecycle?
what percentage had traceable provenance?

But these must be measured.

A recycled-looking stage is not environmental evidence.

A sustainability claim needs a baseline and verifiable data.

What already exists

The current MyZubster repository contains real building blocks for this direction:

✅ Metaverse architecture

✅ Circular Marketplace world

✅ Marketplace booths inside the Metaverse

✅ Cultural event data model

✅ Modular event architecture

✅ Telegram-related event modules

✅ Subculture profile documentation

✅ Artist/subculture discovery flows

✅ Bot and notification infrastructure

✅ Circular item/passport development

✅ GitHub-driven evidence and provenance

✅ Interactive Comic Universe

GitHub:

https://github.com/MyZubster-Ecosystem/myzubster

Metaverse Circular Marketplace:

https://github.com/MyZubster-Ecosystem/myzubster/blob/main/docs/metaverse/CIRCULAR-MARKETPLACE-WORLD.md

Subculture profiles:

https://github.com/MyZubster-Ecosystem/myzubster/blob/main/docs/culture/ZORGAX-SUBCULTURE-PROFILES.md

Free-party modular operations:

https://github.com/MyZubster-Ecosystem/myzubster/blob/main/docs/culture/ZORGAX-MODULAR-FREE-PARTY-OPERATIONS.md

Tekno / artist discovery:

https://github.com/MyZubster-Ecosystem/myzubster/blob/main/docs/culture/ZORGAX-TEKNO-TRIBES-ARTIST-DISCOVERY.md

MyZubster:

https://myzubster.com

Comic Universe:

https://myzubster.com/fumetto.html

What is still a direction

Some parts remain architectural or experimental.

⚠️ The system does not claim affiliation with Spiral Tribe/SP23, Mutoid Waste, Bedlam or other historical collectives.

⚠️ A Metaverse profile does not prove crew membership.

⚠️ Bots should not autonomously publish sensitive event locations.

⚠️ Circular-economy impact requires measurements.

⚠️ Physical events require responsible organizers, appropriate permissions and safety controls.

⚠️ Recycled materials must still be suitable and safe for their intended use.

The goal is not to automate culture.

It is to give culture better infrastructure.

From temporary autonomous space to persistent open infrastructure

A free party is temporary.

A sound system arrives.

A space changes.

People meet.

Music happens.

Then everything disappears again.

But some things should remain:

knowledge
documentation
art
connections
technical solutions
repaired materials
cultural memory
reusable infrastructure

This is where the Metaverse becomes interesting.

Not as an escape from reality.

As a persistent layer connecting temporary real-world experiences.

TEMPORARY EVENT
       ↓
CULTURAL MEMORY
       ↓
OPEN DOCUMENTATION
       ↓
METAVERSE
       ↓
NEW COMMUNITY
       ↓
NEW EVENT

Build culture, not platforms around culture

The deeper principle is simple.

Communities should not exist only as content inside someone else's social network.

They should be able to own their infrastructure.

Their identity.

Their documentation.

Their event data.

Their material flows.

Their archives.

Their connections.

Social networks then become channels, not the foundation.

COMMUNITY
   ↓
OWN DATA / OPEN SOURCE
   ↓
MYZUBSTER
   ↓
Telegram
Instagram
Web
Metaverse
Marketplace
Infopoint

Platforms can change.

The cultural graph remains.

A possible future event

Imagine this:

You enter MyZubster Metaverse.

You discover an independent sound-system district.

You listen to an artist.

You open the event Infopoint.

You see that a cultural gathering is being organized.

You find a workshop building stage furniture from recovered materials.

The Circular Marketplace shows available timber, lighting equipment and repaired electronics.

A maker reserves materials.

The event page updates.

Telegram distributes the authorized public announcement.

The physical event happens.

QR codes connect the installations to their material passports.

After the event, materials return to the circular pool.

Photos and documentation enter the cultural archive.

The Metaverse space remains online.

Another community discovers the project.

And the cycle starts again.

DISCOVERY
   ↓
COMMUNITY
   ↓
MATERIAL
   ↓
CREATION
   ↓
EVENT
   ↓
CULTURE
   ↓
RECOVERY
   ↓
DOCUMENTATION
   ↓
REPLICATION

That is the system we are trying to build.

Not just a Metaverse.

Not just a Marketplace.

Not just an event platform.

Not just AI.

A cultural, circular and open-source coordination layer between digital communities and the physical world.

Culture creates networks.
Open source preserves knowledge.
Circularity keeps materials moving.
The Metaverse keeps the map alive.
Bots connect the channels.
Humans keep the responsibility.

opensource #metaverse #subculture #diy #soundsystem #circulareconomy #recycling #events #telegram #ai #culture #community

MyZubster Pilot Projects: Building an Evidence-First Path Toward EU LIFE

Daniel Ioni — Sat, 05 Sep 2026 14:49:48 +0000

MyZubster Pilot Projects: Building an Evidence-First Path Toward EU LIFE

MyZubster is evolving from an open-source ecosystem into an evidence-first infrastructure designed to connect software, people, environmental observations, sensors, AI-assisted workflows and real-world pilot projects.

One of the directions we are currently exploring is how this infrastructure could support environmental pilots aligned with the objectives and working methods of the European Union's LIFE Programme.

This is an important distinction:

MyZubster is not claiming to be an EU-funded LIFE project today.

The current work is preparatory. There is no claim of European Commission or CINEA endorsement, approved LIFE funding, a completed consortium or automatically validated environmental impact.

The goal is to build the technical and evidence infrastructure that a serious pilot needs before making environmental claims.

What is the LIFE Programme?

LIFE is the European Union's funding programme dedicated to environment and climate action.

Its 2021–2027 structure includes four main sub-programmes:

Nature and Biodiversity
Circular Economy and Quality of Life
Climate Change Mitigation and Adaptation
Clean Energy Transition

Official LIFE Programme:
https://cinea.ec.europa.eu/programmes/life_en

The Circular Economy and Quality of Life programme supports work around areas such as waste and resource recovery, water, soil, air, chemicals and environmental governance.

Climate-oriented LIFE projects can also include pilot, demonstration and best-practice approaches designed to test measurable solutions.

For MyZubster, this is particularly interesting because the technical problem is not only:

"Can we build a solution?"

It is also:

"Can we prove what happened, against a baseline, with traceable evidence?"

The MyZubster evidence model

The common architecture behind our candidate pilots is:

REAL-WORLD EVENT
        ↓
AUTHORIZED DATA / OBSERVATION
        ↓
PROVENANCE
        ↓
BASELINE
        ↓
MEASURABLE KPI
        ↓
EVIDENCE RECORD
        ↓
HUMAN / TECHNICAL REVIEW
        ↓
REPRODUCIBLE REPORT

Instead of treating a dashboard screenshot or an automated result as proof by itself, MyZubster is designed around explicit evidence states.

Some examples:

candidate ≠ partner

discussion ≠ agreement

simulation ≠ physical deployment

observation ≠ validated environmental outcome

GitHub contribution ≠ institutional participation

automation ≠ independent scientific verification

Main repository:

https://github.com/MyZubster-Ecosystem/myzubster

Public vision and architecture:

https://github.com/MyZubster-Ecosystem/myzubster/blob/main/VISION.md

Pilot Track 1 — Absorbent Hygiene Products

One candidate circular-economy pilot focuses on Absorbent Hygiene Products (AHP).

This category can include products such as:

diapers / nappies
sanitary absorbent products
incontinence products

The candidate material flow is:

collection
   ↓
traceable batch
   ↓
treatment
   ↓
recovered materials
   ↓
destination / reuse
   ↓
environmental evidence

A real pilot could measure indicators such as:

total mass collected
mass treated
recovery yield by material fraction
rejected or residual fraction
destination of secondary materials
completeness of traceability records
environmental indicators compared with an agreed baseline

The important part is that MyZubster would not need to operate the recycling plant itself.

Its possible role is the digital evidence and provenance layer connecting the stages of the process.

The current status is:

CANDIDATE_PILOT_TRACK

No recycler, municipality, technology provider or waste-management organisation is currently represented as a confirmed LIFE/MyZubster partner merely because this track exists.

Pilot documentation:

https://github.com/MyZubster-Ecosystem/myzubster/blob/main/docs/life/circular-economy-candidate-pilots.md

Pilot Track 2 — Industrial Hemp Circular Bioeconomy

A second candidate pilot explores the circular use of industrial hemp and lawful agro-industrial biomass or residues.

This is specifically about industrial biomass and circular material flows — not recreational cannabis or controlled-substance commerce.

The possible flow is:

cultivation / processing residue
            ↓
traceable biomass lot
            ↓
transformation / reuse
            ↓
secondary material or product
            ↓
environmental evidence

Potential measurements could include:

biomass or residue input
material recovery or valorisation yield
waste avoided or diverted, where demonstrable
destination and use of outputs
provenance completeness
environmental indicators measured against a defined baseline

Again, the core principle is:

do not infer environmental impact simply because material was processed.

If a project wants to claim avoided waste, improved material efficiency or another environmental benefit, the baseline and measurement method need to be defined first.

Current status:

CANDIDATE_PILOT_TRACK

Documentation:

https://github.com/MyZubster-Ecosystem/myzubster/blob/main/docs/life/circular-economy-candidate-pilots.md

Pilot Direction 3 — Environmental Sensing, Soil and Irrigation

Another part of the MyZubster architecture is connecting environmental sensing with human-governed automation.

Our EVA IONI / Zorgax development direction includes models for:

environmental sensing
soil sensing
irrigation interfaces
evidence collection
safety gates
manual override

The architecture deliberately starts with simulation.

SENSOR MODEL
     ↓
OBSERVATION
     ↓
VALIDATION
     ↓
ZORGAX ANALYSIS
     ↓
RECOMMENDATION
     ↓
HUMAN AUTHORIZATION
     ↓
BOUNDED ACTION

A simulated sensor value is not described as a real environmental measurement.

Likewise, a software-controlled irrigation model is not described as a verified physical deployment until hardware, location, permissions and safety controls are independently established.

This distinction becomes critical when software moves from dashboards into the physical environment.

Architecture:

https://github.com/MyZubster-Ecosystem/myzubster/blob/main/VISION.md

Zorgax: AI-assisted evidence orchestration

Zorgax is the automation/orchestration layer inside this architecture.

Its role is not to become an autonomous environmental authority.

Instead, it can help:

ingest authorized information
classify observations
normalize data
prepare provenance records
identify missing evidence
calculate or prepare KPI inputs
prepare reviewable reports
route contributor tasks
detect inconsistent states

But consequential transitions remain human-controlled.

AUTOMATION MAY

observe
classify
validate
prepare
recommend

HUMANS RETAIN

consent
authorization
partnership decisions
publication
legal commitments
physical activation

That is especially important for environmental pilots.

AI can make evidence workflows faster.

It should not manufacture evidence.

Baselines and KPIs before claims

A LIFE-oriented pilot needs more than a good idea.

Before claiming improvement, we want a clear answer to questions such as:

What was the starting condition?

What exactly changed?

How was it measured?

Who produced the measurement?

Where is the source evidence?

Can another person reproduce the calculation?

This is why MyZubster is building around:

baseline definition
KPI/MRV workflows
provenance
evidence registries
explicit stakeholder states
authorization records
technical and scientific review
reproducible reporting

The desired flow is:

BASELINE
   ↓
AUTHORIZED PILOT
   ↓
MEASUREMENTS
   ↓
RAW EVIDENCE
   ↓
PROVENANCE
   ↓
KPI / MRV
   ↓
REVIEW
   ↓
REPRODUCIBLE RESULT

From candidate pilot to real pilot

Another important part of the project is refusing to collapse every relationship into the word "partner."

A candidate pilot can move through explicit states:

CANDIDATE_PILOT_TRACK
        ↓
STAKEHOLDER_IN_DISCUSSION
        ↓
PILOT_SCOPE_IN_DEFINITION
        ↓
PILOT_CONFIRMED
        ↓
MEASURED PILOT
        ↓
VALIDATED OUTCOMES

A GitHub issue does not create a partnership.

An email does not create a consortium.

A meeting does not prove environmental impact.

And participation does not automatically validate a KPI.

This may sound conservative, but environmental projects become stronger when their evidence boundary is clear.

People and contributors

MyZubster is also experimenting with structured participant and contributor pathways.

One example is Nicola Lorenzini / N4K48, whose contributor and Metaverse journey is documented separately from institutional or LIFE partnership claims.

Nicola's public DEV article:

https://dev.to/n4k48/building-n4k48-my-journey-with-myzubster-ai-and-neon-plaza-3nbp

Participant documentation:

https://github.com/MyZubster-Ecosystem/myzubster/blob/main/docs/NICOLA_LORENZINI_LIFE.md

The important governance principle is:

CONTRIBUTOR
≠
PARTICIPANT
≠
EMPLOYEE
≠
LIFE PARTNER
≠
CONSORTIUM MEMBER

Those states need separate evidence.

Replication matters

A useful environmental pilot should eventually be reproducible outside the original team.

That means publishing enough information for another actor to understand:

setup
baseline
data schema
KPI definitions
evidence requirements
software components
safety requirements
authorization boundaries
expected outputs

Our longer-term direction is therefore not simply to publish a successful dashboard.

It is to build a Replication Kit.

The stronger test is not:

"Can MyZubster demonstrate this once?"

It is:

"Can another authorized organisation independently reproduce the workflow and obtain auditable evidence?"

Why open source matters here

Environmental projects often combine many layers:

physical environment
+
people
+
sensors
+
organisations
+
software
+
data
+
reporting

Making the software and evidence methodology public provides a way to inspect how conclusions were produced.

GitHub organisation:

https://github.com/MyZubster-Ecosystem

MyZubster website:

https://myzubster.com

Press and evidence overview:

https://www.myzubster.com/press

Interactive Comic Universe:

https://myzubster.com/fumetto.html

Current status

As of September 2026, the accurate description is:

✅ MyZubster has an active open-source evidence architecture.

✅ Baseline, provenance, KPI and participant/stakeholder workflows are being developed.

✅ Candidate circular-economy pilot tracks are publicly documented.

✅ Environmental sensing and human-gated automation are part of the technical direction.

✅ Contributor and pilot-state separation is implemented as an explicit governance principle.

⚠️ The AHP and industrial-hemp tracks remain candidate/exploratory pilots.

⚠️ Physical sensing/robotics must remain distinguished from simulation until hardware deployment is verified.

⚠️ Environmental outcomes require measurements against agreed baselines.

❌ MyZubster is not claiming current EU LIFE funding.

❌ It is not claiming European Commission or CINEA endorsement.

❌ A candidate organisation is not automatically a partner.

❌ A contributor is not automatically a consortium member.

What comes next

The next milestone is to move from architecture to bounded real-world validation.

That means finding authorized pilot contexts where we can define:

a real environmental problem;
a responsible organisation or site;
an agreed baseline;
measurable indicators;
a clear data boundary;
provenance rules;
human and technical review;
a reproducible pilot package.

Only then should a candidate track move toward a confirmed pilot.

And only measured evidence should support environmental outcome claims.

That is the approach we want to bring to the MyZubster LIFE-oriented work:

evidence before claims, baseline before impact, authorization before deployment, and reproducibility before scale.

Links

MyZubster
https://myzubster.com

GitHub
https://github.com/MyZubster-Ecosystem/myzubster

Candidate circular-economy pilots
https://github.com/MyZubster-Ecosystem/myzubster/blob/main/docs/life/circular-economy-candidate-pilots.md

Public architecture / vision
https://github.com/MyZubster-Ecosystem/myzubster/blob/main/VISION.md

Press & environmental/LIFE direction
https://www.myzubster.com/press

EU LIFE Programme — CINEA
https://cinea.ec.europa.eu/programmes/life_en

LIFE Circular Economy and Quality of Life
https://cinea.ec.europa.eu/programmes/life/circular-economy-and-quality-life_en

LIFE Climate Change Mitigation and Adaptation
https://cinea.ec.europa.eu/programmes/life/climate-change-mitigation-and-adaptation_en

opensource #sustainability #circulareconomy #climate #iot #ai #environment #europe #lifeprogramme

# Building in Public: Today’s Development Update

Daniel Ioni — Fri, 04 Sep 2026 19:05:15 +0000

Building in Public: Today’s Development Update

Today was one of those days where several pieces started moving at the same time — product, infrastructure, security, payments, and the work Nicola is pushing forward.

Here’s a quick development update on where things stand.

LIFE 2027 and the scientific side

We continued moving forward on the LIFE 2027 track, particularly around the scientific component and the contacts needed to strengthen that side of the project.

The goal here is not simply to prepare an application, but to make sure the technical and scientific foundations are credible enough to support what we want to build.

There are still conversations and validations ahead, but the direction is becoming clearer.

Stripe and MYZ-49

Work also continued around Stripe and MYZ-49.

Payments are one of those areas where the implementation itself is only part of the job. The surrounding flows, edge cases, configuration, and production readiness matter just as much.

We’re progressively closing those gaps and getting the payment layer into a more solid state.

Security: RustSec and MYZ-12

Another important area today was dependency and security work connected to RustSec / MYZ-12.

Security work is rarely the most visible part of a product, but it is exactly the kind of work that becomes expensive when postponed.

So the approach remains simple:

identify the issue;
understand the dependency path;
remove or mitigate the vulnerable surface;
verify that the fix doesn’t introduce regressions.

It’s maintenance work, but it’s foundational maintenance.

Nicola’s progress: N4K48

Nicola also continued pushing forward on N4K48.

This is particularly useful because we’re starting to turn several previously separate pieces into a more coherent development path.

Rather than treating each task as an isolated ticket, the focus is increasingly on how the pieces interact: what blocks what, what can be shipped independently, and what needs to be stabilized before moving to the next layer.

That should help us reduce unnecessary rework as development accelerates.

What comes next

The immediate priorities are now fairly clear: continue consolidating the payment work, close the relevant security issues, keep N4K48 moving, and advance the technical/scientific groundwork around LIFE 2027.

There’s still a lot to build.

But today was less about starting new things and more about connecting existing work into something increasingly coherent.

And that’s usually when a project starts getting interesting.

buildinpublic #development #startup #rust

Human Evolution Is No Longer Only Biological: The Daniel Ioni Experiment

Daniel Ioni — Fri, 04 Sep 2026 13:19:46 +0000

Human Evolution Is No Longer Only Biological: The Daniel Ioni Experiment

When we hear the words human evolution, we usually imagine thousands of generations.

Mutation.
Natural selection.
Adaptation.

But there is another form of evolution happening much faster.

Cultural evolution.

Humans build tools.

Tools change human behavior.

New behavior creates new societies.

And software has accelerated that cycle dramatically.

This raises an interesting question:

What does an evolving human being look like in the age of AI, open source and planetary-scale networks?

My own journey with MyZubster has made me think about this question differently.

Not because I believe I am biologically more evolved than anyone else.

I am not.

But because my life has become an experiment in something that may become increasingly important:

turning experience, technology, discipline and failure into systems that other people can build upon.

Evolution changed

For most of human history, evolution was primarily biological.

Today another process operates on top of biology:

Human
  ↓
Knowledge
  ↓
Tools
  ↓
Networks
  ↓
Collective intelligence
  ↓
New behavior

A developer can learn from millions of lines of open-source code.

AI can compress years of information into an interactive tool.

Git allows thousands of strangers to coordinate changes to the same system.

The Internet allows an idea created in a bedroom in Italy to be examined seconds later in Japan.

Evolution has acquired a new transmission mechanism:

information.

My own transformation

My path was not linear.

It included counterculture, punk environments, hacking culture, mistakes, physical discipline, self-education and eventually software development.

Those experiences could have remained disconnected.

Instead, over time, they began converging.

REBELLION
     +
TECHNOLOGY
     +
DISCIPLINE
     +
OPEN SOURCE
     +
ENVIRONMENTAL THINKING
     ↓
MYZUBSTER

That transformation interests me more than the mythology of the "successful founder."

Because human beings are not immutable objects.

We are systems capable of rewriting parts of ourselves.

From breaking systems to building systems

Hacker culture teaches something extremely valuable:

systems are not magic.

They have components.

Interfaces.

Assumptions.

Weaknesses.

Rules.

Once you understand that, there are two possible directions.

You can exploit systems.

Or you can build better ones.

For me, the interesting evolution was moving increasingly toward the second.

Instead of asking:

How can this system be broken?

the question became:

How could this system work differently?

That question eventually became part of MyZubster.

The circular human

The circular economy is normally described in terms of materials:

PRODUCT
 ↓
USE
 ↓
RECOVERY
 ↓
MATERIAL
 ↓
NEW PRODUCT

But perhaps humans can behave circularly too.

We accumulate:

experiences, failures, knowledge, scars, relationships and skills.

Some of those things initially look like waste.

But they can be processed.

EXPERIENCE
     ↓
REFLECTION
     ↓
KNOWLEDGE
     ↓
CREATION
     ↓
VALUE FOR OTHERS

That may be one of the most interesting forms of human development.

Nothing has to be wasted.

Not even failure.

Humans + AI

AI introduces another major transition.

I don't see the interesting future as:

AI vs HUMAN

I see:

HUMAN
  +
AI
  +
OPEN KNOWLEDGE
  +
GLOBAL COLLABORATION

A single person can now research, prototype, document, translate, analyze and communicate at a scale that previously required an organization.

That doesn't make the individual superhuman.

It changes the individual's leverage.

And leverage changes what small groups can attempt.

GitHub as evolutionary infrastructure

There is something almost biological about open source.

An idea becomes code.

The code is copied.

Someone modifies it.

Another person tests it.

A useful mutation survives.

A bad mutation disappears.

Then the system forks again.

IDEA
 ↓
CODE
 ↓
FORK
 ↓
MUTATION
 ↓
TEST
 ↓
SELECTION
 ↓
MERGE

Obviously software evolution isn't biological natural selection.

But the analogy is useful.

Repositories allow knowledge to evolve beyond the individual who originally created it.

That is why open source matters so much to me.

The objective isn't:

Look what Daniel built.

The more interesting outcome is:

Look what other people can build from it.

From individual intelligence to network intelligence

MyZubster is increasingly becoming an experiment around this idea.

Different actors can contribute different capabilities:

DEVELOPERS
     +
COMMUNITIES
     +
COMPANIES
     +
RESEARCHERS
     +
AI
     +
PUBLIC INSTITUTIONS

No participant needs to know everything.

The intelligence exists in the connections.

This resembles one of humanity's oldest evolutionary advantages:

cooperation.

Technology simply increases its possible scale.

Circular Hygiene became a concrete example

Recently we started applying this philosophy to absorbent hygiene products such as diapers and sanitary products.

The question wasn't simply:

Can these products be recycled?

Industrial actors are already working on that problem.

Our question became:

Can the entire journey of recovered material become measurable and verifiable?

So we designed a possible evidence chain:

COLLECTION
 ↓
WEIGHING
 ↓
DIGITAL LOT
 ↓
TRANSPORT
 ↓
TREATMENT
 ↓
RECOVERED MATERIAL
 ↓
DESTINATION
 ↓
VERIFICATION

And we adopted an important principle:

No evidence → no material claim.

Technology also needs epistemic humility

This may be the most important lesson.

Technology can easily create an illusion of certainty.

Put something on a blockchain and suddenly it looks authoritative.

Generate a SHA-256 digest and it looks verified.

But:

HASH VERIFIED
      ≠
PHYSICALLY VERIFIED

A cryptographic hash can demonstrate data integrity.

It cannot prove that the original measurement was correct.

So we began separating:

COLLECTED
 ↓
DOCUMENTED
 ↓
HASH_VERIFIED
 ↓
MEASURED
 ↓
EXTERNALLY_VERIFIED

This isn't merely an engineering decision.

It represents another kind of evolution:

learning to distinguish what technology can prove from what we merely want to believe.

From Italy to a global conversation

We have now started presenting these concepts beyond the repository.

We prepared a Circular Hygiene pilot framework for discussion with relevant European contacts.

We also prepared dedicated technical outreach material for organizations in Japan, including Unicharm, Kao and the P&G/Pampers ecosystem.

These are exploratory contacts.

They are not partnership announcements.

And that distinction matters.

Evolution requires experimentation.

Experimentation requires evidence.

Evidence sometimes proves that an idea works.

Sometimes it proves that it doesn't.

Both outcomes create knowledge.

So is Daniel Ioni "the evolution of humanity"?

Literally?

No.

One person cannot represent biological human evolution.

And declaring someone a new species or a superior human would turn an interesting idea into mythology.

But as a metaphor?

There is something worth exploring.

My story represents one possible form of human adaptation:

OUTSIDER
 ↓
LEARNER
 ↓
BUILDER
 ↓
COLLABORATOR
 ↓
SYSTEM DESIGNER

A person doesn't erase his past.

He processes it.

He combines physical discipline with intellectual curiosity.

Counterculture with engineering.

Individual autonomy with collaboration.

Software with environmental problems.

AI with human judgment.

And then publishes the result so other people can inspect it.

That is not a new species.

It is something more achievable:

a human being capable of deliberately evolving his own way of operating.

The real evolutionary advantage

Maybe the next great human advantage won't be strength.

Or intelligence alone.

It may be the ability to connect things that used to remain separated:

HUMAN + MACHINE

INDIVIDUAL + COMMUNITY

TECHNOLOGY + ECOLOGY

REBELLION + RESPONSIBILITY

EXPERIENCE + EVIDENCE

IMAGINATION + VERIFICATION

That synthesis is what I am trying to explore through MyZubster.

Not a perfect human.

Not a superior human.

Not a technological messiah.

Just a human being continuously capable of becoming something different from what he was yesterday.

And perhaps that is the most human form of evolution there is.

We don't have to wait for the future.

We can build, test and document pieces of it today.

Learn → Build → Measure → Verify → Share → Evolve

— Daniel Ioni / MyZubster

HumanEvolution #MyZubster #OpenSource #AI #CircularEconomy #BuildInPublic #Programming #FutureOfWork #Sustainability

MyZubster Circular Hygiene: from a 50-ton evidence pilot to global industry outreach

Daniel Ioni — Fri, 04 Sep 2026 12:49:58 +0000

MyZubster Circular Hygiene: from a 50-ton evidence pilot to global industry outreach

Over the last few days, MyZubster has taken an important step forward.

We moved from discussing circular economy at a high level to defining a concrete pilot architecture for used absorbent hygiene products such as:

diapers;
sanitary products;
incontinence products;
other post-consumer absorbent hygiene materials.

The goal is not to reinvent industrial recycling.

The goal is to build the digital evidence layer around it.

Our working principle remains:

No evidence → no material claim.

The problem we want to solve

A circular process is only useful if we can prove what actually happened.

For a used hygiene product stream, a real circular flow may involve:

SOURCE
  ↓
COLLECTION
  ↓
WEIGHING
  ↓
DIGITAL LOT
  ↓
TRANSPORT
  ↓
PLANT RECEIPT
  ↓
TREATMENT
  ↓
RECOVERED MATERIALS
  ↓
DESTINATION / REUSE

Every step creates data.

But today, those data points are often fragmented across:

municipalities;
collectors;
transport operators;
treatment plants;
manufacturers;
auditors;
sustainability teams.

MyZubster is exploring whether these records can be connected into a single verifiable evidence package.

The MyZubster Circular Hygiene model

We designed a pilot called:

MyZubster Circular Hygiene 500T

The name describes the potential scale-up target.

But the real starting point is much smaller.

Our proposed progression is:

50 t
 ↓
100 t
 ↓
500 t

The first serious gate is 50 tonnes.

Before scaling, the pilot should demonstrate:

evidence completeness;
verifiable mass balance;
chain-of-custody records;
consistent lot identification;
treatment output records;
independent review.

We deliberately do not start by claiming that 500 tonnes will be processed.

The 500-tonne level is a possible future scale, not a completed result.

What is inside an evidence package?

For each lot, we propose recording at least:

LOT ID
ORIGIN
TIMESTAMP
RESPONSIBLE OPERATOR
INPUT WEIGHT
TRANSPORT / CUSTODY EVENTS
PLANT RECEIPT
TREATMENT REFERENCE
RECOVERED OUTPUTS
DESTINATION
SUPPORTING EVIDENCE
INTEGRITY DIGEST

This gives us a structured object that can be reviewed later.

But there is an important engineering distinction.

A hash is not scientific validation

One of the easiest mistakes in environmental software is confusing data integrity with truth.

If we calculate a SHA-256 digest, we can prove that a payload has not changed.

That is useful.

But:

HASH_VERIFIED != PHYSICALLY_VERIFIED

and:

CRYPTOGRAPHIC_INTEGRITY != SCIENTIFIC_VALIDATION

A system can prove that a record is authentic and unchanged while the original physical measurement is still wrong.

This is why our trust model separates layers:

COLLECTED
   ↓
DOCUMENTED
   ↓
HASH_VERIFIED
   ↓
MEASURED
   ↓
EXTERNALLY_VERIFIED

Environmental claims, accreditation and rewards should only appear at the appropriate layer.

MRV becomes the bridge

This brings us to MRV:

Measurement, Reporting and Verification.

The technical system can support:

provenance;
timestamps;
evidence references;
chain of custody;
integrity hashes;
mass balance;
reproducible records.

But external review is still required for stronger claims.

For example:

"5,000 kg entered the plant"

is different from:

"3,800 kg were scientifically verified as recoverable secondary material"

and both are different from:

"This process avoided X tonnes of CO2"

The last statement requires a proper methodology.

So our rule is simple:

CO2, LCA and environmental-impact claims are excluded until an appropriate methodology and external validation exist.

KPI for the first pilot

For the initial 50-tonne gate, we defined technical and operational KPI such as:

tonnes collected;
tonnes treated;
contamination rate;
input/output mass balance;
kg recovered per kg input;
recovery by material fraction where measurable;
evidence completeness;
cost per tonne;
revenue per tonne.

For cellulose, plastics and SAP recovery, we only include metrics where they can actually be measured and documented.

The business model is also being tested

We also created a preliminary economic hypothesis.

One scenario assumes that MyZubster could generate approximately:

€30 / tonne

from a combination of:

software;
evidence services;
MRV support;
digital traceability;
marketplace services.

At 500 tonnes:

500 × €30 = €15,000

This is not a validated market price.

It is a business-model hypothesis to test with real operators.

Longer term, possible revenue layers could include:

B2B SaaS
+
MRV / evidence services
+
secondary-material marketplace fees
+
automation / robotics

But first, we need to prove that the evidence architecture is useful.

Bringing the model to CSMT and LIFE contacts

We recently had a positive exploratory discussion with CSMT.

The next step proposed was another call involving a colleague with more specialized expertise.

This is important because the project is reaching a new question:

What evidence would an external specialist require before considering the pilot credible?

We prepared:

a 10-slide Circular Hygiene 500T deck;
a one-page executive proposal;
the 50 t acceptance gate;
the MRV trust model;
the KPI framework;
the proposed business case.

We then shared these materials with relevant CSMT and LIFE contacts.

This does not mean CSMT or LIFE authorities are formal project partners.

At this stage, we are seeking technical feedback and the correct validation pathway.

Then we expanded the conversation to Japan

The next step was to look at companies already active in hygiene-product circularity.

Instead of approaching them with a generic sustainability pitch, we created a Japan Partner Pack focused on interoperability.

The proposal is:

MyZubster does not replace proprietary recycling technology.

It adds a digital layer around:

COLLECTION
   ↓
LOT IDENTITY
   ↓
MEASUREMENT
   ↓
PROVENANCE
   ↓
TREATMENT OUTPUT
   ↓
DESTINATION
   ↓
EVIDENCE

Unicharm

For Unicharm, we prepared a brief focused on potential interoperability with its circularity work and municipal workflows.

The discussion we are proposing is not:

"Use MyZubster instead of your technology."

It is:

"Can MyZubster connect to your existing operational data and turn it into portable, auditable evidence?"

We sent a dedicated outreach brief together with the broader Japan Partner Brief.

Kao

For Kao, the proposal focuses on:

treatment-event evidence;
recovered-output records;
traceability;
validation;
a possible 50 t proof of concept.

Again, the aim is interoperability rather than replacing industrial know-how.

P&G / Pampers

For P&G/Pampers, we created a separate innovation brief around:

digital traceability;
manufacturer/municipality interfaces;
recovered-material evidence;
circularity reporting;
scalable partner interoperability.

The proposal was then sent to a P&G innovation contact channel with a request to route it to the relevant sustainability, circularity, R&D or Connect + Develop team.

Why we created separate documents

We deliberately did not send the same generic PDF to everyone.

Each organization has a different role.

So we created:

GENERAL JAPAN PARTNER BRIEF

UNICHARM BRIEF
→ interoperability / municipal circularity

KAO BRIEF
→ treatment evidence / verification

P&G / PAMPERS BRIEF
→ manufacturer-scale traceability and innovation

This makes the conversation much more useful.

What we are NOT claiming

This part is important.

MyZubster is not claiming that:

Unicharm is a partner;
Kao is a partner;
P&G/Pampers is a partner;
CSMT is a formal project partner;
LIFE funding has been obtained;
the 500 t pilot is approved;
€30/t has been validated;
environmental savings have been certified;
a SHA-256 hash proves environmental performance.

These are exploratory technical and business-development steps.

The purpose is to create the conditions for real validation.

The architecture is becoming clearer

The Circular Hygiene vertical now looks like this:

                         MYZUBSTER
                             │
                             ↓
                      DIGITAL LOT LAYER
                             │
              ┌──────────────┼──────────────┐
              │              │              │
          COLLECTION      EVIDENCE        MRV
              │              │              │
              └──────────────┼──────────────┘
                             ↓
                       TREATMENT PLANT
                             │
                       RECOVERED OUTPUT
                             │
              ┌──────────────┼──────────────┐
              │              │              │
          REPORTING      MARKETPLACE     REVIEW

And the trust progression is:

DATA
 ↓
INTEGRITY
 ↓
PROVENANCE
 ↓
MEASUREMENT
 ↓
EXTERNAL VERIFICATION
 ↓
CLAIM

Why this matters for open source

A lot of sustainability software starts with the final claim.

We are trying to do the opposite.

Start with:

WHAT HAPPENED?

Then:

CAN WE DOCUMENT IT?

Then:

CAN SOMEONE ELSE VERIFY IT?

And only after that:

WHAT CAN WE CLAIM?

That is much harder.

But it is also much more useful.

The next gate

The next real milestone is not another partnership announcement.

It is:

50 tonnes with a complete evidence chain

Target:

50 t
+
≥95% evidence completeness
+
verifiable mass balance
+
defined MRV methodology
+
external review

If that passes:

50 t → 100 t → 500 t → replication

That is the path.

Building MyZubster in public

This project is still experimental.

But the architecture is becoming more disciplined.

We are moving from:

IDEA

to:

PILOT

to:

EVIDENCE

to:

EXTERNAL REVIEW

And only then, hopefully, to:

REPLICATION

The most important rule remains unchanged:

No evidence → no material claim.

MyZubster Circular Hygiene

Build → Measure → Evidence → Verify → Replicate.

MyZubster #OpenSource #CircularEconomy #MRV #Sustainability #WasteTech #CleanTech #Innovation #BuildInPublic

MyZubster: from an open-source MVP to evidence, MRV and a circular economy ecosystem

Daniel Ioni — Fri, 04 Sep 2026 09:52:55 +0000

MyZubster: from an open-source MVP to evidence, MRV and a circular economy ecosystem

Over the last few days, MyZubster has moved through several different layers of development.

Not just code.

Not just visuals.

Not just a marketplace.

We are starting to connect these pieces around one principle:

No evidence → no material claim.

This post explains where the project is today, what we have actually demonstrated, what is still experimental, and where we want to go next.

1. What is MyZubster?

MyZubster is an open-source ecosystem exploring how software, marketplaces, local communities, AI, environmental observations and circular-economy processes can work together.

The long-term idea is a cycle such as:

OBSERVE
   ↓
DOCUMENT
   ↓
CONNECT
   ↓
MEASURE
   ↓
VERIFY
   ↓
RECOVER / REGENERATE
   ↓
NEW CYCLE

But there is an important distinction.

A diagram is not evidence.

A visual is not certification.

A blockchain hash is not scientific validation.

And an MVP is not automatically a production-ready system.

So we are trying to build the project with explicit boundaries between concept, implementation, evidence and external validation.

2. The Marketplace: moving from concept to real transactions

One major milestone has been the MyZubster Marketplace.

We have implemented a Seller flow based on:

STRIPE CHECKOUT
      ↓
SUBSCRIPTION
      ↓
SIGNED WEBHOOK
      ↓
SELLER MEMBERSHIP
      ↓
MARKETPLACE ACCESS
      ↓
LISTING PUBLICATION

The Seller membership flow has been tested with a real subscription and a real listing publication.

That matters because MyZubster is no longer only describing a marketplace architecture.

Parts of the transaction infrastructure are actually running.

The next important product gate is the other side of the marketplace:

BUYER
  ↓
REQUEST
  ↓
MESSAGING
  ↓
EXCHANGE
  ↓
COMPLETION
  ↓
REPUTATION

Closing this loop is one of our current priorities.

3. Nicola enters MyZubster: N4K48

Another important experiment is the work being developed with Nicola.

Inside the visual and narrative layer of MyZubster, Nicola is represented as:

N4K48 // Explorer // Neon Plaza

The cyberpunk identity is storytelling.

Behind it, however, there is a real technical MVP.

The project has worked on components including:

observation APIs;
JSON persistence;
atomic writes;
retrieval of stored observations;
end-to-end tests;
coordinate validation;
Docker;
persistent volumes;
health checks;
CI;
Gunicorn;
local AI;
Ollama;
Qdrant;
local RAG over observations.

This gives us an interesting bridge:

N4K48
   ↓
REAL ACTIVITY
   ↓
OBSERVATION
   ↓
TECHNICAL EVIDENCE
   ↓
MYZUBSTER

The cyberpunk universe can therefore represent real project progress without pretending that the visual itself proves the progress.

4. Connecting N4K48 to the circular economy

We have now connected the N4K48 profile to MyZubster's circular-economy visual layer.

The conceptual path becomes:

N4K48 / Nicola
      ↓
OBSERVE
      ↓
DOCUMENT
      ↓
EVIDENCE
      ↓
MEASURE
      ↓
VERIFY
      ↓
CIRCULAR ECONOMY
      ↓
RECOVERY / REGENERATION
      ↓
NEW CYCLE

We also created visual representations for:

MyZubster Circular Economy;
circular-economy value/payment flows;
the MyZubster Space Station;
Neon Plaza and N4K48.

These visuals help explain the architecture.

But we deliberately keep this boundary:

Visual storytelling does not equal environmental evidence.

5. The next challenge: MRV

This brings us to one of the most important areas we are now exploring:

MRV — Measurement, Reporting and Verification.

Imagine that MyZubster records an environmental observation.

We can hash the payload.

We can timestamp it.

We can preserve provenance.

We can prevent replay.

We can demonstrate that a payload has not changed.

But that still doesn't prove that the underlying physical measurement is scientifically correct.

That distinction is fundamental.

We therefore see several trust layers:

DATA
 ↓
INTEGRITY
 ↓
PROVENANCE
 ↓
MEASUREMENT VALIDITY
 ↓
EXTERNAL VERIFICATION
 ↓
ACCREDITATION / ATTESTATION

For example:

SHA-256 can demonstrate integrity.

It cannot, by itself, demonstrate the truth of a physical environmental claim.

6. Why we are being careful with environmental rewards

We are also experimenting with architectures for environmental rewards.

This creates a much higher trust requirement.

A system must not be able to assign a high-value environmental status simply because somebody uploaded metadata or generated a hash.

For that reason, our direction is increasingly:

SELF REPORTED
      ↓
EVIDENCE
      ↓
TECHNICAL VERIFICATION
      ↓
AUTHORIZED VALIDATION
      ↓
ELIGIBLE RESULT

Any economic reward should remain fail-closed when the required evidence or validator authorization is missing.

This is especially important if MyZubster eventually connects environmental evidence to economic incentives.

7. A very useful conversation with CSMT

Today we also had a very positive exploratory conversation with CSMT.

The purpose was not to announce a partnership.

It was to ask a more important question:

How do we move from a working technical pilot to an MRV approach that can be evaluated seriously?

The meeting went well.

The next step proposed is another conversation involving a colleague with more specialized expertise in the relevant field.

For us, this is valuable because the next challenge is no longer simply:

Can we build it?

It is:

What evidence is required for an external expert to evaluate it?

Our desired next gate is therefore something like:

TECHNICAL PILOT
      ↓
EVIDENCE PACKAGE
      ↓
MRV METHODOLOGY
      ↓
EXTERNAL REVIEW
      ↓
VALIDATED PILOT

We are not calling CSMT a formal MyZubster partner at this stage.

The discussion is an exploratory technical process.

8. Looking toward LIFE — carefully

We are also exploring whether this work could eventually become relevant to a future European LIFE pathway.

Again, wording matters.

We are not saying:

that MyZubster has LIFE funding;
that a LIFE application has been approved;
that CSMT is a LIFE partner;
or that the current pilot already satisfies LIFE requirements.

Instead, we are asking what would have to become true for a credible future path to exist.

A possible progression is:

PILOT
 ↓
MRV
 ↓
EXTERNAL VALIDATION
 ↓
REPLICABILITY
 ↓
CONSORTIUM / PARTNERS
 ↓
FUTURE APPLICATION

Evidence first.

Claims later.

9. Singapore: defining the regulatory boundary

We have also been exploring a potential Singapore pilot.

A particularly useful step was receiving guidance from the Monetary Authority of Singapore's FinTech Regulatory Sandbox team regarding the Phase 1 configuration we described.

The proposed first phase focuses on operational/environmental data and non-transferable evidence credentials, without investment rights, fundraising, custody, trading or live payment functionality.

Based on the configuration presented, MAS indicated that the Phase 1 did not appear to involve a financial service regulated by MAS, meaning the MAS Regulatory Sandbox would not apply to that phase.

This does not mean MAS has approved or certified MyZubster.

It gives us something different and useful:

a clearer regulatory boundary for the experiment as described.

Any future financial functionality would require a separate regulatory assessment before activation.

So our architecture remains:

PHASE 1

DATA
+
MRV
+
PROVENANCE
+
EVIDENCE

----------------

FUTURE FINANCIAL LAYER

SEPARATE
REGULATORY
ASSESSMENT

10. Open Banking: exploring the connection to real financial infrastructure

In parallel, we have started exploring how MyZubster could interact with traditional banking infrastructure.

The first goal is deliberately limited:

read-only account connectivity.

For example:

AUTHORIZED USER
      ↓
OPEN BANKING
      ↓
BALANCE / TRANSACTIONS
      ↓
MYZUBSTER

No payment initiation is required for this initial exploration.

We contacted Banco BPM about the appropriate route.

The bank informed us that its contacted channel cannot provide direct assistance for connecting MyZubster to customer accounts.

We remain interested in proceeding and have therefore asked for the appropriate Open Banking / PSD2 technical channel, documentation or authorized provider route.

This is still exploratory.

There is no live Banco BPM integration today.

11. The architecture is becoming clearer

Putting everything together, MyZubster is starting to look less like one application and more like a set of connected layers.

                 MYZUBSTER
                     │
       ┌─────────────┼─────────────┐
       │             │             │
 MARKETPLACE       N4K48          MRV
       │             │             │
   SELLER /       PILOT /       EVIDENCE
    BUYER        LOCAL AI          │
       │             │         VALIDATION
       └──────┬──────┘             │
              │                    │
        CIRCULAR ECONOMY ──────────┘
              │
        RECOVERY / REUSE
              │
          NEW CYCLE

Around this core there are additional experimental interfaces:

CSMT → methodology / expert discussion

LIFE → possible future European pathway

SINGAPORE → operational evidence pilot exploration

OPEN BANKING → financial-data interoperability exploration

12. What we are NOT claiming

Open-source projects can move quickly.

Claims should move more slowly.

So here are some explicit boundaries.

MyZubster is not claiming that:

environmental results are already scientifically validated;
hashes are equivalent to signatures or accreditation;
CSMT is already a formal partner;
LIFE funding has been obtained;
MAS has approved MyZubster;
Banco BPM is integrated with MyZubster;
visual concepts prove technical functionality;
an evidence token automatically represents a verified environmental asset.

These distinctions are part of the architecture, not legal fine print added afterward.

13. What comes next

Our immediate roadmap is becoming much simpler.

Product

SELLER FLOW
     ↓
BUYER FLOW
     ↓
COMPLETE MARKETPLACE LOOP

Nicola / N4K48

MVP
 ↓
EVIDENCE PACKAGE
 ↓
MRV
 ↓
EXTERNAL REVIEW

Circular economy

OBSERVATION
 ↓
MEASUREMENT
 ↓
PROVENANCE
 ↓
VERIFICATION
 ↓
RECOVERY
 ↓
REPLICATION

Institutional exploration

CSMT
 ↓
SPECIALIST FOLLOW-UP
 ↓
METHODOLOGY
 ↓
VALIDATION PATH

International exploration

SINGAPORE PHASE 1
 ↓
OPERATIONAL DATA
 ↓
MRV / EVIDENCE
 ↓
VALIDATION

Financial interoperability

OPEN BANKING
 ↓
READ-ONLY
 ↓
AUTHORIZED PROVIDER / API
 ↓
TECHNICAL VALIDATION

Building in public

One reason we keep these repositories and technical decisions visible is that MyZubster is being developed as an open ecosystem.

We want developers, researchers, sustainability experts, organizations and contributors to be able to challenge assumptions.

If an environmental claim is weak, we want to know.

If the MRV model is insufficient, we want to improve it.

If a trust boundary is wrong, we want to fix it before economic value depends on it.

The goal isn't to make the biggest claim.

The goal is to progressively make stronger claims supported by stronger evidence.

BUILD
 ↓
TEST
 ↓
DOCUMENT
 ↓
MEASURE
 ↓
VERIFY
 ↓
LEARN
 ↓
REPLICATE

That's where MyZubster is today.

And that's the direction we're building toward.

MyZubster — open source, evidence first, circular by design.

GitHub: MyZubster Ecosystem
Project: MyZubster
N4K48: Nicola's technical and visual pilot

opensource #circulareconomy #sustainability #MRV #AI #OpenBanking #MyZubster

What We Shipped Overnight: MyZubster Metaverse Safety and a Live Space Station

Daniel Ioni — Fri, 04 Sep 2026 00:37:04 +0000

What We Shipped Overnight: MyZubster Metaverse Safety and a Live Space Station

Last night was an important step for MyZubster: we strengthened the foundations of our Metaverse and connected the Space Station to the public platform.

These are not speculative mockups. Both projects now have working public entry points, live APIs and clearly documented security boundaries.

Neon Plaza: from prototype to a safer shared world

The MyZubster Metaverse is available at:

👉 https://www.myzubster.com/metaverse

Neon Plaza currently provides:

MongoDB-backed shared presence
Keyboard and touch movement
Public chat
Proximity awareness
Emotes
Guest and account-linked characters
Portals to Marketplace, LIFE, Identity, Visual and Zorgax
A session dashboard showing online users and activity
Browser capability diagnostics

The public API currently uses shared polling. WebSockets, WebXR, spatial voice and full 3D rendering remain future work.

A privacy and abuse-control baseline

During the night, we merged PR #920, establishing the first official privacy, retention and abuse-control baseline for Neon Plaza.

The documented production boundaries include:

Active presence expires after 90 seconds of inactivity
Public chat messages expire after one hour
Inputs are sanitized and length-limited
Operational logs exclude chat content, tokens, request bodies and session identifiers
Account-linked identities are resolved through authenticated MyZubster accounts
Client-provided identity claims are never treated as verified
Permanent movement history is not collected

The pull request passed:

CI, tests and lint
Security Audit
Continuous Evidence Gate
Vercel deployment checks

We also documented what is not implemented yet: distributed rate limiting, mute, block, reporting, moderator auditing and formal deletion workflows.

Being explicit about these gaps matters. Open source development should describe the system that exists—not the system we hope to have later.

The Space Station is online

We also merged PR #921, adding a public Space Station dashboard:

🚀 https://www.myzubster.com/space-station

The integration introduces same-origin proxy routes under /api/space-station/*, allowing the website to display live station health, robot and mission information without exposing backend credentials.

The production health endpoint reports:

{
  "station": "MYZUBSTER-SPACE-STATION",
  "status": "online",
  "version": "0.2.0"
}

The browser currently receives read-only information. Mutating inventory, economy or robot operations have deliberately not been exposed because those actions still require a production-grade authentication and authorization layer.

A broader read-only client—covering spaces, inventory, MYZ balances and missions—is being developed in PR #919.

Two environments, one ecosystem

The direction is becoming clearer:

Neon Plaza provides the social and immersive layer
Space Station provides robotics, missions and operational data
MyZubster identity connects participants to persistent characters
Marketplace and LIFE projects provide real destinations and activities
Evidence gates keep technical claims independently verifiable

The next challenge is not adding visual complexity for its own sake. It is connecting these components safely: authenticated missions, verified contributions, controlled robot operations and immersive representations of real data.

That is how MyZubster is evolving—from a collection of experiments into an open, connected and evidence-driven ecosystem.

Repository: https://github.com/MyZubster-Ecosystem/myzubster
Metaverse: https://www.myzubster.com/metaverse
Space Station: https://www.myzubster.com/space-station

opensource #metaverse #robotics #webdev

From Storyboard to GitHub: Bringing N4K48 into the MyZubster Neon Plaza

Daniel Ioni — Thu, 03 Sep 2026 07:29:53 +0000

From Storyboard to GitHub: Bringing N4K48 into the MyZubster Neon Plaza

Today I worked on a small but meaningful step in the evolution of the MyZubster / Zorgax visual ecosystem.

The goal was simple:

Turn Nicola's existing project journey into a visual “first mission” inside the MyZubster Neon Plaza.

The result became:

N4K48 enters Neon Plaza — First Mission

The visual represents Nicola's experimental participant journey around the Project Planner, with a simple progression:

Build → Test → Evidence

This is deliberately a storytelling layer around an existing technical and validation workflow. It is not presented as proof that a fully deployed metaverse platform already exists.
The idea

Nicola already has a documented participant path connected to MyZubster and Zorgax.

Instead of creating a completely fictional avatar with arbitrary levels, scores or achievements, the idea was to make his digital identity reflect things that can eventually be connected to real project activity.

His visual identity is:

N4K48

Archetype:

Explorer

World:

Neon Plaza

The first mission is based around the Project Planner.

The visual sequence starts before the portal, shows identity activation, entry into Neon Plaza, interaction with Zorgax and finally the activation of the first mission.
Storytelling with an evidence boundary

One principle matters a lot to me in MyZubster:

visual storytelling must not replace evidence.

A cyberpunk interface can say:

FIRST MISSION STARTED

But it should not automatically say:

MISSION COMPLETED
REPUTATION +500
VERIFIED EXPERT

unless something underneath actually supports those claims.

That distinction is important because I want the visual layer of MyZubster to eventually represent real activity rather than manufacture reputation.

The README therefore explicitly states that the visual represents the project narrative and does not itself constitute technical evidence of completed functionality.
Then Git fought back

Uploading the visual became more interesting than expected.

The Nicola repository contained an old malformed path whose filename included a very long block of Markdown text.

On Windows this triggered problems such as:

Filename too long

The local checkout started interpreting several repository files as deleted.

A normal:

git add
git commit
git push

would therefore have been dangerous.

Instead of committing only:

M README.md
A assets/n4k48-neon-plaza-first-mission-2026-09-03.png

Git was showing many unrelated deletions.

That immediately became a safety condition:

do not push a commit if unrelated files are being deleted.
A second problem: hidden carriage returns

While experimenting with low-level Git tree creation from PowerShell, another subtle issue appeared.

Some generated tree paths ended up containing carriage-return characters.

Conceptually, Git was seeing things similar to:

README.md\r
CONSENT.md\r
assets\r/

rather than:

README.md
CONSENT.md
assets/

That produced a commit where GitHub could no longer resolve the expected README.md path correctly.

The problematic commit was visible as a set of renamed/deleted files with \r embedded in filenames.

This was a useful reminder that Git trees store byte-level path names.

Something that looks almost identical on screen can be a completely different path internally.
Repairing the branch safely

Instead of merging or trying to patch the corrupted commit, I rebuilt the intended change against the last known-good parent.

The repaired commit contains only two repository changes:

M README.md
A assets/n4k48-neon-plaza-first-mission-2026-09-03.png

No project files were removed.

No main branch was modified.

No automatic merge was performed.

The safe commit is:

6298c1d31f2eb813af981747a341806170c87670

Its diff contains only the README addition and the new visual asset.

The experimental branch now points to that repaired commit.
The final result

The Nicola profile branch now contains a new section:
🌌 N4K48 enters Neon Plaza — First Mission

with the visual embedded directly into the README.

The narrative is:

IDENTITY
↓
NEON PLAZA
↓
ZORGAX
↓
PROJECT PLANNER
↓
BUILD
↓
TEST
↓
EVIDENCE

The README is now correctly available again and includes the Neon Plaza section.
What I learned from this small experiment

A visual feature can reveal infrastructure problems.

What started as “add one cyberpunk image to a GitHub profile” touched:

Git tree objects

Windows path limitations

sparse checkout behavior

CR/LF and carriage-return edge cases

branch isolation

commit verification

evidence boundaries

human-controlled publishing

And that is actually aligned with what I want MyZubster to become.

Not just a visual world.

A world where the visual layer, project activity and technical evidence can eventually remain connected.

For N4K48, this is only the beginning.

N4K48 HAS ENTERED NEON PLAZA

FIRST MISSION STARTED

Repository:
DanielIoni-creator/Nicola

Branch:
visual/n4k48-neon-plaza-first-mission-2026-09-03

Project:
MyZubster / Zorgax

Mission:
Project Planner · Build → Test → Evidence

DEV Community: Daniel Ioni

# DEV Guide: Building ZORGAX Party Mode, Realtime Sessions and Moderation in MyZubster

DEV Guide: Building ZORGAX Party Mode, Realtime Sessions and Moderation in MyZubster

1. The Starting Point: Neon Plaza

2. The Goal: ZORGAX Party Mode

3. Z1 — PartyContext

4. Z2 — Grounded Community and Event Assistant

5. Z3 — Room and Session Telemetry

6. Why not-modeled Matters

7. Z4 — Creator Capability Gateway

8. Z5 — Moderation Assistance

9. Z6 — Post-Event Archive Handoff

10. Z7 — Safety and End-to-End Acceptance

11. Building the Real Room/Session Lifecycle

12. Short-Lived Session Tokens

13. Persistent Lifecycle Event Stream

14. Moderation Foundation: Block, Mute, Report

15. Contextual Reports

16. Why MYZ-82 Is Not Finished Yet

17. MYZ-78 — Realtime Gateway and Socket Authentication

18. Server-Side Channel Authorization

19. Reconnect Without Duplicate Presence

20. Heartbeat and Connection Lifecycle

21. An Important Deployment Constraint

22. Current State

23. What Still Needs to Be Built

24. The Longer-Term Architecture

25. The Main Engineering Lesson

Links

Current development sequence

Building ZORGAX Party Mode: Giving Our Metaverse an Intelligent Orchestration Layer

Building ZORGAX Party Mode: Giving Our Metaverse an Intelligent Orchestration Layer

What Is ZORGAX Party Mode?

The Current Architecture

Z1 — PartyContext

Z2 — A Grounded Community Assistant

Z3 — Teaching ZORGAX to Understand the Room

We Are Not Pretending WebXR Is Finished

Why Telemetry Matters for an AI Agent

Privacy Is Part of the Telemetry Design

What Comes Next: Z4 Creator Commands

Then Comes Moderation

What Happens After the Party?

The Final Gate: Z7

Where We Are Today

The Bigger Idea

opensource #ai #webdev #metaverse

Building Social Life: From a Metaverse Concept to an Execution-Ready Product Roadmap

Building Social Life: From a Metaverse Concept to an Execution-Ready Product Roadmap

1. The Product Architecture

2. Social Foundation

3. Realtime Social Layer

4. The WebXR Metaverse

WebXR Runtime

Scene Manifest

Avatars

Room Lifecycle

Spatial Media

Interactive Environments

Performance

5. Physical Experiences Meet Virtual Twins

6. Creator Studio

7. Creator Economy — But Not Yet

8. From Documents to an Engineering Backlog

Milestone A — Social Foundation

Milestone B — Realtime Social

Milestone C — WebXR Metaverse

Milestone D — Public Events & Virtual Twins

Milestone E — Creator Economy Gate

9. The First Execution Block

10. What Social Life Is Becoming

What's Next

From Social Networks to an Open Network: What We Are Building with MyZubster

From Social Networks to an Open Network: What We Are Building with MyZubster

Why talk about MyZubster in underground communities?

From DIY Culture to Open Source

Social Networks Are Channels, Not the Network

What Does the MyZubster Metaverse Do?

Events Become Structured Information

The Infopoint

6. Why `not-modeled` Matters