DEV Community: Daniel Ioni

We Built Our First Isolated Tor v3 Onion Service for MyZubster 🧅

Daniel Ioni — Sat, 17 Oct 2026 07:21:20 +0000

We Built Our First Isolated Tor v3 Onion Service for MyZubster 🧅

An open-source experiment in privacy, Docker isolation, and decentralized infrastructure.

At MyZubster, we're exploring how independent contributors can build and operate interoperable services without relying on a single centralized infrastructure.

Today, we reached a new technical milestone: our first isolated Tor v3 Onion pilot successfully completed the Tor bootstrap process and displayed its experimental web page.

This is a small but meaningful step toward our broader vision.

What We Built

The pilot uses a deliberately minimal architecture:

Tor Browser
    |
    v
Tor v3 Onion Service
    |
    v
Isolated HAProxy
    |
    v
Static MyZubster Pilot Page

The environment includes:

A dedicated Tor container running Tor 0.4.9.11
An isolated HAProxy container
Separate Docker networks
A persistent volume for the Onion service identity
A static experimental page
No intended access to MyZubster production APIs, wallets, or payment services

The proxy was configured to return HTTP 200 for the homepage and HTTP 404 for /api and /admin.

Our First Successful Tor Bootstrap

During the initial tests, we encountered Docker permission errors when Tor attempted to switch to its dedicated system user.

After adjusting the container capabilities, Tor started successfully.

The logs eventually confirmed:

Bootstrapped 100% (done): Done

We also generated a dedicated Onion v3 address:

http://lrkjukwcbn7ftl7nkhuaefarwqymxx6xzopt77qa7mc4uinbdxrzn4id.onion

The experimental page displays:

MyZubster Onion Pilot

Experimental Tor v3 service.

Isolated technical pilot without API or payment access.

This demonstrates an initial working proof of concept. It is not yet a production-ready, independently security-audited deployment.

Why Does This Matter?

MyZubster is exploring a model where contributors can connect their own projects, services, skills, and infrastructure.

Our longer-term goals include:

Independent infrastructure nodes
Interoperability between contributor projects
Privacy-conscious access through Tor
Verifiable contributions and digital contributor passports
Community-driven governance and resource sharing

Decentralization is not simply adding a blockchain or an Onion address.

It requires real operational independence, reproducible deployments, clear security boundaries, and contributors who can maintain services without depending on a single administrator.

What's Next? Contributor-Led Development

We're inviting @wasim-builds to help advance the next phase of this Tor/HAProxy pilot.

The proposed work includes:

Reproducible Docker Compose configuration
Network isolation and threat-model documentation
Meaningful health checks and rollback procedures
End-to-end Tor Browser testing
Recovery tests after container restarts or network changes
Independent code review

This is an opt-in open-source contribution proposal, not a confirmed paid assignment.

You can follow the technical discussion here:

MyZubster GitHub — Tor Onion Pilot #1584

Contributor Operations and DAO Pilots #1605

Join the Experiment

We're looking for developers interested in Tor, Docker, networking, privacy engineering, and interoperable open-source infrastructure.

You don't need to operate a VPS or join a DAO to contribute.

Start with a review, a reproducible test, documentation, or a small pull request.

The goal isn't to claim we've already decentralized everything. It's to build and verify one independent component at a time.

Explore the project:

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

MyZubster — Connecting people, knowledge, projects, and independent infrastructure.

opensource #tor #docker #privacy

Building the MyZubster Metaverse: Secure Sessions, Verified Identities and the Road to Realtime

Daniel Ioni — Sat, 17 Oct 2026 05:19:27 +0000

Building the MyZubster Metaverse: Secure Sessions, Verified Identities and the Road to Realtime

The MyZubster Metaverse is evolving from a visual experiment into a real, testable multiplayer environment.

Our objective is not simply to render avatars on a page. We are building an open-source world where guest users, verified contributors and independent communities can interact through a shared identity and knowledge layer.

The public entry point is now available here:

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

This article explains what we have implemented, the security work completed in our latest development cycle, the current architecture and what still needs to be built before the platform can be considered production-ready at scale.

What the MyZubster Metaverse is

The MyZubster Metaverse is intended to connect several parts of the ecosystem:

public and verified user profiles;
GitHub contributor identities;
Zorgax characters;
Verified Knowledge;
community spaces;
Development Requests;
open-source contributions;
optional rewards and bounties;
future immersive WebXR experiences.

The current version focuses on the foundations: identity, presence, sessions and authenticated world actions.

Users can currently enter the world as guests without requiring:

a cryptocurrency wallet;
identity documents;
a GitHub account;
an installed application.

Verified MyZubster explorers can also be displayed with their associated public GitHub identity.

This gives us two different identity levels:

Guest explorers, who can enter quickly using a public display name.
Verified explorers, whose public character is linked to an authorized account or GitHub identity.

Verification here does not mean KYC or legal identity verification. It only represents a confirmed connection with the declared public account.

What we have implemented

1. Public Metaverse entry point

The production interface now provides a dedicated Metaverse route:


text
https://www.myzubster.com/metaverse
The entry interface includes:
- guest onboarding;
- public display-name selection;
- automatic character creation;
- verified explorer discovery;
- multilingual UI support;
- links to account-based authentication.
The guest path is intentionally lightweight. A user can explore the world without being forced to create a permanent account first.
2. World presence model
The backend maintains a presence record for each active Metaverse participant.
A presence can contain information such as:
{
  sessionId,
  displayName,
  characterId,
  accountId,
  githubLogin,
  position,
  status,
  lastSeenAt
}
The public representation deliberately excludes private credentials and internal security fields.
Presence data is used by the world API to support operations such as:
- joining the world;
- synchronizing visible participants;
- moving a character;
- sending chat messages;
- publishing emotes;
- leaving the world;
- retrieving world events.
Before our latest security work, knowing a public session identifier could potentially be sufficient to target mutable session routes. That is not an acceptable trust boundary for a multiplayer environment.
A public identifier must identify a session, but it must never prove ownership of it.
The latest milestone: possession-bound sessions
Our latest merged pull request introduces possession-based session credentials.
Pull request:
👉 MyZubster PR #34 — Bind world actions to session credentials
Production commit:
148a798
This work creates a security boundary between:
- the public session identifier;
- the private credential required to control that session.
How session creation now works
When a player joins the world, the backend creates:
1. a public sessionId;
2. a cryptographically random private session token.
The token is generated from 32 random bytes, providing 256 bits of entropy.
Conceptually:
const sessionToken = crypto.randomBytes(32).toString("base64url");
The raw token is returned to the client only when the session is created.
It is never included in public player data.
3. Only the token digest is stored
The backend does not persist the raw session token.
Instead, it calculates a SHA-256 digest:
const tokenHash = crypto
  .createHash("sha256")
  .update(sessionToken)
  .digest("hex");
The presence record stores the digest:
{
  sessionId,
  sessionTokenHash: tokenHash
}
This reduces the impact of an accidental database disclosure. An attacker reading the presence collection would not immediately obtain the active bearer credentials.
A token cannot be recovered directly from its digest.
4. Constant-time credential verification
Mutable world routes verify the submitted credential against the stored digest.
The comparison uses a constant-time operation to reduce timing side-channel exposure:
crypto.timingSafeEqual(expectedBuffer, receivedBuffer);
Credential validation is centralized in an ownership middleware similar to:
requireOwnedSession
The middleware checks that:
- the session exists;
- the private token was provided;
- the submitted token produces the expected digest;
- the credential belongs to the requested session.
Missing or invalid credentials result in an unauthorized response.
HTTP 401 Unauthorized
5. Protected world actions
The following routes are now protected by session ownership verification:
/sync
/move
/chat
/emote
/leave
/events
Knowing another player’s public sessionId is no longer sufficient to:
- move that player;
- send messages as that player;
- publish their emotes;
- synchronize private session state;
- remove them from the world;
- retrieve protected session events.
This closes an important class of horizontal session-ownership vulnerabilities.
6. Tokens are sent through a dedicated header
The frontend now sends the private credential through:
X-Metaverse-Session-Token: <private-token>
Example:
const createSessionHeaders = (sessionToken) => ({
  "X-Metaverse-Session-Token": sessionToken,
});
The token is not placed inside normal public JSON payloads:
{
  "sessionId": "public-session-id",
  "x": 120,
  "y": 80
}
Separating authorization data from world-state payloads makes the security boundary clearer and reduces the risk of credentials being copied into:
- application logs;
- analytics events;
- public state;
- debugging output;
- serialized world events.
The backend temporarily supports a legacy request-body token for compatibility, but the header is the canonical client mechanism.
7. Credentials remain in memory
The browser keeps the Metaverse session credential in React runtime memory.
We deliberately avoid storing it in:
localStorage
sessionStorage
public profile objects
world event payloads
In-memory credentials disappear when the page or browser session is closed.
This does not eliminate every browser-side threat, especially an active cross-site scripting vulnerability, but it reduces long-lived credential exposure.
Privacy and identity boundaries
The Metaverse must distinguish several concepts that are often incorrectly combined:
Account identity
      ↓
Public profile
      ↓
Character identity
      ↓
Temporary world session
      ↓
Private session credential
A public GitHub profile proves control of a public contributor account only when an authorization flow verifies it.
It does not automatically prove:
- legal identity;
- employment;
- institutional affiliation;
- ownership of an organization;
- eligibility for payment;
- control of a blockchain wallet.
Similarly, the public session ID identifies an active world session, but only the private session credential authorizes mutations for that session.
These distinctions are now documented in the repository’s Metaverse privacy and security documentation.
Testing completed
The session-ownership work includes backend, frontend and static architecture tests.
Backend verification
The targeted backend suites cover:
- secure token creation;
- SHA-256 digest persistence;
- successful authorized operations;
- missing credential rejection;
- invalid credential rejection;
- attempts to mutate another player’s session;
- exclusion of credentials from public payloads;
- protected movement, chat, emote, synchronization and leave routes.
Result:
3 targeted backend suites
22 tests passed
Frontend verification
Frontend tests validate:
- token retention in application memory;
- use of X-Metaverse-Session-Token;
- authorized API requests;
- session-aware world operations;
- absence of the token from public request bodies.
Result:
1 targeted frontend suite
5 tests passed
Build and integration verification
We also completed:
Production frontend build: successful
git diff --check: clean
MYZ-164 Marketplace regression: passed
Vercel preview deployments: successful
Main deployment: successful
The implementation was squash-merged into main and deployed through the production workflow.
Current architecture
The current architecture can be summarized as:
React Metaverse Client
        |
        | HTTPS requests
        | X-Metaverse-Session-Token
        v
Node.js / Express Metaverse API
        |
        | ownership middleware
        | token hashing and verification
        v
Metaverse Presence Storage
        |
        v
Shared world polling and event synchronization
The current system provides a practical foundation, but it is not yet the final realtime architecture.
What still needs to be completed
1. Realtime transport
The current shared-world model still relies on polling-based synchronization in important areas.
The next architectural step is to introduce a proper realtime transport, most likely based on:
- WebSockets;
- Socket.IO;
- Server-Sent Events for selected read-only streams;
- a message broker when horizontal scaling becomes necessary.
Realtime transport must include:
- authenticated connection establishment;
- session-token validation;
- connection-to-session binding;
- reconnect handling;
- event ordering;
- duplicate-event protection;
- backpressure controls;
- presence expiry.
We should not simply move the existing endpoints to WebSockets. The event protocol must be explicitly designed and versioned.
2. Distributed rate limiting
In-memory rate limiting is insufficient when multiple backend instances process requests.
We still need a distributed limiter for:
- session creation;
- movement events;
- chat messages;
- emotes;
- authentication attempts;
- reconnect operations.
Possible storage layers include Redis or another shared atomic counter service.
The limiter should support dimensions such as:
IP address
account ID
session ID
route
world or room ID
time window
Movement events should have different limits from chat or authentication attempts.
3. Session lifecycle and revocation
Possession-bound credentials are now implemented, but lifecycle management needs additional work.
Remaining tasks include:
- explicit session expiration;
- server-side revocation;
- automatic removal of abandoned sessions;
- token rotation;
- reconnect-safe credential renewal;
- maximum active sessions per account;
- logout across devices;
- suspicious-session invalidation.
We also need clear rules for temporary guest sessions versus authenticated persistent characters.
4. Stronger account authentication
Verified characters need a canonical authentication path.
The roadmap includes:
- stable GitHub OAuth integration;
- verified account-to-character linking;
- protection against account-link substitution;
- clear reauthorization flows;
- audit trails for identity changes;
- recovery procedures.
The Metaverse must never trust a GitHub username supplied directly by the browser without verifying control of that account.
5. Privacy-safe analytics
We need operational visibility without building invasive tracking.
Metrics should focus on system health:
- active anonymous sessions;
- session duration ranges;
- API latency;
- reconnect frequency;
- rate-limit events;
- server errors;
- world capacity;
- event throughput.
We should avoid collecting unnecessary personal identifiers.
Analytics data needs:
- documented retention;
- aggregation;
- access restrictions;
- deletion rules;
- explicit separation from public profile data.
6. Reliability and load testing
The next reliability milestone must test realistic concurrent behavior.
Scenarios should include:
- many simultaneous joins;
- movement bursts;
- reconnect storms;
- inactive sessions;
- malformed events;
- duplicate events;
- slow clients;
- backend restarts;
- database latency;
- multiple application instances.
The system needs measurable targets for:
maximum concurrent participants
p95 and p99 API latency
event delivery delay
error rate
recovery time
presence consistency
7. Complete end-to-end acceptance tests
Unit and integration tests are not sufficient for the entire world flow.
We still need automated E2E tests covering:
Guest joins
→ session credential is issued
→ character becomes visible
→ movement is synchronized
→ chat and emotes are authorized
→ another session cannot impersonate the guest
→ reconnect behavior is correct
→ session leaves or expires
Equivalent tests are required for verified characters.
8. WebXR and immersive clients
WebXR remains a later-stage objective.
Before adding immersive rendering, we need to stabilize:
- authentication;
- world protocol;
- realtime synchronization;
- abuse prevention;
- accessibility;
- performance;
- mobile behavior.
The WebXR client should consume the same documented world protocol rather than implementing an independent backend.
This will allow multiple compatible clients:
2D web client
3D browser client
WebXR client
mobile client
community-built client
9. Dependency security debt
The current repository still reports dependency vulnerabilities during npm audit.
The latest Metaverse pull request did not modify package or lock files, so these findings were not introduced by the session-security work.
However, they remain real technical debt.
They must be handled in a separate dependency-hardening cycle involving:
1. vulnerability classification;
2. identification of production versus development exposure;
3. safe direct dependency updates;
4. transitive dependency analysis;
5. regression testing;
6. replacement of abandoned packages;
7. lockfile regeneration;
8. SBOM and audit evidence updates.
We should not hide or disable the audit simply to obtain a green badge.
Proposed next development sequence
The recommended order is:
1. Stabilize session expiration and revocation
2. Implement distributed rate limiting
3. Complete canonical account authentication
4. Design the versioned realtime event protocol
5. Introduce authenticated WebSocket connections
6. Add privacy-safe operational metrics
7. Execute reliability and load testing
8. Complete full guest and verified-user E2E tests
9. Resolve dependency security debt
10. Start the WebXR client milestone
Security and reliability must come before graphical complexity.
Open-source collaboration
We are looking for developers and independent testers interested in:
- Node.js and Express;
- React;
- realtime systems;
- WebSockets;
- MongoDB;
- Redis;
- application security;
- abuse prevention;
- privacy engineering;
- load testing;
- WebXR;
- open-source documentation.
Repository:
👉 https://github.com/danieldirimini-myzubster/myzubster
Public Metaverse:
👉 https://www.myzubster.com/metaverse
Recent security implementation:
👉 https://github.com/danieldirimini-myzubster/myzubster/pull/34
Conclusion
The MyZubster Metaverse now has a stronger technical foundation.
We have moved from trusting public session identifiers to enforcing private possession-bound credentials for mutable world actions.
The platform now includes:
- public guest access;
- verified explorer discovery;
- character presence;
- protected world operations;
- 256-bit session credentials;
- SHA-256 token digests;
- constant-time verification;
- header-based authorization;
- memory-only client credentials;
- backend and frontend tests;
- automated production deployment.
The next challenge is no longer simply creating more visual features.
It is building a secure, realtime, distributed and independently testable world protocol that can support different clients and communities without sacrificing privacy or transparency.
That is the direction of the next MyZubster Metaverse milestones.

MyZubster: From a Centralized VPS to a Network of Independent Nodes — The Work of Nicola N4K48 and Wasim

Daniel Ioni — Thu, 15 Oct 2026 05:24:59 +0000

MyZubster: From a Centralized VPS to a Network of Independent Nodes — The Work of Nicola N4K48 and Wasim

Open source, Docker, Tor, interoperability, verifiable knowledge, and distributed governance: we are exploring an ecosystem where contributors can build, verify, and eventually operate independent nodes.

Decentralization does not begin with a cryptocurrency. It begins when multiple people can develop, verify, and operate a system without depending entirely on a single administrator.

This is the direction we are exploring with MyZubster, an open-source ecosystem connecting a marketplace, AI tools, independent projects, contributors, and verifiable knowledge.

Our goal is not simply to create another marketplace.

We want to build an ecosystem where developers, artists, researchers, and local communities can contribute their own projects, document their work, demonstrate their skills, and progressively operate independent infrastructure.

Two contributors are helping turn this vision into a concrete technical roadmap:

Nicola (N4K48) and Wasim (@wasim-builds).

Their work represents two complementary approaches to decentralization.

1. Nicola N4K48: Building an Independent Node

Nicola is developing an experimental model connecting creative projects, digital catalogs, software agents, and Docker-based infrastructure.

His work addresses a fundamental question:

Can an independent project maintain its technical autonomy while interoperating with the wider MyZubster ecosystem?

The documented checkpoints include local catalog and agent verification, alongside a previously completed authenticated connection test between the MyZubster VPS and the N4K48 node.

Following credential rotation, the agent has remained offline pending authorization for any further authenticated testing.

This is an important principle: decentralization must not come at the expense of security.

Nicola's GitHub contributions

Nicola's work demonstrates how an independent creative project can also become an experiment in autonomous infrastructure, verifiable contributions, and interoperability.

2. Wasim: Designing Resilient and Reproducible Infrastructure

While Nicola is experimenting with an independent node, Wasim is working on the technical foundations that could make this model safer, more resilient, and easier to reproduce.

His contributions currently cover four major areas.

A. Tor Onion, HAProxy, and Docker

Wasim has prepared an architecture proposal involving:

Docker containerization
HAProxy reverse proxy
Tor Onion connectivity
Threat modeling
Reproducible local tests
Rollback procedures
Security evidence

The objective is to investigate ways of improving service resilience and reducing infrastructure dependencies.

His reported tests were performed in an isolated local environment, without exposing host ports, using real credentials, or consuming external VPS resources.

The design is documented in:

Important: This is currently a technical proposal under review, not a production Tor service or an operational independent node.

B. Pastebin → GitHub → Zorgax Interoperability

Another contribution focuses on connecting external information sources to MyZubster's verifiable knowledge system.

Wasim has updated a technical design for an evidence-ingestion workflow with security protections, provenance checks, and human review.

The proposal includes:

HTTPS-only source restrictions
Redirect blocking
Protection against requests to private network addresses
Deterministic rejection tests
Payload limits
Sensitive-information filtering
Mandatory human review before accepting evidence

The proposed evidence format uses:

myzubster.knowledge.evidence.v1

The goal is to establish a clear distinction between information that has been submitted, imported, reviewed, and verified.

External information should not automatically become trusted knowledge.

Related work:

C. Contributor Passport Privacy

Wasim has also participated in reviewing privacy protections for the MyZubster Contributor Passport.

The underlying principle is straightforward:

A contributor's personal information should not become publicly accessible without appropriate consent controls.

This is particularly important when connecting identities, technical contributions, skills, evidence, and reputation.

PR #1599 — Contributor Passport Privacy Gate

D. GitHub CI Reliability and Hardhat 3

Decentralized infrastructure also requires reliable and independently verifiable software.

Wasim has contributed to GitHub Actions troubleshooting and reviewed the migration to Hardhat 3.

His review covered a change separating NFT tooling from the main application's dependency structure.

We are also investigating CI failures in our development fork.

3. What Are We Building Together?

Our long-term objective is to evolve MyZubster into a federated ecosystem of independently operated projects.

A simplified conceptual architecture looks like this:

                MyZubster Ecosystem
                        |
          +-------------+-------------+
          |             |             |
      Nicola Node   Future Node   Future Node
        N4K48        Wasim?       Contributor
          |             |             |
     Docker/Agent   Tor/HAProxy    Independent
     Local Catalog  Docker         Application
          |             |             |
          +-------------+-------------+
                        |
               Interoperability
                        |
                  Zorgax / APIs
                        |
              Knowledge & Evidence
                        |
              Contributor Passport
                        |
                   Marketplace
                        |
                DAO Governance

This diagram represents a proposed architecture, not an already operational federation. Wasim has not yet confirmed an independently operated production node.

The idea is that contributors could retain control over their own projects while choosing how to connect them to a shared ecosystem.

Different MyZubster components would serve complementary purposes.

Zorgax could help contributors explore and organize connected knowledge.

The Contributor Passport could document identities, skills, contributions, and supporting evidence.

The Marketplace could enable contributors to offer services, products, and technical expertise.

Independent nodes could host projects without requiring every service to run on the founder's central VPS.

DAO governance could eventually help distribute responsibilities, decision-making, infrastructure costs, and rewards.

4. Why We Want to Reduce Dependence on a Single VPS

A centralized infrastructure creates practical limitations.

One administrator may be responsible for hosting costs, maintenance, security, availability, and operational decisions.

This creates both technical and organizational risks.

Our goal is to investigate a model in which:

Contributors can independently operate parts of their infrastructure.
Projects communicate through documented interfaces.
Credentials remain under the control of their respective operators.
Tests can be reproduced without production access.
Infrastructure costs and responsibilities can be distributed.
Contributions and knowledge are supported by verifiable evidence.
Independent projects retain their identity and autonomy.

This transition cannot be achieved through a single deployment.

It requires reproducible tests, shared protocols, security reviews, operational agreements, and genuine collaboration.

5. Toward a DAO and Sustainable Contributor Economy

We are also exploring a DAO-inspired governance model for distributing work, responsibilities, costs, and rewards.

Our goal is to avoid building an ecosystem whose long-term survival depends entirely on one founder's personal resources.

However, a DAO is not created simply by issuing tokens or opening a GitHub discussion.

A sustainable governance model requires:

Clearly defined responsibilities
Transparent decision-making
Verifiable contributions
Fair and documented compensation arrangements
Sustainable infrastructure funding
Dispute-resolution procedures
Independent oversight

These mechanisms remain under development.

Related discussions:

Our objective is to develop a model in which independent contributors can create value, receive recognition, and potentially participate in sustainable economic activity.

6. What Has Been Tested, and What Still Needs to Be Proven?

One of the most important principles behind MyZubster is distinguishing proposals from verified implementations.

Already documented

GitHub contributions and technical reviews
Local Docker testing
N4K48 catalog and agent checks
A previously completed authenticated VPS-to-node checkpoint
Hardhat 3 migration review
Contributor Passport privacy review

Currently under review

Wasim's Tor/HAProxy architecture
Pastebin-to-Zorgax evidence ingestion
Additional CI reliability work
Reproducibility and security of the proposed infrastructure

Not yet demonstrated

A stable federation of multiple independently operated production nodes
Effective failover between independent infrastructure operators
Fully operational decentralized governance
Sustainable distributed infrastructure financing
End-to-end interoperability across all proposed services

These distinctions matter.

We want our technical claims to be supported by reproducible evidence, not just ambitious announcements.

7. An Invitation to Open-Source Contributors

MyZubster is open to developers, researchers, creators, and independent project operators interested in experimenting with interoperability and decentralization.

You do not need to own a VPS or invest money to begin contributing.

Useful contributions can include:

Code reviews and security analysis
Docker-based local experiments
API interoperability testing
Privacy and consent mechanisms
Knowledge graph research
Documentation
Accessibility improvements
Independent verification of technical evidence

We believe meaningful collaboration starts with small, clearly scoped, reproducible contributions.

Explore the project

Main project

Nicola N4K48

Wasim

Decentralization roadmap

Conclusion: Decentralization Is Something We Build Together

MyZubster is not yet a fully decentralized federation.

We are building and testing the components that could make such a federation possible.

Nicola is helping us understand how an independent project can operate as a node.

Wasim is helping us investigate how those nodes can become more secure, reproducible, interoperable, and resilient.

The next milestone is to verify that these components can work together safely, under distributed operational responsibility.

We are not simply trying to connect servers.

We are exploring how to connect people, projects, skills, evidence, and independent infrastructure.

And we want that process to remain open, transparent, and verifiable.

The future of MyZubster should not depend on one person operating everything. It should be something contributors can build, verify, and sustain together.

Daniel Ioni (h4x0r)

Creator & Administrator — MyZubster Ecosystem

opensource #decentralization #docker #webdev

Building the MyZubster Metaverse: What We've Shipped and What's Next

Daniel Ioni — Thu, 15 Oct 2026 04:48:24 +0000

Building the MyZubster Metaverse: What We've Shipped and What's Next

From account-linked experiences to distributed abuse protection — an open-source development update.

Over the past development cycle, we've made meaningful progress on the MyZubster Metaverse.

Our goal is not simply to build another virtual environment. We're exploring how a metaverse can connect people, independent projects, digital identities, knowledge, and real-world communities through an open-source ecosystem.

Here's what we've completed, what we've tested, and what still needs work.

✅ What we've completed

1. Account-linked Metaverse experience

The public Metaverse route is available at:

https://www.myzubster.com/metaverse

We have implemented and tested the account-linked flow, connecting the Metaverse experience with MyZubster's broader authentication and user ecosystem.

This provides a foundation for future interactions between digital identity, community participation, and independent projects.

2. Distributed rate limiting

One of our latest milestones is the implementation of MongoDB-backed abuse protection.

The system introduces rate limits for four Metaverse operations:

join — entering a session
sync — synchronizing session state
chat — sending messages
emote — submitting interactions

Using a shared MongoDB-backed limiter helps coordinate abuse controls across application instances instead of relying exclusively on individual server memory.

3. Privacy-conscious throttling

We've introduced HMAC-derived identifiers for throttling, rather than storing raw identifiers directly as rate-limit keys.

The implementation also includes:

Automatic TTL-based expiration
HTTP 429 Too Many Requests responses
Retry-After information
Protection against spoofed proxy headers
Documented privacy and retention boundaries

These measures are intended to reduce abuse while limiting unnecessary retention of identifying information.

4. Fail-closed production behavior

During review, we identified an important issue: if MongoDB became unavailable, the limiter could fall back to local in-memory behavior.

We corrected this behavior so that the production configuration fails closed when the shared rate-limiting dependency is unavailable.

This is an important security trade-off: availability may be reduced during an infrastructure failure, but abuse protection is not silently weakened.

5. Automated testing and GitHub integration

The final development work included:

21 backend test suites passing
125 backend tests passing in the final local verification
Clean Git diff checks
GitHub pull request review and merge

The distributed abuse protection was merged through:

PR #30 — feat(metaverse): add distributed abuse rate limits

https://github.com/danieldirimini-myzubster/myzubster/pull/30

Merge commit: d911cadd824a1ca00b50cfead7929eb8f80934d0

This represents completed implementation work, not a claim that every production-readiness requirement has been satisfied.

⚠️ What still needs to be completed

1. Dependency security remediation

Our security pipeline continues to flag an existing dependency backlog.

The latest reported audit included:

61 vulnerabilities in total
43 high-severity vulnerabilities
1 critical vulnerability

Some remediation paths involve potentially breaking dependency upgrades, including a major Hardhat migration.

We don't want to hide these findings or blindly apply incompatible updates.

Next step: review production versus development dependencies, assess actual exposure, submit targeted fixes, and rerun the security pipeline.

2. Final production verification

The pull request has been merged, but the final production verification was interrupted before completion.

We still need to verify the deployed commit, production health, and real behavior of the new rate limits.

3. Multi-user and load testing

Passing unit and integration tests is not the same as demonstrating scalability.

We want to validate:

Concurrent user sessions
Distributed synchronization
Chat and interaction throttling
MongoDB availability and recovery behavior
Performance under realistic traffic

4. Contributor-led testing

We're inviting open-source contributors to test the Metaverse independently, report reproducible bugs, review security assumptions, and improve documentation.

A useful contribution doesn't have to be a large feature.

A clear bug report, a failing test, or a small targeted pull request can move the project forward.

5. Independent infrastructure and decentralization

MyZubster is also exploring interoperability with contributor-owned infrastructure.

Our N4K48 pilot is an early step toward connecting independently managed projects and nodes.

However, an independently hosted VPS is not automatically a decentralized network.

We still need documented interfaces, tested recovery procedures, access controls, and independently reproducible interoperability tests.

This work remains in progress.

🌍 The bigger vision

We want MyZubster to become a place where people can connect their real-world activities, creative work, services, and technical contributions to a shared digital ecosystem.

The Metaverse is one component of that vision, alongside Zorgax, the Marketplace, and the Contributor Passport.

But our immediate priority is simpler:

Make the existing features reliable, secure, understandable, and useful before expanding their scope.

🤝 Join the development

We're looking for contributors interested in:

Security and dependency remediation
Backend and MongoDB testing
Metaverse frontend testing
Accessibility and user experience
Docker and infrastructure automation
Documentation and reproducible test cases

GitHub repository:

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

Contributor coordination:

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

Metaverse:

https://www.myzubster.com/metaverse

If you're interested, explore the repository, choose a focused task, and join the discussion.

We're building MyZubster in the open — one verified contribution at a time.

Daniel Ioni (h4x0r)

MyZubster — Open-Source Ecosystem

opensource #webdev #nodejs #metaverse

Building an Evidence-First Contributor Network: How MyZubster Connects Independent Projects

Daniel Ioni — Tue, 13 Oct 2026 05:05:00 +0000

Building an Evidence-First Contributor Network: How MyZubster Connects Independent Projects

Open-source collaboration becomes fragile when contribution history, current responsibilities, public profiles, and external projects all live in different places.

At MyZubster, we are working on a simpler boundary:

Contributors keep control of their own repositories and environments.

MyZubster connects only the evidence, interfaces, and explicitly approved collaboration checkpoints.

This is not a claim that every contributor belongs to a DAO, has a public digital passport, or is part of a funded research consortium. Those are separate states and must remain separate.

Our public README now includes a compact status index for contributor roles, digital-passport publication, external projects, and LIFE-oriented pilot candidates:

The model

A connected contributor project follows this path:

independent repository or environment
→ public, bounded evidence
→ documented interface or fixture
→ reproducible test
→ reviewed result
→ optional Knowledge / Passport / pilot link

The important words are bounded, optional, and reviewed.

A GitHub fork is not automatically a competence credential. A merged pull request is not automatically a public Passport. A pilot is not automatically a partnership. And a LIFE-oriented internal track is not an EU LIFE grant or consortium.

The contributors and linked projects

Daniel Ioni — coordination and evidence boundaries

GitHub: @danieldirimini-myzubster
Core project: MyZubster
Current scope: interim product and governance coordination, privacy boundaries, acceptance criteria, and evidence architecture.

The role is deliberately limited: coordination is not unilateral DAO authority. High-impact actions such as public-profile publication, treasury activity, deployment, funding, or institutional commitments require their own explicit process.

Nicola / N4K48 — independent Docker node and interoperability reference

Nicola’s work is the clearest example of the independent-project model. The N4K48 environment remains independently operated, while published Docker, provenance, and read-only interoperability evidence can be reviewed by others.

The next proposed checkpoint is an authenticated, sanitized N4K48 ↔ MyZubster test. It is a technical interoperability task—not a transfer of ownership, a production deployment, or a LIFE membership claim.

khongten124 — Open Period Care research and evidence package

GitHub: @khongten124
Evidence: PR #1451
Project documentation: Open Period Care package
Network reference: Pilot Node Network #1505

The Open Period Care work is connected as a research/evidence package. The contribution has a bounded evidence state and can be reused as a reference for provenance, structured requirements, and reproducible review.

It does not claim clinical validation, product efficacy, institutional endorsement, or a formal LIFE role.

Aming9303 — gateway, sensor, replication, and signed-webhook evidence

Aming’s public work contributes to the technical edge of the network: adapters, replication checks, and signed webhook behavior. These are useful building blocks for future environmental or operational pilots, including Circular Water, but they do not imply access to a partner’s systems or data.

wasim-builds — security and local resilience design

GitHub: @wasim-builds
Evidence:

Wasim has opted into a strictly local and isolated resilience-design track. The planned deliverable is a draft PR containing a threat model, Compose configuration, health checks, rollback instructions, and redacted smoke-test evidence.

There is no authorization for a public Onion deployment, production access, reimbursement, or paid bounty in that scope.

foxxx009 — documentation, KPI, and evidence framework

GitHub: @foxxx009
Documentation repository: myzubster-docs
Marketplace repository: MyZubster-Marketplace
Evidence:

foxxx009 has consented to existing public graph links. That is not the same as accepting a new project assignment. Their evidence is useful for future independent verification and KPI work, but any new pilot must start with a separate opt-in and a defined test plan.

Shweta Singh — technical verifier path, still consent pending

GitHub: @Shweta-singh24
Project fork: MyZubsterGateway
Reference: Pilot Node Network #1505

Shweta’s public fork has been discovered, but a fork alone is not enough to claim a verified contributor role. The proposed path is technical verification: Docker, Node.js, HTTPS/read-only interoperability, documentation, and contributor-to-contributor reproduction.

That path remains opt-in and evidence pending.

What the digital Passport means

A MyZubster Contributor Passport is not an automatic profile created from a GitHub username.

A public Passport requires explicit publication consent. It should expose only an approved, minimized public projection of contribution evidence. It must not expose internal reviewer data, payment identifiers, reward amounts, settlement records, secrets, or sensitive personal information.

This is an active privacy requirement, tracked in issue #1598.

What “LIFE-oriented” means here

MyZubster has candidate real-world tracks such as kefir, Circular Water, and circular-care evidence. They can reuse technical components created by independent contributors:

Docker and independent-node operation;
data schemas and deterministic hashes;
read-only adapters;
KPI dashboards;
evidence review and provenance;
privacy and consent controls.

But the language must stay precise:

a candidate is not a consortium member;
a technical pilot is not a validated field pilot;
a company reviewing a concept is not yet a project partner;
an internal LIFE-oriented track is not EU LIFE funding.

For Circular Water, the correct approach is to build reusable, synthetic-data components first. If a water utility later authorizes a real case, only the authorized data, constraints, and measurements are connected to the shared framework.

Why this structure matters

The goal is not to centralize everyone’s work under one account or one server.

The goal is to make collaboration inspectable:

who owns the project?
what was actually tested?
what evidence is public?
what is proposed versus accepted?
what consent exists?
what can be reused safely?

That is how a contributor network becomes credible: not by making the biggest possible claim, but by preserving the boundary between evidence, consent, current work, and future ambition.

If you want to contribute, start with a small bounded task, publish reproducible evidence, and keep control of your own work. The network can connect it when both the technical and consent conditions are satisfied.

Hardhat 3 in a CommonJS Application: Isolating ESM Tooling Without Breaking CI

Daniel Ioni — Tue, 13 Oct 2026 04:28:50 +0000

Hardhat 3 in a CommonJS Application: Isolating ESM Tooling Without Breaking CI

Modernising blockchain tooling inside an established application is rarely just a dependency upgrade.

Our repository is primarily a CommonJS Node.js application: the server, most tests, and existing runtime scripts use require(). At the same time, we needed to move the NFT toolchain to Hardhat 3, which is ESM-first. A naïve migration—setting "type": "module" at the repository root—would have changed the module semantics of the whole application and created unnecessary runtime risk.

This article documents the approach we used instead: isolate the ESM toolchain, make mixed test execution deterministic, remove a high-severity dependency path, and verify the result without deploying anything to a public chain.

The constraints

The change had four non-negotiable constraints:

The existing CommonJS application had to remain CommonJS.
Solidity contracts and NFT scripts needed to run under Hardhat 3.
CommonJS Jest tests and ESM Node tests needed to run correctly in both local development and CI.
Dependency auditing had to fail on high and critical vulnerabilities without relying on unsafe automatic upgrades.

The goal was not to “make the build pass” at any cost. The goal was to make the boundaries explicit and testable.

Why converting the repository root was the wrong move

Hardhat 3 expects an ESM project. The obvious reaction is to add this to the root package.json:

{
  "type": "module"
}

That would make every .js file in the repository ESM by default. In a mature CommonJS application, that affects server startup, test helpers, scripts, configuration files, and dependencies that expect require().

The blockchain toolchain has different module requirements from the application runtime. Treating them as one module system turns a local migration into a repository-wide compatibility project.

The safer design was to create a narrow ESM boundary.

Create an isolated ESM workspace

We moved Solidity-specific tooling into a dedicated directory:

nft-tools/
  package.json
  hardhat.config.js
  contracts/
  scripts/

Its package.json is intentionally small:

{
  "name": "@myzubster/nft-tools",
  "private": true,
  "type": "module"
}

The root application remains CommonJS. Only the NFT workspace is ESM.

This lets the Hardhat configuration use native imports:

import { defineConfig } from "hardhat/config";
import hardhatEthers from "@nomicfoundation/hardhat-ethers";

export default defineConfig({
  plugins: [hardhatEthers],
  solidity: "0.8.28",
  paths: {
    sources: "./contracts",
    cache: "./cache",
    artifacts: "./artifacts"
  }
});

The separation is more than cosmetic. Hardhat resolves project files relative to its project boundary, so contracts must live inside that ESM workspace rather than outside it.

Migrate scripts deliberately

The previous NFT scripts used CommonJS:

const hre = require("hardhat");

In the isolated ESM workspace, they now use the Hardhat 3 runtime model:

import { network } from "hardhat";

const { ethers } = await network.getOrCreate();
const [owner] = await ethers.getSigners();

The scripts retain their original safety characteristics:

deployment and minting remain explicit commands;
public-chain operations require an external private-key environment variable;
local tests use Hardhat’s simulated network;
no real transaction is sent during compilation or local verification.

Root-level scripts make the intended boundary visible:

{
  "scripts": {
    "nft:compile": "cd nft-tools && ../node_modules/.bin/hardhat compile",
    "nft:test:local": "cd nft-tools && ../node_modules/.bin/hardhat run scripts/test-comic-nft.mjs"
  }
}

A local NFT test deploys the contract, mints a test token, and verifies ownership and metadata URI. It does not use a wallet, a public RPC account, or production funds.

Dependency audit: avoid destructive “fixes”

During the audit, the high-severity issue was not application code. It came from the development watcher dependency path:

nodemon → chokidar → braces

An automated npm audit fix --force proposed breaking downgrades, including old versions of development tooling. That is not a reliable security remediation strategy.

Instead, we removed the unnecessary watcher dependency and used Node’s built-in watch mode:

{
  "scripts": {
    "dev": "node --watch server.js"
  }
}

The dependency audit then had no high or critical findings. Moderate findings remain in Jest coverage-related transitive dependencies and are documented rather than hidden. The CI gate continues to fail on high or critical findings:

npm audit --audit-level=high

Security work should reduce exposure without silently introducing a different operational risk.

Mixed CommonJS and ESM tests need two runners

The repository contains two valid kinds of tests:

a large Jest suite for CommonJS application tests;
a small set of .test.mjs files that must run through Node’s native ESM test runner.

Jest can discover .mjs files, but attempting to execute them as CommonJS produces errors such as:

Must use import to load ES Module

The solution is not to force ESM tests through a CommonJS runner. Instead, the test command is an explicit two-stage process:

const { spawnSync } = require("node:child_process");

const esmTests = [
  "identity/credential/credential.test.mjs",
  "identity/verifier/verify.test.mjs",
  "identity/hash-verification/verify-hash.test.mjs",
  "workshop/app/domain.test.mjs",
  "workshop/app/integrate.test.mjs"
];

function run(command, args) {
  const result = spawnSync(command, args, {
    stdio: "inherit",
    env: process.env
  });

  if (result.error) throw result.error;
  if (result.status !== 0) process.exit(result.status || 1);
}

Jest is restricted to JavaScript test files:

module.exports = {
  testMatch: [
    "**/?(*.)+(test).js"
  ]
};

Then the ESM files run separately:

run(process.execPath, ["--test", ...esmTests]);

This gives each test type the runtime it actually requires.

The CI argument-forwarding trap

One subtle failure only appeared in CI.

The workflow called:

npm test -- --runInBand --testPathIgnorePatterns=/frontend/

Jest command-line options can override settings declared in jest.config.js. In this case, the workflow’s testPathIgnorePatterns replaced the repository configuration, allowing Jest to discover the ESM test files again.

The wrapper now filters that externally supplied ignore-pattern override before invoking Jest:

const jestArgs = process.argv.slice(2).filter(
  (arg) => !arg.startsWith("--testPathIgnorePatterns=")
);

run(process.execPath, [
  require.resolve("jest/bin/jest"),
  ...jestArgs
]);

The repository configuration remains the source of truth for test discovery; CI still passes useful execution options such as --runInBand.

This is a general lesson: forwarding CLI arguments blindly can change test semantics. A wrapper should forward only the arguments that are safe for that stage of the pipeline.

Verification results

The final verification was intentionally layered:

Jest:                 221 suites / 969 tests passed
Node ESM runner:       26 tests passed
Hardhat compile:       4 Solidity contracts compiled
Local NFT test:        deploy + mint + ownership + URI passed
Security audit:        no high or critical vulnerabilities

No deployment and no public-chain transaction were performed.

The pull request also passed the repository’s test, evidence, policy, security-audit, and secret-scanning checks. A Vercel status remained blocked by external deployment authorization, so it was treated as an environment-integration issue—not as evidence that the code had been deployed or independently validated.

What this migration changed

The important result is not simply “Hardhat 3 works.”

The repository now has clearer operational boundaries:

the application runtime remains CommonJS;
blockchain tooling is isolated in an ESM workspace;
CommonJS and ESM tests run with their native runners;
CI argument handling cannot accidentally re-enable incompatible test discovery;
local blockchain verification is explicit and does not touch public networks;
high- and critical-severity audit findings are gated without unsafe forced upgrades.

Tooling migrations are safest when they reduce ambiguity. In this case, separating module systems, test runners, and deployment intent made the codebase easier to verify—and harder to accidentally misuse.

Building the MyZubster Metaverse: Browser-First WebXR, Server-Authoritative Rooms, Versioned Scenes, and the Road Ahead

Daniel Ioni — Mon, 12 Oct 2026 13:21:01 +0000

Building the MyZubster Metaverse: Browser-First WebXR, Server-Authoritative Rooms, Versioned Scenes, and the Road Ahead
The MyZubster Metaverse is evolving from a narrative prototype into a browser-first, testable platform with explicit technical contracts.
The objective is not to build a VR-only experience. The objective is to create a shared digital environment that works on ordinary browsers first, can progressively enable WebXR when available, and can connect virtual experiences to real MyZubster projects—including LIFE-oriented environmental pilots.
This technical update covers:

What currently works
What we verified in production
The browser and WebXR capability layer
The server-authoritative room lifecycle
The versioned scene-manifest contract
Security and validation boundaries
How this connects to LIFE and evidence-based pilots
What is still missing
The next implementation milestones Repository: MyZubster-Ecosystem/myzubster Live entry point: MyZubster Metaverse
The Architecture We Are Building The current direction separates the metaverse into several technical layers: ┌───────────────────────────────────────────────────────────┐ │ Browser Experience │ │ │ │ React UI → capability checks → browser/WebXR fallback │ └───────────────────────────────┬───────────────────────────┘ │ ▼ ┌───────────────────────────────────────────────────────────┐ │ Metaverse Client Runtime │ │ │ │ Scene loading → controls → chat → emotes → interactions │ └───────────────────────────────┬───────────────────────────┘ │ ▼ ┌───────────────────────────────────────────────────────────┐ │ Server-Authoritative API │ │ │ │ Rooms → sessions → access → capacity → stage → tokens │ └───────────────────────────────┬───────────────────────────┘ │ ▼ ┌───────────────────────────────────────────────────────────┐ │ Versioned Scene Contract │ │ │ │ Assets → spawn points → zones → portals → capabilities │ └───────────────────────────────┬───────────────────────────┘ │ ▼ ┌───────────────────────────────────────────────────────────┐ │ Evidence / LIFE Layer │ │ │ │ Pilot → provenance → evidence → KPI/MRV → visualization │ └───────────────────────────────────────────────────────────┘ Each layer has a different responsibility. The browser detects what the device can do. The server controls room and session authority. The scene manifest defines what should be loaded. The evidence layer determines what claims can legitimately be represented. This separation matters because a 3D scene must not become the source of truth for authentication, permissions, environmental claims, or evidence.
What Works Today Neon Plaza is available directly from a browser. A VR headset, crypto wallet, native application, or dedicated GPU is not required for the standard experience. During our production desktop smoke test, we verified:
Authenticated access
Character-associated entry
Neon Plaza loading
An active online session
Movement controls
Emotes
Room chat
Browser capability detection
A non-blocking fallback when immersive WebXR is unavailable The critical product rule is: WebXR is an optional capability. It must never become a mandatory gateway to the MyZubster Metaverse.

Desktop and mobile browsers remain the baseline. VR devices can progressively enhance the experience when supported.
This is important for accessibility, adoption, testing, and compatibility with real-world projects. A LIFE participant, researcher, local community member, or developer should not need a headset simply to inspect a pilot, join a session, or understand a project.

Browser and WebXR Capability Detection The first implementation milestone was tracked in:
PR #1597 — Add non-blocking WebXR capability fallback The browser capability module defines explicit WebXR states: export const WEBXR_STATUS = Object.freeze({ CHECKING: 'checking', SUPPORTED: 'supported', UNSUPPORTED: 'unsupported', ERROR: 'error' }); This is intentionally more precise than a boolean such as hasWebXR. There are several meaningful conditions: checking │ ├── supported │ ├── unsupported │ └── error An unsupported API is different from a capability check that failed. A browser without navigator.xr is different from a browser exposing the API but rejecting the request. The implementation checks the browser baseline separately: export function browserCapabilityBaseline(browser = window) { return [ { label: 'JavaScript', ok: true }, { label: 'Fetch API', ok: typeof browser.fetch === 'function' }, { label: 'Storage locale', ok: Boolean(browser.localStorage) }, { label: 'CSS Grid', ok: Boolean(browser.CSS?.supports?.('display', 'grid')) }, { label: 'Connessione', ok: browser.navigator?.onLine !== false } ]; } WebXR support is detected asynchronously: export async function detectImmersiveVr( navigatorLike = navigator ) { if (!navigatorLike?.xr?.isSessionSupported) { return { status: WEBXR_STATUS.UNSUPPORTED, reason: 'api-unavailable' }; }

try {
const supported =
await navigatorLike.xr.isSessionSupported('immersive-vr');

return {
  status: supported
    ? WEBXR_STATUS.SUPPORTED
    : WEBXR_STATUS.UNSUPPORTED,
  reason: supported ? null : 'session-unsupported'
};

} catch (_error) {
return {
status: WEBXR_STATUS.ERROR,
reason: 'capability-check-failed'
};
}
}
Why dependency injection matters here
The function accepts navigatorLike instead of directly depending on the global navigator internally.
That makes capability behavior testable:
await detectImmersiveVr({
xr: {
isSessionSupported: async () => true
}
});
It also allows us to test unsupported and error conditions without requiring an actual headset in every CI run.

Non-Blocking Fallback UX Capability detection is connected to a React component that communicates the system state to the user. A simplified version of the state mapping is: const XR_COPY = { checking: 'Checking WebXR support…', supported: 'Immersive WebXR is available', unsupported: 'Browser mode active: a headset is not required', error: 'WebXR could not be verified: continue in browser mode' }; The important behavior is not just the message. It is the absence of a blocking redirect or fatal error. const browserReady = checks.every((check) => check.ok);

const ready =
browserReady &&
xr.status !== WEBXR_STATUS.CHECKING;
When immersive VR is unavailable, the interface explicitly keeps the browser path open:
{xr.status !== WEBXR_STATUS.SUPPORTED && (

Neon Plaza remains accessible from desktop and mobile.
The WebXR check never blocks entry.

)}
This approach supports progressive enhancement:
Basic browser
↓
Neon Plaza browser experience
↓
Optional advanced capabilities
├── richer graphics
├── immersive WebXR
├── spatial input
└── device-specific controls
The baseline must remain usable even when one of the enhancement layers is unavailable.

Server-Authoritative Room Lifecycle The metaverse is not controlled only by client-side React state. Rooms and sessions have server-authoritative lifecycle states: const ROOM_TRANSITIONS = Object.freeze({ draft: new Set(['published']), published: new Set(['scheduled', 'live']), scheduled: new Set(['live']), live: new Set(['ended']), ended: new Set(['archive']), archive: new Set([]) }); This gives us a forward-only state machine: draft │ ▼ published │ ├───────────────┐ ▼ ▼ scheduled live │ │ └───────►───────┘ ▼ ended │ ▼ archive Invalid reverse transitions are rejected. For example: if ( patch.state && patch.state !== room.state ) { if (!ROOM_TRANSITIONS[room.state]?.has(patch.state)) { return { valid: false, status: 409, error: Invalid room transition + ${room.state} -> ${patch.state} }; }

room.state = patch.state;
}
This prevents a browser client from arbitrarily changing an ended room back to live.
The client requests a transition. The server decides whether it is valid.

Room Access and Capacity A virtual room can currently use one of three access policies: accessPolicy: { type: String, enum: [ 'public', 'authenticated', 'private' ], default: 'authenticated' } Capacity is bounded at the model and service layers: capacity: { type: Number, min: 1, max: 500, default: 100 } Join validation checks:
Session state
Blocklist
Private-room allowlist
Host access
Current participant count
Existing membership async function validateJoin({ session, room, actorUserId }) { if (session.state !== 'live') { return { valid: false, status: 409, error: 'Session is not live' }; }

const actor = String(actorUserId);

if ((room.blockedUserIds || []).includes(actor)) {
return {
valid: false,
status: 403,
error: 'Access blocked'
};
}

if (
room.accessPolicy === 'private' &&
!(room.allowedUserIds || []).includes(actor) &&
actor !== String(room.hostUserId)
) {
return {
valid: false,
status: 403,
error: 'Private room access denied'
};
}

const current =
new Set(session.participantUserIds || []);

if (
!current.has(actor) &&
current.size >= session.capacity
) {
return {
valid: false,
status: 409,
error: 'Session is at capacity'
};
}

return { valid: true };
}
The server therefore remains authoritative over membership. A modified browser cannot legitimately join a closed or full session simply by changing local state.

Short-Lived Realtime Tokens After a successful join, the backend can mint a short-lived realtime token. The token is scoped to:
The authenticated user
A specific purpose
A session
A room
A scene-manifest version function mintRealtimeToken( session, actorUserId ) { const secret = process.env.REALTIME_TOKEN_SECRET || process.env.JWT_SECRET;

if (!secret) {
throw new Error(
'Realtime token secret is not configured'
);
}

return jwt.sign({
sub: String(actorUserId),
purpose: 'metaverse-realtime',
sessionId: session.sessionId,
roomId: session.roomId,
sceneManifestVersion:
session.sceneManifestVersion
}, secret, {
expiresIn: '5m'
});
}
The five-minute expiration limits the lifetime of captured tokens.
Future work will need to evaluate:

Token refresh
Revocation semantics
Horizontal realtime scaling
Redis-backed session coordination
Replay resistance
Rate limiting
Reconnect behavior
Multi-region latency
Moderation Without Exposing Raw Account IDs Moderation references are generated as opaque identifiers rather than exposing account IDs directly in public session views. function moderationParticipantRef( sessionId, actorUserId ) { return hashRoomInviteCode( ${sessionId}:${actorUserId} ).slice(0, 24); } Room blocklist references are scoped separately: function blockedParticipantRef( roomId, actorUserId ) { return hashRoomInviteCode( blocklist:${roomId}:${actorUserId} ).slice(0, 24); } This does not make the system anonymous by itself, but it reduces unnecessary identifier exposure in moderation interfaces. The server supports actions such as:
Removing a participant from a live session
Blocking a participant from a room
Removing pending stage requests
Revoking speaker status
Listing blocklist entries through opaque references The public session representation also excludes raw participant arrays: function publicSession(session) { return { id: session.sessionId, roomId: session.roomId, state: session.state, capacity: session.capacity, participantCount: (session.participantUserIds || []).length, sceneManifestVersion: session.sceneManifestVersion, lifecycleVersion: session.lifecycleVersion, startedAt: session.startedAt || null, endedAt: session.endedAt || null }; }
Versioned Scene Manifest v1 The second major implementation milestone was delivered through:
PR #1601 — Validate versioned scene manifests before publication The manifest establishes an explicit contract between the room configuration, asset pipeline, backend, and client runtime. The current schema version is: const SCENE_MANIFEST_SCHEMA_VERSION = '1'; Supported asset types are intentionally constrained: const ASSET_TYPES = new Set([ 'gltf', 'glb', 'image', 'audio', 'video' ]); The initial contract also defines allowed zone types, lighting presets, and capability requirements: const ZONE_TYPES = new Set([ 'portal', 'stage', 'link' ]);

const LIGHTING_PRESETS = new Set([
'day',
'sunset',
'night',
'studio'
]);

const CAPABILITIES = new Set([
'webgl2',
'webxr-immersive-vr',
'audio',
'video'
]);

Safe Default Manifest
Every newly created room receives a minimal valid scene manifest:
function defaultSceneManifest() {
return {
schemaVersion:
SCENE_MANIFEST_SCHEMA_VERSION,

assetBundleVersion: '1',

assets: [],

spawnPoints: [
{
id: 'default',
position: [0, 0, 0]
}
],

interactionZones: [],

stage: {
position: [0, 0, 0],
capacity: 1
},

lighting: {
preset: 'day'
},

capabilities: []
};
}
This provides a known baseline rather than leaving newly created rooms in an undefined state.
The room creation service persists this default:
const room = await VirtualRoom.create({
roomId: crypto.randomUUID(),
slug: safeSlug,
name: safeName,
hostUserId: String(actorUserId),
accessPolicy,
capacity: numericCapacity,
stagePolicy,
sceneManifest: defaultSceneManifest()
});
Example of a More Complete Scene Manifest
A future Neon Plaza manifest could look like this:
{
"schemaVersion": "1",
"assetBundleVersion": "42",
"assets": [
{
"id": "neon-plaza",
"type": "glb",
"url": "https://cdn.myzubster.com/scenes/neon-plaza.42.glb"
},
{
"id": "ambient-track",
"type": "audio",
"url": "https://cdn.myzubster.com/audio/neon-plaza.7.ogg"
},
{
"id": "life-dashboard",
"type": "image",
"url": "https://cdn.myzubster.com/life/pilot-dashboard.12.webp"
}
],
"spawnPoints": [
{
"id": "main-entrance",
"position": [0, 1.6, 4]
},
{
"id": "life-hub",
"position": [12, 1.6, -3]
}
],
"interactionZones": [
{
"id": "life-portal",
"type": "portal",
"position": [10, 0, -3],
"radius": 1.5,
"destination": "life-hub"
},
{
"id": "pilot-details",
"type": "link",
"position": [14, 1, -4],
"radius": 1,
"destination": "https://www.myzubster.com/life-pilot"
}
],
"stage": {
"position": [0, 0, -8],
"capacity": 30
},
"lighting": {
"preset": "sunset"
},
"capabilities": [
"webgl2",
"audio"
]
}
This is a contract, not an arbitrary JSON document.
The server validates its structure before accepting it.
Input Validation and Security Boundaries
Manifest IDs must use a constrained format:
function validId(value) {
return (
typeof value === 'string' &&
/^[a-zA-Z0-9][a-zA-Z0-9_-]{0,63}$/.test(value)
);
}
Coordinates must contain exactly three finite values:
function validVector(value) {
return (
Array.isArray(value) &&
value.length === 3 &&
value.every(Number.isFinite)
);
}
Asset and external-link URLs must use HTTPS:
function validHttpsUrl(value) {
if (
typeof value !== 'string' ||
value.length > 2048
) {
return false;
}

try {
return new URL(value).protocol === 'https:';
} catch {
return false;
}
}
This blocks obvious unsafe values such as:
javascript:alert(1)
http://untrusted.example/asset.glb
invalid-url
HTTPS validation alone does not solve every asset-security problem. Future protections should include:

Approved asset origins
Content-Type verification
Maximum file size
Download timeouts
Hash or checksum validation
Malware scanning where applicable
glTF structural validation
Texture and geometry limits
CORS verification
Redirect restrictions
Decompression-bomb protections
Asset-license metadata
Bounded Collections The validator limits the number of objects that can be supplied. For example: if ( !Array.isArray(input.assets) || input.assets.length > 100 ) { errors.push( 'assets must be an array with at most 100 entries' ); } Spawn points are also bounded: if ( !Array.isArray(input.spawnPoints) || input.spawnPoints.length < 1 || input.spawnPoints.length > 32 ) { errors.push( 'spawnPoints must contain between 1 and 32 entries' ); } Bounding collection sizes reduces accidental or malicious resource amplification before scene loading begins. Client-side budgets will still be needed for:
Triangle count
Texture memory
Audio duration
Video resolution
Animation count
Shader complexity
Draw calls
Concurrent network requests
Duplicate and Invalid Spawn Points Spawn-point IDs must be valid and unique: const ids = new Set();

input.spawnPoints.forEach((spawn, index) => {
if (!isRecord(spawn) || !validId(spawn.id)) {
errors.push(
spawnPoints[${index}].id is invalid
);
} else if (ids.has(spawn.id)) {
errors.push(
spawnPoints[${index}].id must be unique
);
} else {
ids.add(spawn.id);
}

if (
!isRecord(spawn) ||
!validVector(spawn.position)
) {
errors.push(
spawnPoints[${index}].position +
'must be a finite xyz vector'
);
}
});
This prevents ambiguous spawn resolution and invalid coordinates such as:
{
"id": "entrance",
"position": [0, null, 4]
}
or:
{
"id": "entrance",
"position": [0, 1]
}

Portal and Link Validation Interaction zones can currently represent:
Portals
Stage areas
External links Portal destinations must be valid internal identifiers: if ( zone?.type === 'portal' && !validId(zone.destination) ) { errors.push( interactionZones[${index}].destination + 'is required for portals' ); } External links must use HTTPS: if ( zone?.type === 'link' && !validHttpsUrl(zone.destination) ) { errors.push( interactionZones[${index}].destination + 'must use https for links' ); } A complete implementation will also need to distinguish: internal room destination internal MyZubster route approved external URL blocked external URL missing destination temporarily unavailable destination
Validation Before Publication The most important server-side behavior is the publication gate. When the client supplies a new manifest—or tries to publish a draft—the backend validates the candidate first: const manifestCandidate = patch.sceneManifest !== undefined ? patch.sceneManifest : room.sceneManifest;

if (
patch.sceneManifest !== undefined ||
patch.state === 'published'
) {
const manifestValidation =
validateSceneManifest(manifestCandidate);

if (!manifestValidation.valid) {
return {
valid: false,
status: 400,
error: 'Invalid scene manifest',
details: manifestValidation.errors
};
}

room.sceneManifest =
manifestValidation.manifest;
}
Only after this check can the room continue through the lifecycle transition.
The intended invariant is:
invalid manifest
│
▼
HTTP 400
│
└── publication rejected
while:
valid manifest
│
▼
lifecycle validation
│
▼
draft → published
This is stronger than validating only in the frontend. Frontend validation improves UX, but it cannot be authoritative because requests can be sent outside the official UI.

Persisting the Scene Contract The room model now stores both the manifest version and manifest content: sceneManifestVersion: { type: String, default: '1' },

sceneManifest: {
type: mongoose.Schema.Types.Mixed,
default: null
}
The public room representation includes the scene configuration:
function publicRoom(room) {
return {
id: room.roomId,
slug: room.slug,
name: room.name,
state: room.state,
accessPolicy: room.accessPolicy,
capacity: room.capacity,
stagePolicy: room.stagePolicy,
sceneManifestVersion:
room.sceneManifestVersion,
sceneManifest:
room.sceneManifest || null,
scheduledFor:
room.scheduledFor || null
};
}
This is the first version of the contract. It is not the final persistence design.
The next implementation should separate the current manifest pointer from immutable historical versions.

Testing the Contract The validator includes tests for:
A safe default manifest
Versioned asset bundles
Valid spawn points
Valid interaction zones
Portal destinations
HTTPS links
Unsupported schema versions
Insecure asset URLs
Malformed vectors
Duplicate IDs
Unsupported capability requirements
A simplified example:
test(
'rejects unsupported schema versions and insecure asset urls',
() => {
const manifest = {
...defaultSceneManifest(),

schemaVersion: '2',

assets: [{
id: 'plaza',
type: 'glb',
url: 'http://cdn.example.com/plaza.glb'
}]
};

const result =
validateSceneManifest(manifest);

expect(result.valid).toBe(false);

expect(result.errors).toEqual(
expect.arrayContaining([
'schemaVersion must be 1',
'assets[0].url must use https'
])
);
}
);
Another test verifies malformed vectors and duplicate IDs:
test(
'rejects malformed vectors, duplicate ids and unsupported capabilities',
() => {
const manifest = {
...defaultSceneManifest(),

spawnPoints: [
{
id: 'same',
position: [0, 0]
},
{
id: 'same',
position: [0, 0, Number.NaN]
}
],

capabilities: ['telepathy']
};

const result =
validateSceneManifest(manifest);

expect(result.valid).toBe(false);
}
);
The merged changes passed:
Backend lint
Backend unit tests
Frontend unit tests
Backend build
Frontend build
Security audit
Continuous evidence checks
What We Verified in Production
The current evidence boundary is important.
We verified the following using a desktop browser against the production environment:
The metaverse page loaded
Authentication was active
Neon Plaza loaded
The session appeared online
Controls were visible
Emotes were available
Chat was available
The browser capability panel rendered
Baseline browser checks passed
WebXR fallback messaging appeared
The experience remained accessible without immersive WebXR
We have not yet treated the following as fully verified:
Real-device mobile behavior
Real-headset WebXR entry
Real-headset WebXR exit
Controller input across different headsets
Long-running realtime reliability
High-concurrency room behavior
CDN-backed versioned 3D asset loading
Manifest rollback in production
Complete accessibility validation
A full LIFE pilot represented in the scene
This distinction prevents roadmap intentions from being reported as completed features.
Connecting the Metaverse to LIFE
The MyZubster Metaverse should not become only a visual or social layer.
Its more valuable role is to become an interface between:
Real-world pilots
Technical evidence
Community participation
Education
Environmental indicators
Replicable workflows
The proposed LIFE-oriented flow is:
Real-world pilot
↓
Observation or measurement
↓
Data provenance
↓
Evidence classification
↓
KPI / MRV calculation
↓
MyZubster project record
↓
Metaverse representation
↓
Mission or educational interaction
↓
Community feedback
↓
Improved pilot
Example
Imagine a LIFE-oriented water or circular-agriculture pilot.
A participant enters Neon Plaza and approaches a portal labelled “Water Pilot”.
The portal opens a dedicated scene. Inside that scene, the participant can inspect:
The pilot location at an appropriate privacy level
The project methodology
The instruments or sensors used
The observation period
Current evidence status
Relevant KPIs
Data-quality warnings
Missing evidence
Replication instructions
Public contribution tasks
The scene might include a dashboard, but the dashboard must reference an authoritative evidence record.
The scene itself is not evidence.
3D visualization ≠ verified measurement
simulation ≠ real-world result
self-declaration ≠ independent validation
project goal ≠ achieved impact
The UI should make these boundaries visible.
Evidence States for LIFE Scenes
A useful next contract could attach evidence states to interactive objects:
{
"id": "water-savings-display",
"type": "evidence-panel",
"position": [4, 1.5, -2],
"evidence": {
"status": "measured",
"source": "pilot-observation-2026-10",
"methodologyVersion": "0.2",
"verifiedBy": null,
"independentVerification": false
}
}
Possible evidence states could include:
planned
self-declared
observed
measured
methodology-reviewed
independently-verified
disputed
superseded
This would allow the metaverse client to render different visual treatments:
verified data → solid green indicator
measured, unverified → amber indicator
self-declared → blue information indicator
simulation → purple simulation indicator
missing evidence → grey warning indicator
disputed → red review indicator
The goal is not to gamify uncertainty away. The goal is to make uncertainty understandable.
What Is Still Missing
The current implementation is a foundation, not a finished metaverse stack.
22.1 Real mobile-device validation
We still need structured testing on real devices:
Android Chrome
Android Firefox
iOS Safari
iPadOS Safari
Low-memory devices
Slow or unstable networks
Small screens
Touch-only navigation
Orientation changes
Background and resume behavior
The UI claims that mobile browser access is supported as the intended baseline, but a complete real-device verification matrix is still required.
22.2 Real WebXR headset testing
We need physical tests for:
Entering immersive mode
Exiting immersive mode
Session interruption
Controller input
Focus loss
Guardian or boundary changes
Headset sleep and resume
Unsupported-feature fallback
Audio behavior
Motion comfort
Performance degradation
Automated capability tests cannot replace physical-device validation.
22.3 Immutable manifest history
The current room stores its active manifest.
The next persistence layer should add immutable versions:
{
roomId: 'room-123',
version: '7',
schemaVersion: '1',
assetBundleVersion: '42',
checksum: 'sha256:...',
manifest: { /* immutable snapshot */ },
createdBy: 'account-reference',
createdAt: '2026-10-12T...'
}
A room should point to an active version rather than mutating history:
VirtualRoom
activeManifestVersion → 7

SceneManifestVersion
version 5
version 6
version 7
22.4 Safe rollback
Rollback should not destroy newer history.
Instead, it should create a new version based on a previous valid snapshot:
v5 → v6 → v7
│
└── rollback requested
↓
v8
content derived from v6
That preserves auditability.
22.5 CDN and cache invalidation
Versioned asset URLs should be immutable:
/scenes/neon-plaza.42.glb
/textures/plaza-floor.18.webp
/audio/neon-ambient.7.ogg
The manifest can change its pointer to a new asset version, while previous versions remain available for rollback.
The CDN layer needs:

Immutable cache headers
Content hashes
CORS configuration
Range requests where appropriate
Compression strategy
Cache invalidation rules
Origin failure handling
Asset availability checks 22.6 Graceful asset failure A missing decorative object should not necessarily prevent the whole scene from loading. The client needs failure classes: critical asset failure └── load fallback scene

important asset failure
└── continue with visible warning

optional asset failure
└── omit asset and continue
A future manifest entry could declare this explicitly:
{
"id": "neon-plaza",
"type": "glb",
"url": "https://cdn.myzubster.com/scenes/neon-plaza.42.glb",
"criticality": "critical",
"fallbackAssetId": "basic-plaza"
}
22.7 Resource budgets
Schema validity does not guarantee runtime safety.
We still need budgets for:

Asset file size
Texture dimensions
Total texture memory
Polygon count
Draw calls
Animation complexity
Audio memory
Video resolution
Concurrent downloads
Scene initialization time 22.8 Realtime load testing The realtime system needs controlled tests for:
Concurrent joins
Concurrent leaves
Chat bursts
Stage requests
Participant moderation
Token refresh
Reconnect storms
Server restart
Database latency
Redis degradation
Network partitions 22.9 Accessibility The browser-first experience needs continued testing for:
Keyboard navigation
Screen-reader labels
Focus management
Reduced motion
Colour contrast
Text scaling
Captions
Non-spatial alternatives
Touch targets
Cognitive load An immersive view cannot be the only way to access important project information. 22.10 LIFE evidence integration The first complete LIFE scene still needs:
A selected pilot
A defined methodology
A provenance contract
Evidence states
KPI definitions
MRV boundaries
Privacy rules
A public scene representation
A contribution workflow
A validation and review process
Proposed Next Technical Milestones The next roadmap can be structured into the following slices. C2.1 — Immutable manifest versions Create manifest version model → calculate checksum → store immutable snapshot → point room to active version C2.2 — Manifest rollback Select historical version → validate snapshot → create new version → update active pointer → preserve audit history C2.3 — Asset pipeline Upload → validate → scan → optimize → hash → version → CDN publish → manifest reference C2.4 — Client scene loader Fetch room → fetch manifest → check schema version → check capabilities → load critical assets → load optional assets → expose failures → enter scene C2.5 — LIFE pilot scene Pilot record → evidence contract → KPI/MRV mapping → manifest generation → scene visualization → public test
Links to the Work Main repository
MyZubster-Ecosystem/myzubster Browser and WebXR fallback
PR #1597 — Non-blocking WebXR capability fallback Versioned scene manifest
PR #1601 — Scene manifest validation and publication gate Live experience
MyZubster Metaverse
MyZubster
LIFE Pilot
How Developers Can Contribute The most useful contributions right now include:
Android and iOS browser test reports
Real-headset WebXR test reports
Scene-manifest reviews
glTF and GLB validation
3D performance budgets
Asset fallback design
Accessibility reviews
Realtime load-test scenarios
Security reviews
CDN architecture
Manifest version-history design
Rollback implementation
LIFE evidence modelling
KPI and MRV data contracts
Technical documentation A useful contribution should include reproducible evidence: environment browser or device exact version steps performed expected result observed result screenshots or logs when safe related issue or pull request Please do not publish:
Passwords
Authentication tokens
Private wallet keys
Seed phrases
Private participant information
Precise sensitive locations
Unredacted personal data Conclusion The MyZubster Metaverse now has two important foundations:
A browser-first runtime that treats WebXR as progressive enhancement
A server-side scene contract that blocks invalid manifests from publication The completed work is publicly traceable through:
PR #1597
PR #1601 The next challenge is not simply adding more 3D content. It is building a reliable chain from versioned assets and authoritative sessions to transparent, evidence-aware virtual experiences: code → validated contract → versioned scene → reliable session → real-world pilot → evidence → understandable visualization → community contribution That is the direction of the MyZubster Metaverse: an open, browser-first environment where virtual experiences connect to documented projects, reproducible evidence, and real-world collaboration. Status verified: October 12, 2026.

Bringing MyZubster to the Tor Network: Building an Onion with Docker, React and Node.js

Daniel Ioni — Sat, 10 Oct 2026 04:12:57 +0000

Bringing MyZubster to the Tor Network: Building an Onion Service with Docker, React and Node.js

Building a privacy-conscious access layer for an open-source ecosystem — with real tests, reproducible bugs, and contributions from the community.

The next chapter of MyZubster is taking shape.

We're working toward making MyZubster accessible through the Tor network using a .onion address, alongside our traditional website.

This is not just about adding Tor to a Docker container. It's about understanding how an Onion Service interacts with an existing application stack, how we protect its identity, and how we make the deployment reliable.

And we're building it openly, with community contributors.

Meet the contributors

Two people deserve particular recognition for the work we're currently reviewing and validating.

Mohammed Wasim Khan — GitHub: @wasim-builds

Wasim has been working on a pull request that brings together improvements to Docker infrastructure, backend services, frontend configuration, and the Tor integration.

His current contribution is available here:

MyZubster PR #1582 — Wasim's contribution

Nicola — N4K48

Nicola's independent pilot and earlier contribution form an important part of the work that is now being reviewed and extended.

You can explore the original contribution here:

MyZubster PR #1457 — Nicola / N4K48

This is the kind of open-source collaboration we want to encourage: independent experiments, code contributions, technical review, reproducible tests, and improvements that can eventually benefit the wider ecosystem.

What are we building?

The objective is to provide a second access path to MyZubster through a Tor Onion Service.

The proposed architecture looks like this:

          TRADITIONAL WEB
                 |
            MyZubster
                 |
              Nginx
                 |
                 v
        +----------------+
        | React Frontend |
        +----------------+
                 |
                 v
        +----------------+
        | Node.js API    |
        +----------------+
                 |
                 v
        +----------------+
        | MongoDB        |
        +----------------+


             TOR NETWORK
                 |
          Tor Browser
                 |
          .onion address
                 |
        +----------------+
        | Tor Container  |
        | Hidden Service |
        +----------------+
                 |
          Docker Network
                 |
                 v
        +----------------+
        | React Frontend |
        | Nginx          |
        +----------------+
                 |
                 v
             Backend API

The concept is simple:

The Onion Service is an alternative entry point, not a replacement for the application.

The backend and database do not need to expose public ports just because users can reach the frontend over Tor.

That separation is an important part of the deployment design.

Technology stack

The components under test include:

Docker and Docker Compose for service isolation.
Tor on Debian Bookworm.
React for the frontend.
Nginx for serving the application and proxying API requests.
Node.js and Express for backend services.
MongoDB for application data.
JWT middleware for authentication and authorization.

The Tor container runs using the dedicated debian-tor user.

The Onion Service identity is designed to persist through a Docker volume, and telemetry is disabled by default.

These are useful foundations, but secure and reliable operation still requires runtime validation.

What we tested on an isolated VPS

We created a dedicated Docker test environment rather than deploying the pull request directly into production.

The environment used separate containers, an internal Docker network, and a dedicated MongoDB volume.

No application ports were published to the VPS host as part of these tests.

1. Backend and MongoDB

The backend image compiled successfully.

However, the original backend initially failed during startup because of an incorrect middleware import:

Cannot find module '../../../src/middleware/auth'

The affected file was:

backend/src/routes/metaverse.js

We tested a one-line local correction:

-const { authenticate, optionalAuthenticate } = require('../../../src/middleware/auth');
+const { authenticate, optionalAuthenticate } = require('../middleware/auth');

After rebuilding with that local change, the backend started and connected to MongoDB.

The health endpoint returned HTTP 200.

Important: this fix was tested locally; the pull request itself still needs the correction.

2. Ledger and Economics APIs

We also exercised the application's experimental API endpoints.

Results included:

API	Result
`GET /api/ledger`	HTTP 200
`GET /api/ledger/balances`	HTTP 200
`POST /api/economics/simulate`	HTTP 200

The simulation returned internally consistent results using synthetic inputs, including a GMV of 200, revenue of 10, costs of 22, and a monthly margin of -12.

These tests demonstrate working API responses in the isolated environment, not production financial operations.

3. Authentication and authorization

We ran seven targeted checks across Chat, Notifications, and an administrative metrics endpoint.

All seven passed.

The tests included requests without tokens, invalid bearer tokens, valid synthetic user tokens, and valid synthetic administrator tokens.

The administrative endpoint returned:

No token       -> HTTP 401
Standard user  -> HTTP 403
Administrator  -> HTTP 200

This gives us encouraging evidence about the specific middleware paths we tested, although it is not a complete security audit.

4. React and Nginx

The React production build completed successfully.

The frontend Docker image also built, and Nginx validated on the isolated Docker network.

We confirmed:

GET /                       -> 200
GET /synthetic-spa-route    -> 200
GET /api/ledger             -> 200
GET /api/ledger/balances    -> 200

The last two requests passed through the Nginx reverse proxy to the backend.

We also identified a build-hardening improvement.

The frontend Dockerfile currently includes:

RUN npm run build || echo "Build skipped for now"

That can conceal future React compilation failures.

For a deployment image, we recommend making the build fail when compilation fails:

RUN npm run build

The most interesting challenge: Tor and Docker DNS

The Onion Service component introduced a particularly useful debugging exercise.

The original entrypoint generated a Tor configuration with a destination similar to:

HiddenServicePort 80 frontend:80

Here, frontend is the Docker Compose service name.

Docker containers can resolve that hostname through their internal DNS service.

However, when we tested this configuration with Tor 0.4.9.11, the validation failed:

Unparseable address in hidden service port configuration.
Failed to parse/validate config.

Using a numeric IP address passed Tor's configuration validation.

We therefore tested a local candidate approach: resolve the Docker service name before generating torrc.

For example:

TARGET_HOST=${ONION_TARGET_HOST:-frontend}
TARGET_IP=$(getent ahostsv4 "$TARGET_HOST" | awk 'NR == 1 {print $1}')

Then generate the destination using the resolved address:

HiddenServicePort 80 <resolved-container-ip>:80

In our isolated environment, Docker DNS resolved the frontend to an internal IP.

We confirmed that:

The Tor container could resolve the frontend hostname.
The frontend responded with HTTP 200 from that Docker network.
The configuration using the resolved IP passed tor --verify-config.
The modified Onion image built successfully.
The modified entrypoint generated a configuration accepted by Tor.

But there is a catch

Docker container IP addresses are not necessarily stable.

If the frontend is recreated, its address may change.

Resolving the address only once at startup may therefore leave Tor pointing at an outdated destination.

This is why we're treating the change as a tested candidate fix, not a final production solution.

A robust design needs to account for startup readiness, service recreation, address changes, and safe reconfiguration.

Privacy and operational considerations

Supporting .onion access does not automatically make the entire application anonymous.

Authentication, application logs, external resources, browser behavior, and telemetry all matter.

Our current approach emphasizes separation of services, protection of Onion identity material, and explicit privacy boundaries.

Telemetry is disabled by default.

We also want to improve the Tor health check. Merely detecting a generated Onion hostname file does not prove that the service is reachable through the Tor network.

What is still missing?

Before we can describe the Onion deployment as ready for public use, we need to complete several tasks:

Integrate the backend authentication import correction.
Implement resilient destination resolution for Tor.
Handle frontend recreation and Docker DNS readiness.
Improve Tor health and connectivity checks.
Make frontend Docker builds fail reliably on compilation errors.
Validate the actual Onion Service in a controlled Tor-network test.
Verify browser functionality and end-to-end behavior.
Review application privacy boundaries and security before public deployment.

We have not yet launched or independently verified a publicly reachable MyZubster .onion service through these tests.

The work is in active development and review.

Why this matters

For us, open source means more than publishing code.

It means giving contributors meaningful work, recognizing their contributions, reproducing problems independently, and sharing evidence even when something doesn't work yet.

Nicola's N4K48 work and Wasim's ongoing contribution demonstrate how independent efforts can be reviewed and developed toward a shared technical goal.

And the Tor integration raises questions that other Docker and privacy-focused developers may have encountered before.

We would love feedback from the community

If you have experience with Tor Onion Services, Docker DNS, container lifecycle management, Nginx, or privacy-conscious infrastructure, we'd especially appreciate your input.

How would you handle a Tor Onion Service backend whose Docker container IP can change after recreation?

Would you use a local forwarding proxy, a service-discovery strategy, controlled Tor configuration reloads, or something else?

We're interested in practical, reproducible approaches.

Explore the project and contributors

MyZubster repository:

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

MyZubster website:

https://www.myzubster.com/

Wasim — GitHub profile:

https://github.com/wasim-builds

Wasim — current pull request #1582:

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

Nicola / N4K48 — original contribution #1457:

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

A sincere thank you to Wasim and Nicola for contributing their work to the MyZubster ecosystem.

We're building this step by step, testing carefully, and keeping the process open for people who want to help.

The next milestone isn't simply having an Onion address. It's making that address reliable, secure, maintainable, and useful.

And that's something worth building together.

Debugging ZORGAX: How We Traced an AI Agent Tool-Calling Loop from Open WebUI to Ollama

Daniel Ioni — Fri, 09 Oct 2026 06:24:19 +0000

Debugging ZORGAX: How We Traced an AI Agent Tool-Calling Loop from Open WebUI to Ollama

An evidence-first debugging story, with a reproducible test and an open invitation to contributors.

Building an AI agent is not just about making a language model call tools. It is also about ensuring the model knows when to stop.

While developing ZORGAX, a local DevOps AI agent within the MyZubster ecosystem, I encountered a tool-calling problem: when asked which automations were active, ZORGAX repeatedly invoked list_automations even after the tool returned a successful empty result.

The expected behavior was simple:

Call list_automations.
Receive {"automations":[],"total":0}.
Tell the user that no automations are active.
Stop.

Instead, the Open WebUI integration sometimes repeated the tool call until interrupted.

We investigated the problem using a custom ZORGAX model derived from Qwen2.5 3B, Ollama, Open WebUI, Docker, and a temporary HTTP diagnostic proxy.

Here is what we discovered.

1. The first clue: direct Ollama worked

Our first experiment bypassed Open WebUI.

We sent a synthetic conversation to Ollama's /api/chat endpoint, including an assistant tool call and a matching tool result.

The result was exactly what we wanted:

Content: Non ci sono automazioni attive al momento.
Tool calls: []
Done: True

ZORGAX understood the empty result and produced a final answer without calling the tool again.

This was useful, but it did not prove Open WebUI was at fault. The direct test used a simplified system prompt and tool schema. We needed to compare the actual integration path.

2. Following the tool result through Open WebUI

A commenter on our earlier Coder Legion article suggested a more precise investigation: capture the request immediately after the first list_automations result and compare it with a working Ollama control.

That changed the direction of our debugging.

We inspected the installed Open WebUI source and identified its tool-call continuation flow.

The middleware transforms tool execution output back into conversation messages, including the assistant's tool_calls and a matching role: tool message.

Rather than relying on source inspection alone, we extracted and exercised the actual convert_output_to_messages() function using a harmless fixture.

The test produced:

[
  {
    "role": "assistant",
    "content": "",
    "tool_calls": [
      {
        "id": "zorgax-test-001",
        "type": "function",
        "function": {
          "name": "list_automations",
          "arguments": "{}"
        }
      }
    ]
  },
  {
    "role": "tool",
    "tool_call_id": "zorgax-test-001",
    "content": "{\"automations\":[],\"total\":0}"
  }
]

The conversion test passed.

That ruled out a basic failure of this function for our isolated empty-result case. It did not establish that every subsequent network request would preserve the same structure.

3. Adding a safety limit

We also found that the investigated Open WebUI build had a default limit of 256 tool-call iterations.

For debugging, that was far more than we needed.

In our test setup, we configured:

environment:
  CHAT_RESPONSE_MAX_TOOL_CALL_ITERATIONS: "3"

After applying the setting, an isolated Open WebUI experiment reproduced the repeated calls and stopped with:

Tool-call iteration limit reached (3)

This was a safety improvement, not a root-cause fix. A single iteration can contain multiple tool calls, so the limit should not be interpreted as an exact cap on individual invocations.

4. Building a disposable diagnostic environment

We created a separate Open WebUI instance rather than modifying the main MyZubster interface.

We then added a harmless custom tool:

"""
title: ZORGAX Automation Test
description: Safe automation-listing test fixture.
version: 1.0.0
"""

class Tools:
    def list_automations(self) -> dict:
        """Return a synthetic list of active automations."""
        return {
            "automations": [],
            "total": 0
        }

This function never reads real automations, touches a database, or performs an administrative action.

That isolation matters. Debugging an agent with operational tools should not require putting production infrastructure at risk.

5. Capturing the actual Ollama requests

Next, we introduced a temporary HTTP proxy between the diagnostic Open WebUI instance and Ollama.

The proxy forwarded requests while recording only structural metadata: model name, message roles, tool-call IDs, tool names, and whether the empty-result fixture was present.

We deliberately avoided storing complete conversation prompts and authentication data.

The first interesting observation was that one captured request exposed approximately 35 built-in tools to the model.

That was substantially different from the successful direct Ollama test, which exposed only list_automations.

However, this alone did not prove the number of tools caused the loop.

We needed a narrower experiment.

6. The successful end-to-end experiment

We configured ZORGAX Diagnostic to use a single custom tool and disabled the unrelated built-in capabilities.

Then we asked:

Controlla quali automazioni sono attive usando list_automations. Se non ce ne sono, dimmelo.

ZORGAX invoked the simulated tool and replied that no automations were active.

More importantly, the proxy captured the continuation:

Request 7
  Model: zorgax:latest
  Tools: [list_automations]
  Messages:
    user

Request 8
  Model: zorgax:latest
  Tools: [list_automations]
  Messages:
    user
    assistant -> list_automations
    tool -> empty result present

The assistant's call identifier and the tool result were preserved, and the empty result reached the next request destined for Ollama.

For this controlled configuration, the full interaction worked.

That is our most important verified finding: Open WebUI can carry a successful empty tool result through to Ollama and obtain a final response from ZORGAX.

7. What we have not proven

It would be tempting to conclude that exposing too many tools caused the original loop.

But that would be premature.

The successful and unsuccessful experiments did not hold every variable constant. Tool availability was different, and other factors — including prompt instructions, function schemas, model parameters, and sampling behavior — might also affect the result.

We therefore have a strong debugging lead, not a definitive explanation.

Our next objective is a controlled A/B comparison using identical model versions, prompts, tool schemas, and generation options while changing one variable at a time.

We also want regression tests that distinguish three important cases:

A tool successfully returns an empty result.
A tool fails with a transport or execution error.
A model generates invalid tool arguments.

An empty result is valid information. An error is not the same thing.

8. Opening the investigation to the community

We have now published the investigation in the public MyZubster GitHub repository.

Technical reproduction guide:

https://github.com/MyZubster-Ecosystem/myzubster/blob/main/docs/zorgax/TOOL-CALLING-INVESTIGATION-2026-10-09.md

Contributor investigation issue:

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

Contribution guidelines:

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

Contributors can reproduce the problem on their own machines, improve the fixtures, compare sanitized HTTP payloads, add regression tests, or propose changes to observability and error handling.

No one needs access to the MyZubster VPS or any production credentials.

We welcome small, focused contributions backed by clear evidence.

9. The bigger lesson

A tool-calling loop is not always something you can fix by adding another instruction such as “do not repeat the call.”

The more reliable approach is to inspect the complete sequence:

User request
    ↓
Assistant tool call
    ↓
Tool execution
    ↓
Tool result
    ↓
Follow-up request to the model
    ↓
Final response or another tool call

Each boundary needs to preserve the right context.

This investigation taught us to separate three questions:

Did the tool execute?

Did its result reach the next model request?

Did the model make the right decision after receiving it?

Only by testing those questions independently can we narrow down the cause of an agent loop without blaming the wrong component.

What's next for ZORGAX?

ZORGAX is intended to become a dependable local DevOps assistant for monitoring, diagnostics, and carefully authorized infrastructure operations.

The successful single-tool experiment is an important milestone, but the original loop investigation remains open.

We are continuing that work in public so others can reproduce the evidence, challenge our assumptions, and help build a more reliable agent.

If you work with Ollama, Open WebUI, Qwen, or local AI agents, you're welcome to join the investigation.

Build in public. Test with evidence. Keep humans in control.

Building ZORGAX: From a Local AI Model to a Server Operations Agent for MyZubster

Daniel Ioni — Fri, 09 Oct 2026 03:15:40 +0000

Building ZORGAX: From a Local AI Model to a Server Operations Agent for MyZubster

Connecting Ollama, Docker, Open WebUI and a custom AI assistant — and learning why reliable tool calling matters.

We're working on a new capability inside the MyZubster ecosystem: ZORGAX, an AI assistant intended to help observe, diagnose and eventually manage technical infrastructure.

Our goal isn't simply to create another chatbot.

We want an AI agent that can understand what's happening across our servers, services and software projects — while operating under explicit permissions and human oversight.

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

1. Our current infrastructure

The pilot environment includes:

Ubuntu 24.04 LTS running on our VPS
Docker and Docker Compose for isolated services
Ollama for local LLM inference
Qwen 2.5 3B as the foundation model
ZORGAX, our custom Ollama model
Open WebUI as the conversational interface
N4K48, our independent AI integration pilot
Qdrant for vector infrastructure

The architecture allows our AI services to communicate internally without exposing the Ollama API directly to the public internet.

2. Connecting Docker applications to Ollama

One of our first challenges involved networking.

Ollama was available at:

http://172.22.0.1:11434

But Open WebUI was configured to use:

http://host.docker.internal:11434

Inside the container, that hostname resolved to 172.17.0.1, where requests timed out.

We corrected the Open WebUI connection to the reachable Ollama endpoint and verified it with an API request.

The result:

HTTP: 200

Models:
- nomic-embed-text:latest
- zorgax:latest
- qwen2.5:3b

CONNECTION: OK

We also introduced a systemd socket proxy to make Ollama accessible through the VPS loopback interface:

127.0.0.1:11434

This preserved the existing Ollama listener used by Docker.

3. Testing actual model inference

Connectivity alone isn't enough.

We tested text generation directly from the Open WebUI container using Ollama's /api/generate endpoint.

The result:

RESPONSE: OLLAMA OK
DONE: True

The Open WebUI container subsequently passed its healthcheck:

running / healthy
HTTP 200

We then connected through an SSH tunnel and successfully interacted with ZORGAX in the browser.

At this stage, we had working infrastructure and a functioning conversational AI.

But the next challenge was more interesting.

4. The tool-calling loop problem

We asked ZORGAX to identify which tools it could actually use.

It invoked a function called:

list_automations

The tool returned:

{
  "automations": [],
  "total": 0
}

Instead of terminating the process and reporting that no active automations were found, ZORGAX repeatedly called the same function.

We observed one sequence reaching 28 calls and another reaching 16 calls.

This exposed an important engineering problem.

An AI agent must not confuse the ability to call a tool with the ability to manage a workflow reliably.

Repeated tool calls are inefficient. More importantly, they could become dangerous if the tools eventually acquire permissions to modify real infrastructure.

5. Isolating the issue

We tested ZORGAX directly through Ollama, without Open WebUI.

First, we confirmed that it could answer normally without tools.

Then we simulated a complete tool interaction:

The user asked how many active automations existed.
ZORGAX requested list_automations.
The test supplied an empty result.
ZORGAX responded that no active automations were available.

There was no repeated tool call in that controlled test.

This suggests that the problem requires further investigation into the Open WebUI tool execution path, model configuration and calling behavior.

It does not yet establish a single root cause.

6. What comes next: ZORGAX as a server operations agent

Our next objective is to move beyond conversation and build a carefully controlled operational assistant.

The first planned capability is:

myzubster_server_status

This will be a read-only tool for collecting selected infrastructure health information.

The long-term roadmap includes:

Phase 1 — Observation

Read-only server metrics, Docker container health, systemd service status and selected application healthchecks.

Phase 2 — Diagnosis

Analyze bounded logs, identify anomalies and suggest possible explanations.

Phase 3 — Project intelligence

Review repository status, test results and project diagnostics without automatically merging or deploying changes.

Phase 4 — Authorized operations

Execute predefined maintenance actions only with explicit approval, restricted permissions and audit logging.

We are intentionally not giving the AI unrestricted root access or direct control over the Docker socket.

7. The main lesson

Building an AI assistant is relatively straightforward.

Building an AI agent that can interact reliably with real systems is a different engineering challenge.

The important questions become:

Can it distinguish facts from assumptions?
Can it interpret tool results correctly?
Can it avoid duplicate or unnecessary operations?
Can it stop when an operation is complete?
Can it operate with least-privilege permissions?
Can every consequential action be audited?

For MyZubster, these are not optional details. They are foundational requirements.

Conclusion

ZORGAX is now functioning as a conversational assistant through Ollama and Open WebUI.

We have validated container connectivity, model inference and a controlled example of tool calling.

The next stage is improving tool execution reliability and introducing a read-only infrastructure monitoring interface.

Our direction is clear:

From a local AI model to a permission-controlled infrastructure assistant — one verified capability at a time.

This is an ongoing development experiment, not a production-ready autonomous system.

More engineering notes will follow as we test each component.

Built as part of the MyZubster ecosystem and the N4K48 independent AI integration pilot.

From Pull Requests to Reproducible Interoperability: Building an Evidence-First Contributor Network

Daniel Ioni — Thu, 08 Oct 2026 18:15:35 +0000

From Pull Requests to Reproducible Interoperability: Building an Evidence-First Contributor Network

Open source collaboration becomes much more useful when contribution history is not just a list of usernames and merged pull requests, but a network of reproducible technical evidence.

At MyZubster, we have been working on a contributor model where public work can be connected to:

exact pull requests;
canonical merge commits;
independent test checkpoints;
external contributor-owned repositories;
bounded interoperability experiments;
explicit limitations on what each test actually proves.

The goal is simple:

PUBLIC CONTRIBUTION
        ↓
EXACT SOURCE / COMMIT
        ↓
REPRODUCIBLE TEST
        ↓
PUBLIC EVIDENCE
        ↓
BOUNDED TESTED STATUS

Not every contributor needs to work inside the same repository.

Some contributors maintain their own projects, forks, research packages or independent runtime environments. Instead of absorbing those projects into MyZubster, we can build small, reproducible bridges between independently owned work.

Current tested contributor checkpoints

Nicola / N4K48

GitHub:

@nicolaususnicola-lgtm
External project: nicolaususnicola-lgtm/myzubster-mvp

Nicola's work became one of our first runtime interoperability experiments.

The bounded test used:

MyZubster VPS
    ↓
authenticated HTTPS broker
    ↓
contributor-controlled N4K48 agent
    ↓
local contributor catalog
    ↓
bounded result returned to MyZubster

The participant-controlled environment successfully returned the expected result to the bridge.

Evidence state:

TESTED

Canonical MyZubster evidence merge:

0c00836a96b36d7c64de098dd26d39ac5ddaf98a

Nicola also authored MyZubster PR #1460, merged at:

ee8c15d4b26824b75345c2eebc62ac034058b84a

This checkpoint demonstrates a bounded runtime bridge.

It does not by itself establish complete decentralization, direct P2P networking, security certification, employment, payment or governance authority.

Shweta-singh24 / MyZubsterGateway

GitHub:

@Shweta-singh24
External project: Shweta-singh24/MyZubsterGateway

Shweta's external MyZubsterGateway work provided a good opportunity to test something different: can we independently reproduce a security/policy checkpoint from an external repository without pretending that the code has been deployed or merged upstream?

We pinned the verifier to this exact source commit:

82461433e0c5bfee9aa369b4a71e9331261cf803

The upstream MyZubsterGateway PR #1385 is:

CLOSED_UNMERGED

Our independent VPS verifier reproduced:

verifier status: TESTED
policy checks:   14/14 PASS
syntax checks:    5/5 PASS
wiring checks:    6/6 true

The wiring checkpoint covered bounded Tari/XMR jurisdictionGate paths.

The MyZubster evidence PR #1575 passed:

CI – Test e Lint
Security Audit
MYZ-164 Seller Free policy
Continuous Evidence Gate

and was squash-merged at:

dc4fb1e3c403f6e554c2402ec9fb4c5dfd93e593

This means we independently reproduced that exact checkpoint.

It does not mean the upstream PR was merged, the system was deployed to production, legal compliance was certified or a security certification was issued.

That distinction matters.

Open Period Care / khongten124

GitHub:

@khongten124
External project: khongten124/myzubster

Open Period Care is an example of a different type of interoperability.

Instead of a runtime security or API bridge, this work connects:

PUBLIC RESEARCH
      ↓
EVIDENCE PACKAGE
      ↓
KNOWLEDGE CARDS
      ↓
STRUCTURED RETRIEVAL
      ↓
CIRCULAR CARE / KNOWLEDGE GRAPH

The contributor's research package focuses on areas including materials, sustainable health technologies, technical documentation and evidence analysis.

Relevant MyZubster contribution anchors:

PR #1451:

fc4a5cd30c854a242e6ed39e757c77f463c5d231

PR #1489:

6d88448821f25a252a79a777101ef904af8bbccb

The contributor-scoped semantic bridge has been recorded as:

TESTED

This checkpoint is about evidence normalization, provenance and retrieval.

It does not establish a medical credential, professional certification, physical recycling proof or production blockchain implementation.

More tested contributions inside MyZubster

Not every tested contributor checkpoint comes from an external repository.

Several contributors have testable work directly inside the canonical MyZubster repository.

Aming9303 — signed payment webhooks

GitHub:

@Aming9303

PR #891 implemented signed lifecycle webhooks.

Canonical merge:

be78e0cf9081c3346aa0c61e022acd297d745619

Independent regression testing covered:

HMAC-SHA256 signing;
stable delivery IDs across retries;
unsigned endpoint rejection;
one-time replay claims;
stale-event rejection.

Result:

5/5 targeted tests passed

Status:

TESTED — signed payment-webhook regression

This does not establish external receiver deployment, settlement, wallet security or broader infrastructure certification.

wasim-builds — fail-closed admin authentication

GitHub:

@wasim-builds

PR #860:

Canonical merge:

9c36d5be450e12345ff9251a40ab4df38839a7fe

The independent checkpoint reproduced:

unconfigured → 503
missing      → 401
wrong        → 401
correct      → 200

Result:

4/4 targeted tests passed

Status:

TESTED — fail-closed admin-auth regression

Again, the claim is deliberately bounded to that regression behavior.

foxxx009 — KPI/evidence framework and automated testing

GitHub:

@foxxx009

PR #894 — KPI/evidence framework:

50f70aab6dc9a909f65b81cb70d932706143afec

PR #259 — historical GitHubMonitor test contribution:

1c78fadd608e8c8acaeaeaf00d448676f82c3f91

The KPI/evidence framework was independently reproduced with synthetic data.

The historical #259 test suite was later re-enabled through maintainer integration PR #1526:

f8cbdee1e50cfbfa6925b4bc1014ca75ed5e90d1

That attribution distinction is intentional:

259 is contributor-authored work.

1526 is a maintainer-authored integration repair that made the historical test suite runnable again.

Good provenance should preserve that difference.

Why external repositories matter

A healthy open-source ecosystem should not require every contributor to surrender project independence.

We would rather support a model like:

CONTRIBUTOR PROJECT A ───┐
                         │
CONTRIBUTOR PROJECT B ───┼── reproducible bridges ── MYZUBSTER
                         │
CONTRIBUTOR PROJECT C ───┘

External projects can remain under their own ownership, architecture and release process.

MyZubster only needs a bounded interface or reproducible artifact when interoperability is useful.

Current examples include:

And the canonical ecosystem repository remains:

MyZubster-Ecosystem/myzubster

Evidence-first does not mean claim-first

One principle has become increasingly important during this work:

A passing test should prove exactly what it tested — and nothing more.

For example:

TESTED
≠ deployed

MERGED
≠ production-ready

security regression PASS
≠ security certification

research evidence
≠ professional credential

blockchain attestation
≠ proof that a physical event happened

contribution
≠ employment

verified contribution
≠ payment

Being precise about these boundaries makes public technical evidence more credible, not less.

Where we want to go next

The long-term direction is a contributor network where independent developers, researchers and maintainers can expose small interoperable capabilities without centralizing everything into one codebase.

A future graph could look like:

Contributor project
      ↓
public commit
      ↓
reproducible capability
      ↓
signed / bounded request
      ↓
another independent node
      ↓
public evidence result

The interesting milestone is not simply "more contributors".

It is:

more independently controlled projects that can prove small things to each other reproducibly.

That creates a much stronger foundation for open-source collaboration, decentralized infrastructure and evidence-driven automation.

Explore the project

Canonical repository:

github.com/MyZubster-Ecosystem/myzubster

External contributor projects:

If you maintain an independent open-source project and want to explore a small, reproducible interoperability checkpoint instead of a vague "integration", that is exactly the kind of experiment we are interested in.

One project. One bounded capability. One reproducible checkpoint. One public evidence trail.

opensource #github #decentralization #security

🧠 Teaching an AI Assistant What It Is Allowed to Know, Claim, and Do

Daniel Ioni — Thu, 08 Oct 2026 16:47:49 +0000

🧠 Teaching an AI Assistant What It Is Allowed to Know, Claim, and Do

I’m working on a new MyZubster milestone around Zorgax.

The interesting problem is not simply:

“How do we give an AI assistant more knowledge?”

The harder problem is:

How do we define what it is actually allowed to do with that knowledge — and how do we prove those capabilities?

That is what PR #1573 is about.

Separating contributor competence from AI capability

One of the design decisions I wanted to make explicit is that these are two different things.

A contributor record answers questions like:

Who produced this work?
Which repository or pull request supports it?
What was documented, recorded or tested?
What is the evidence state?
What are the limitations?

A Zorgax capability answers something else:

Which evidence may Zorgax consume?
Which actions may it perform?
Which claims must it not make?
Which source state is required?
Does the capability need a bounded test before it can be called TESTED?

That distinction matters.

If a contributor has expertise or evidence in a domain, Zorgax should not automatically inherit that expertise as an unrestricted claim.

A machine-readable capability model

The new schema is:

myzubster.zorgax-capability.v1

A capability defines:

inputs
→ allowed actions
→ prohibited claims
→ evidence requirements
→ linked evidence
→ limitations
→ capability state

Initial states are intentionally conservative:

Contributor Profile Assistant
→ DOCUMENTED

Research Evidence Navigator
→ TESTED

Interoperability Checkpoint Assistant
→ DOCUMENTED

Only one of them starts as TESTED.

That is deliberate.

Example: contributor profiles

The Contributor Profile Assistant may use approved public evidence to:

summarize declared professional interests;
prepare a profile draft;
identify provenance;
suggest bounded onboarding steps.

But it must not:

invent qualifications;
infer employment;
infer certification;
infer Passport / LIFE / DAO participation;
publish profile information without the required approval.

So if someone says:

“I am interested in MyZubster usability testing”

Zorgax can preserve and structure that information.

It cannot silently convert it into:

“Certified software tester.”

Example: research evidence

The Research Evidence Navigator is designed around another rule:

evidence state must survive retrieval.

If a research Knowledge Card is:

SUPPORTED

then after Zorgax retrieves or summarizes it, it is still:

SUPPORTED

not:

TESTED

not:

scientifically validated

not:

clinically certified

This capability already has a bounded contributor-scoped checkpoint behind it, which is why its current state can be TESTED.

Capability testing

The model I’m moving toward is:

Capability definition
        ↓
Allowed evidence
        ↓
Fixed / bounded procedure
        ↓
Observed result
        ↓
PASS / FAIL / PARTIAL
        ↓
Evidence state

Documentation alone is not enough.

A capability should become TESTED only when a reproducible bounded checkpoint supports it.

CI enforcement

I also added a validator for the Zorgax capability registry and connected it to the existing Continuous Evidence Gate.

The validator checks things such as:

schema validity;
duplicate capability IDs;
registry ↔ file consistency;
status consistency;
whether a TESTED capability actually links to bounded TESTED checkpoint evidence.

So capability state is not just prose anymore.

It is becoming something CI can reject.

Why this matters

A lot of AI systems are described in vague terms:

“The assistant knows X.”

I think that framing is too loose for contributor-driven systems.

I prefer:

source
→ provenance
→ evidence state
→ allowed capability
→ guardrails
→ bounded test
→ observed result

That makes it easier to answer:

Why is Zorgax allowed to say this?
Which source supports it?
Is the information self-declared, supported, recorded or tested?
What is Zorgax explicitly prohibited from inferring?
Has this specific capability actually been tested?

Current roadmap

The broader MyZubster path is becoming:

Contributor evidence
→ machine-validatable checkpoint
→ competence / provenance registry
→ Zorgax capability registry
→ bounded capability tests
→ Passport / Knowledge Graph / workflows

without collapsing all of those states into one generic “verified” label.

PR #1573 is the first implementation of that capability layer.

Once the checks are green and the PR is merged, I’ll publish the canonical merge commit and the final capability states.

The principle behind the whole thing is simple:

AI capability should be bounded by evidence, not by confidence.

SoftwareEngineering #AIEngineering #AIGovernance #DevOps #JSONSchema #CI #OpenSource #SystemDesign #EvidenceFirst #DeveloperTools #MyZubster