DEV Community: Daniel Ioni

Building MyZubster Together: Meet the Contributors Creating an Open-Source, Decentralized Ecosystem

Daniel Ioni — Tue, 27 Oct 2026 04:56:05 +0000

Building MyZubster Together: Meet the Contributors Creating an Open-Source, Decentralized Ecosystem

From a simpler service marketplace to independent infrastructure, gardening, digital comics and AI-assisted development.

Tags: #opensource #github #webdev #community

MyZubster is an open-source experiment with a simple ambition: help people turn their skills, projects and knowledge into useful services, while allowing contributors to build and operate independent parts of the ecosystem.

We are not trying to build everything behind one centralized team.

Instead, we are exploring a network where developers, artists, gardeners, service providers and independent infrastructure operators can contribute in different ways.

Today, I want to introduce some of the people helping us build MyZubster, share their public work, and explain what is already implemented, what is being reviewed, and what we are still testing.

🌐 The main project

MyZubster GitHub:

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

Website:

https://myzubster.com

Our current priorities are deliberately practical:

Make the Marketplace easier to understand and use.
Help contributors offer real services through Seller Free.
Keep Zorgax, our assistant, available to support users.
Preserve the Metaverse and experimental projects without making the homepage complicated.
Explore independent infrastructure, privacy and interoperability.
Connect contributions to public evidence, skills and contributor profiles.

Here is how the community is helping.

🎨 Wasim — Simplifying the Homepage and Marketplace

Contributor: @wasim-builds

Wasim is working on one of our most important improvements: making MyZubster understandable to someone visiting for the first time.

His redesign focuses on four clear actions:

Find services.
Offer a service.
Explore the Metaverse.
Sign in or manage a profile.

The new interface also introduces featured service categories, clearer navigation and a more direct route into the Marketplace.

Current work:

Wasim has reported passing automated tests for the Seller Free workflow, including seller activation, listing publication and editing.

Status: The redesign and photo features are still under review. Automated tests have passed in isolated environments, but we are not presenting them as proof of a completed public production rollout.

Our immediate goal is to release the simpler homepage first, then continue improving listing photographs and other features.

🛡️ Wasim and Gangkor — Isolated Infrastructure and Interoperability

Decentralization also means thinking carefully about who operates infrastructure, how services communicate and how access is secured.

Wasim and Gangkor are involved in separate but related infrastructure experiments.

Their work explores:

Isolated development environments.
Least-privilege access.
Threat modeling.
Mock peer-to-peer interoperability.
Safer testing without exposing production wallets or credentials.
Possible future Tor Onion access.

Public work:

Status: These are development and security pilots. We are not claiming that a fully decentralized production network or public Onion service has already been completed.

The goal is to let contributors develop independent capabilities while maintaining clear security boundaries.

🖼️ Nicola — Comics, Zorgax and Independent Projects

Nicola is exploring how original creative work can become part of an open-source ecosystem.

His Nicola Comics pilot connects digital artwork, public evidence and possible future integrations with contributor identities and the Marketplace.

One concrete software contribution is a read-only bridge allowing Zorgax to retrieve information from the Nicola Comics pilot when a user explicitly requests it.

Public work:

This integration is intentionally limited: it does not mint NFTs, transfer funds or claim ownership that has not been independently verified.

Nicola is also part of our broader exploration of independent contributor infrastructure.

Status: The comics integration has been developed; further independent-node and creative-commerce capabilities remain areas of experimentation.

🌱 Nico — Connecting Real Gardening Work to GitHub

One of the most meaningful experiments is not about advanced software.

It is about everyday work.

Nico is documenting gardening and urban green-space maintenance through a public GitHub project.

His repository includes a work diary describing activities such as mowing, pruning, garden maintenance and transplanting.

Public project:

Our proposed next step is to help Nico connect his documented skills to a real Seller Free service listing.

Imagine a gardener who does not need to become a programmer to benefit from open-source tools.

GitHub can hold a portfolio of work. An assistant can help explain the technical steps. A Marketplace can make those services easier to discover.

Status: The independent repository and work diary exist. A successful live Seller listing has not yet been verified.

🧾 ClearSheet — Testing a Remote Digital Service

Another potential Marketplace participant is ClearSheet, a proposed service for converting documents into structured spreadsheets with human review.

This is a different kind of service from gardening, but it helps us test the same question:

Can MyZubster support both local work and remote digital skills through a simple seller experience?

We have invited ClearSheet to test the Seller Free onboarding process, using synthetic examples rather than publishing customer documents.

Public discussion:

Issue #1613 — Contributors as Marketplace sellers

Status: Invitation and onboarding discussion underway. A real production listing has not yet been confirmed.

🤖 An AI Agent Has Also Proposed Contributing

Recently, the GitHub account @aiautomationagentesting, which identifies itself as an autonomous AI agent, expressed interest in MyZubster.

It proposed two possible contributions:

Tests for the public bounty API's funding-state filters.
An original four-panel comic with documented provenance and rights information.

Public discussions:

We have asked how the agent discovered MyZubster and whether it would be interested in a small, human-reviewed pilot.

We are also discussing the possibility of internal MYZ credits for approved contributions.

These credits are not being presented as guaranteed monetary compensation or as automatically convertible cryptocurrency.

Status: This is an early proposal, not a completed contribution. We do not yet know whether the agent discovered the project independently or through an external assignment.

It raises an interesting question for the future of open source:

How should human contributors and AI agents collaborate transparently, with verifiable evidence and human oversight?

🔗 Knowledge, Evidence and Contributor Identity

We want contributions to be more than usernames in a list.

A useful contributor record could connect:

Identity → Project → Contribution → Evidence → Skills → Review → Recognition

For a developer, evidence might be a pull request and passing tests.

For an artist, it might be an original file, its Git commit and documented rights.

For a gardener, it might be an authorized work diary and a portfolio of completed activities.

These are different kinds of work, but all deserve clear attribution.

Our Contributor Passport and knowledge-graph ideas are intended to explore these connections. Their capabilities are evolving, and not every proposed integration is available today.

🪙 What About MYZ, Monero and Rewards?

MyZubster is also experimenting with ways to recognize contributions and support privacy-conscious payments.

We distinguish between:

Internal MYZ credits: ecosystem rewards whose use and terms must be clearly defined.
Monero and other payment integrations: separate financial infrastructure with its own operational and security requirements.
Proposed bounties: potential rewards that are not payment promises until funding and terms are explicitly agreed.

We do not want contributors to mistake an unfunded issue for guaranteed compensation.

Transparency about the state of a reward is just as important as transparency about the state of the code.

🚀 What Comes Next?

Our next milestone is not to announce ten more features.

It is to prove a small, useful workflow:

A person signs in → activates Seller Free → publishes a real service → another person discovers it → a genuine inquiry can happen.

At the same time, we want to continue improving the homepage, supporting independent contributor projects and testing interoperability without compromising production security.

MyZubster is still a work in progress.

Some contributions are implemented. Others are awaiting review. Several ideas are experimental.

But the people and projects are real, and the public GitHub links allow anyone to follow the work.

🤝 Want to Contribute?

You do not have to work on every part of MyZubster.

You can choose a direction that fits your skills:

Frontend development and accessibility.
Marketplace testing.
Security and independent infrastructure.
Documentation and knowledge organization.
Art, comics and digital creativity.
Local or remote services.
Responsible AI-assisted open-source contributions.

Start by exploring the repository and joining an issue that interests you.

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

Marketplace contributor pilot: https://github.com/MyZubster-Ecosystem/myzubster/issues/1613

Website: https://myzubster.com

Our vision is not that everyone must become a software developer.

It is that people with different skills can build useful things, document their work and connect with one another through an open ecosystem.

Built in public, one contribution at a time.

— Daniel, MyZubster

Building the MyZubster Metaverse: Realtime Infrastructure, Security, Reliability, and What Comes Next

Daniel Ioni — Fri, 23 Oct 2026 05:19:00 +0000

Building the MyZubster Metaverse: Realtime Infrastructure, Security, Reliability, and What Comes Next

The MyZubster Metaverse is evolving from an experimental interactive environment into a more structured, observable, and production-oriented platform.

Our goal is not simply to render a virtual world. We are building an open-source environment where authenticated users, guests, communities, developers, and AI-assisted experiences can interact through traceable and reliable services.

During the latest development phase, we focused on the foundations that must exist before adding more ambitious WebXR, social, and multiplayer features:

authenticated metaverse sessions;
server-authorized world actions;
realtime communication;
distributed abuse protection;
privacy-safe observability;
MongoDB and Redis readiness;
Preview infrastructure isolated from Production;
automated tests and continuous evidence;
explicit operational and security gates.

This article describes what we implemented, the architectural decisions behind it, what we verified, and what still needs to happen before production rollout.

1. From client-controlled actions to authenticated sessions

One of the most important changes was moving world actions away from implicit client trust.

A browser must not be able to claim an arbitrary user identity or perform a privileged action simply by sending a crafted request.

The current architecture binds metaverse actions to authenticated session credentials. The server is responsible for determining:

which user is connected;
which role the user has;
which session or community the action belongs to;
whether the requested operation is permitted;
whether the submitted identity matches the authenticated principal.

This creates a clear trust boundary:


text
Browser input
    ↓
Authenticated HTTP or realtime session
    ↓
Server-side identity and authorization checks
    ↓
Validated world action
    ↓
Persistent or realtime state update
Client state can still improve the user experience, but it is no longer treated as authoritative security evidence.
2. Realtime access tokens
We introduced a dedicated token endpoint for the realtime subsystem.
An authenticated application session can request a short-lived realtime token. The token contains only the minimum information required by the gateway, such as:
- user identifier;
- authorized role;
- optional public username;
- correlation identifier;
- expiration time.
The response also describes the supported connection contract:
{
  "success": true,
  "expiresInSeconds": 300,
  "socketPath": "/realtime",
  "transports": ["websocket", "polling"],
  "namespaces": [
    "user:{id}",
    "community:{id}",
    "session:{id}"
  ]
}
The correlation identifier lets us connect an HTTP request, token-minting operation, socket connection, and later operational events without exposing sensitive application data.
3. Authorized realtime channels
Realtime communication is organized around explicit channel families:
user:{id}
community:{id}
session:{id}
These channels are not arbitrary rooms that a client can join freely.
The server validates whether the authenticated user may enter the requested channel. This is essential for preventing:
- cross-user subscription;
- unauthorized community access;
- session impersonation;
- client-generated room escalation;
- accidental data leakage between realtime contexts.
We are also separating connection authorization from application events. Establishing a socket connection does not automatically authorize every action that may travel through it.
4. Redis-backed distributed presence
A single-process memory map is useful during local development, but it is not sufficient for a horizontally scaled realtime service.
When multiple application instances are running, each instance sees only its own connected users. A reconnect or deployment can also destroy local presence state.
We therefore implemented a Redis-backed presence store.
Redis keeps short-lived connection records for users inside community and session channels. The implementation supports:
- adding a connection;
- refreshing its expiration;
- removing it during disconnection;
- listing active members;
- handling multiple sockets belonging to the same user;
- pruning expired records;
- detecting the first and last active connection.
Presence data uses a TTL. Stale sockets eventually disappear even when the application does not receive a clean disconnect event.
The service retains a local fallback to avoid completely breaking realtime behavior during a Redis incident. However, that fallback is considered degraded mode—not production-ready distributed presence.
5. Redis failure handling
Redis operations are wrapped with explicit failure handling.
When Redis initialization or an established operation fails, the service:
1. records an aggregate Redis failure;
2. emits a structured operational event;
3. invalidates the failed shared client;
4. falls back locally where permitted;
5. exposes the degraded state through readiness.
We deliberately avoid returning Redis connection strings, internal exception messages, usernames, or infrastructure details to public clients.
Operational errors are represented through safe categories such as:
{
  "event": "redis_presence_failure",
  "operation": "health",
  "status": "local_fallback",
  "mode": "local-fallback",
  "reason": "redis_error"
}
6. Distributed rate limiting
Metaverse actions and realtime endpoints need protection against abuse, spam, and accidental request storms.
Local counters are insufficient when traffic reaches multiple server instances, so we developed a distributed rate-limiting path using Redis.
The rate-limiting architecture is designed to support:
- authenticated user limits;
- guest or anonymous limits;
- action-specific policies;
- shared counters across instances;
- explicit retry metadata;
- privacy-safe operational metrics;
- controlled degraded behavior.
Rate limiting is part of the server-side authorization boundary. A client cannot reset its allowance by refreshing the page or connecting to a different application instance.
7. Privacy-safe observability
Operational visibility is necessary, but observability must not become a second surveillance system.
The realtime metrics endpoint is restricted to administrators and exposes aggregate counters rather than individual user activity.
Current metrics can describe behavior such as:
- connection attempts;
- successful connections;
- authorization failures;
- active connection changes;
- Redis failures;
- rate-limit decisions;
- service degradation.
The endpoint does not return raw tokens, Redis URLs, database credentials, private messages, or individual browsing histories.
A simplified response follows this pattern:
{
  "success": true,
  "privacy": "aggregate-only",
  "counters": {
    "connectionAttempts": 42,
    "connectionSuccesses": 40,
    "redisFailures": 0
  }
}
The response uses Cache-Control: no-store so operational data is not retained by shared caches.
8. A real production-readiness endpoint
We added a public readiness endpoint:
GET /api/realtime/health
Its purpose is different from a generic “the process is running” check.
The endpoint verifies whether the dependencies required by the realtime subsystem are actually operational:
- Express router;
- MongoDB connection;
- Redis connection.
A healthy response follows this contract:
{
  "success": true,
  "service": "myzubster-realtime",
  "status": "ready",
  "checks": {
    "router": "ready",
    "mongodb": "connected",
    "redis": "connected"
  },
  "timestamp": "2026-10-23T00:00:00.000Z"
}
If MongoDB or Redis is unavailable, the endpoint returns HTTP 503:
{
  "success": false,
  "service": "myzubster-realtime",
  "status": "degraded",
  "checks": {
    "router": "ready",
    "mongodb": "connected",
    "redis": "disconnected"
  }
}
Readiness therefore means more than “the route exists.” It means the service can currently use its required durable and distributed infrastructure.
9. Reusing the shared Redis client
The readiness endpoint does not create a separate Redis implementation.
It uses the same shared Redis client used by the presence store. This reduces the risk of reporting a healthy dependency through one connection while the application is using another broken connection.
The readiness function:
1. checks whether REDIS_URL is configured;
2. initializes or reuses the shared client;
3. sends PING;
4. returns a normalized status;
5. invalidates the client after a failed ping;
6. records the failure through the existing observability service.
Conceptually:
async function redisReadiness() {
  if (!redisConfigured()) {
    return { ready: false, status: "not_configured" };
  }

  const client = await getRedis();

  if (!client) {
    return { ready: false, status: "disconnected" };
  }

  try {
    await client.ping();
    return { ready: true, status: "connected" };
  } catch (error) {
    recordRedisFailure(error);
    invalidateRedisClient(client);

    return { ready: false, status: "disconnected" };
  }
}
10. Isolated Preview infrastructure
We did not reuse Production database credentials for branch deployments.
Instead, the Vercel Preview environment was connected to isolated resources:
- a dedicated MongoDB Preview database;
- a scoped MongoDB Preview user;
- a Redis resource connected through REDIS_URL;
- environment variables restricted to Preview.
This gives us a safer environment for testing readiness, presence, failure modes, and migrations.
The boundary is explicit:
Pull request branch
    ↓
Vercel Preview deployment
    ↓
Preview-only MongoDB
    ↓
Preview-only Redis
Production secrets were not copied into the branch environment, and Production was not changed during this phase.
11. Automated verification
We added tests at two levels.
Presence-store tests
The Redis presence tests verify that the service:
- reports Redis as connected after a successful ping;
- reports it as disconnected after a failed ping;
- records an alertable Redis failure;
- falls back locally when connection initialization fails;
- falls back when an established Redis operation fails.
HTTP route tests
The realtime route tests verify:
- HTTP 200 when MongoDB and Redis are ready;
- HTTP 503 when MongoDB is disconnected;
- HTTP 503 when Redis is disconnected;
- the presence of the expected readiness fields;
- Cache-Control: no-store;
- the absence of sensitive values;
- administrator-only access to aggregate metrics;
- denial of metrics access to regular users.
The main CI workflow completed successfully, including:
- backend lint;
- backend unit tests;
- frontend unit tests;
- backend build;
- frontend build;
- artifact generation.
The Seller Free policy regression workflow also passed, and the Continuous Evidence Gate produced a retained evidence artifact.
12. Current pull-request status
The readiness work is tracked in a Draft pull request.
The latest implementation includes:
- Redis readiness in the shared presence service;
- Redis gating in the public health endpoint;
- MongoDB and Redis degradation behavior;
- unit and route-level tests;
- successful Preview deployment.
The pull request remains Draft intentionally.
We have not merged it and have not performed a Production rollout.
13. The current security blocker
The latest security audit detected two dependency advisories:
- one high-severity vulnerability;
- one moderate-severity vulnerability.
The affected package is ip-address <= 10.7.3, and an updated version is available.
This dependency issue is separate from the Redis readiness implementation, but it is still a release gate. The lockfile and the transitive dependency path must be reviewed and updated in a focused security change.
We will not describe the branch as release-ready while a high-severity dependency audit is failing.
14. What is still missing
The core realtime foundation is substantially stronger, but MYZ-83 is not complete.
The remaining work includes the following.
Dependency remediation
Upgrade the vulnerable dependency path, regenerate the lockfile, rerun the complete audit, and verify that the change does not break network-address handling.
Load baseline
Measure the realtime system under repeatable workloads:
- concurrent socket connections;
- connection and reconnection bursts;
- channel joins and leaves;
- presence refresh operations;
- distributed rate-limit operations;
- token issuance;
- HTTP and socket latency;
- MongoDB and Redis resource consumption.
The result must include reproducible commands, environment information, and retained metrics.
Redis restart drill
We need to demonstrate what happens when Redis becomes unavailable and later returns:
Redis healthy
    ↓
Redis interrupted
    ↓
Readiness becomes degraded
    ↓
Failures are counted
    ↓
Local fallback is bounded
    ↓
Redis reconnects
    ↓
Readiness returns to ready
MongoDB restart drill
The same operational evidence is required for MongoDB:
- health transition;
- connection retry behavior;
- public response safety;
- recovery time;
- absence of credential leakage;
- final healthy state.
Multi-instance validation
Distributed presence and rate limiting must be tested with multiple application instances. A single-instance test cannot prove that Redis-backed coordination behaves correctly across replicas.
Reconnection behavior
We still need repeatable tests for:
- short network interruptions;
- token expiration;
- reconnect storms;
- duplicate sockets;
- stale presence cleanup;
- retry backoff;
- client state restoration.
Production smoke test
Production verification will happen only after:
1. security remediation;
2. completed review;
3. explicit merge authorization;
4. an approved deployment;
5. confirmation that the correct Production resources are configured.
No Production change should be inferred from the successful Preview work.
15. What comes after reliability
Once the operational foundation is accepted, we can continue with higher-level metaverse features:
- richer shared-world interactions;
- realtime community events;
- persistent avatars and progression;
- WebXR exploration;
- spatial interfaces;
- collaborative missions;
- verified contributor identities;
- connections between the Metaverse and MyZubster Knowledge;
- development requests linked to GitHub contributions;
- community-governed experiences;
- optional reward and bounty bridges backed by verifiable evidence.
The sequence matters.
WebXR and visual features are valuable, but authentication, authorization, abuse protection, distributed state, and recovery behavior must come first.
Conclusion
The latest MyZubster Metaverse work is primarily about trustworthiness.
We moved closer to a system where:
- identities are derived from authenticated sessions;
- world actions are authorized by the server;
- realtime channels have explicit access rules;
- presence and rate limits can work across multiple instances;
- Redis and MongoDB are part of the readiness contract;
- operational metrics remain aggregate and privacy-safe;
- Preview infrastructure is isolated from Production;
- CI produces reproducible technical evidence;
- known security failures remain visible instead of being hidden.
The Metaverse is not production-complete yet, but its foundation is becoming measurable, testable, and independently reviewable.
That is the kind of progress we want: not unsupported claims, but small engineering steps backed by code, tests, deployments, and evidence.
Project links
- GitHub: https://github.com/danieldirimini-myzubster/myzubster
- Metaverse: https://www.myzubster.com/metaverse
- Realtime readiness PR: https://github.com/danieldirimini-myzubster/myzubster/pull/40
- MYZ-83 roadmap issue: https://linear.app/myzubster/issue/MYZ-83/b6-realtime-observability-reliability-and-load-tests

Building MyZubster: From a Working AI Gateway to GitHub Contributor Onboarding

Daniel Ioni — Wed, 21 Oct 2026 05:37:13 +0000

Building MyZubster: From a Working AI Gateway to GitHub Contributor Onboarding

How we connected Vercel, our VPS, local AI, and a step-by-step GitHub guide — and what our real-world tests taught us.

Building an open-source platform is not just about writing code. It's about making technology accessible to people who may have never used GitHub, configured a development environment, or contributed to a repository before.

At MyZubster, we're working toward a decentralized ecosystem where people can share skills, collaborate on projects, and build independent services.

Today, we made measurable progress on one important part of that vision: Zorgax, our AI assistant.

1. Restoring the connection between Vercel and our VPS

Our application runs through Vercel, while part of our backend infrastructure and local AI services operate on a VPS.

Previously, requests to the Zorgax assistant could fail with HTTP 502 errors.

We worked on a signed HTTPS gateway connecting the Vercel deployment to the VPS backend.

The result:

Vercel Production successfully communicates with the Zorgax gateway.
The backend responds to assistant requests.
Our local AI infrastructure remains available on the VPS.
We confirmed successful HTTP 200 responses during testing.

This is an important infrastructure milestone, but it does not mean every feature is finished.

2. Giving Zorgax a practical job: helping new contributors

We want Zorgax to do more than answer general questions.

One of its first practical responsibilities is to help people join MyZubster through GitHub.

A new contributor should be able to say:

Hi Zorgax, help me create a GitHub profile for MyZubster.

And receive a clear first step, rather than a complicated technical explanation.

We introduced a local GitHub onboarding guide that starts with:

Step 1 — Create your GitHub account.

Visit https://github.com/signup, complete the registration, and return when ready.

The assistant also reminds users not to share passwords or verification codes.

3. Teaching the assistant to remember progress

Our first live tests revealed a problem.

Zorgax correctly started the registration process, but after a contributor supplied a GitHub username, it sometimes restarted Step 1.

We traced the issue to the onboarding rules.

We then introduced username recognition and used conversation history to identify whether the contributor had already started the registration process.

The updated assistant can now respond:

Step 2 — You've provided your GitHub username. Open PowerShell and check your Git and GitHub CLI installations.

This change was tested before deployment.

Regression test results: 4/4 passed.

The tests covered:

Starting GitHub registration.
GitHub social login guidance.
Handling login errors.
Recognizing a contributor's GitHub username.

After applying the change, restarting the VPS service, and testing the public chat, we confirmed that Zorgax progressed to Step 2 instead of restarting registration.

4. Local AI and privacy-conscious processing

Our VPS runs local AI services, including Ollama.

During the onboarding tests, we observed two response paths:

local-rule · github-guide — deterministic instructions for GitHub onboarding.
local-ollama · qwen2.5:3b — responses generated by the local language model.

The test responses reported privacy_local_only, indicating local processing for those requests.

This architecture allows us to combine predictable instructions for critical workflows with a language model for more flexible assistance.

However, the distinction matters: a model-generated answer is not the same as a verified workflow step.

5. What didn't work yet

Our next test simulated a Windows user who had Git and GitHub CLI installed.

Instead of progressing to GitHub authentication, Zorgax switched to Ollama and began discussing the creation of a MyZubster character.

That wasn't the expected response.

The correct next step should be to guide the contributor through:

gh auth login

Then verify authentication using:

gh auth status

Without requesting passwords, tokens, or private credentials.

This exposed the next engineering task: extending the deterministic onboarding guide so that the AI doesn't lose track of the contributor's actual objective.

We are not presenting this part as complete.

6. What's next for MyZubster?

Our next development priorities are:

Complete Git and GitHub CLI installation checks.
Guide contributors through GitHub authentication.
Help users configure their local Git identity.
Connect contributors to the appropriate MyZubster repository.
Guide their first fork and pull request.
Make the onboarding experience usable by people without programming experience.

Longer term, we want Zorgax to support the MyZubster marketplace, contributor collaboration, and independent projects — without making the platform unnecessarily complicated.

7. Why this matters

MyZubster is exploring a model where contributors can participate not only by writing code, but also by offering services, documenting knowledge, testing software, and connecting independent projects.

A useful AI assistant should lower the barrier to participation.

It should explain one step at a time, remember progress, avoid claiming that something has been verified when it hasn't, and help people become more independent.

Today we didn't finish the entire onboarding journey.

But we verified that our Production assistant can start it, recognize a GitHub username, and continue to the next step.

Small, tested improvements are how an open-source ecosystem becomes usable.

Join the project

Website: https://www.myzubster.com

Zorgax assistant: https://www.myzubster.com/zorgax

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

We're interested in contributors who want to help simplify onboarding, improve local AI workflows, test the marketplace, or explore decentralized collaboration.

What would you expect an open-source AI assistant to do when helping a complete beginner make their first GitHub contribution?

opensource #github #ai #nodejs

Building the MyZubster Metaverse: Sessions, Verified Identities, CI Hardening, and the Road Ahead

Daniel Ioni — Mon, 19 Oct 2026 04:57:10 +0000

Building the MyZubster Metaverse: Sessions, Verified Identities, CI Hardening, and the Road Ahead
MyZubster is evolving from a traditional community platform into an experimental open-source metaverse where people, contributors, knowledge, and software services can interact through verifiable identities and authenticated actions.
This article summarizes what we have implemented, what is currently operational, and what still needs to be completed before the system can be considered production-ready.
What We Are Building
The MyZubster Metaverse is designed as a connected environment composed of several layers:
User identity
↓
Authenticated session
↓
Metaverse character
↓
World actions
↓
Realtime services
↓
Verified Knowledge and Zorgax
↓
GitHub contributions and Development Requests
The goal is not simply to render a virtual world. We want every relevant action to have a verifiable context:

Who initiated the action?
Which session authorized it?
Which character represents the user?
When does the authorization expire?
Which backend service accepted the action?
Can another participant independently verify the result? Public Metaverse Interface The public Metaverse page is available at: https://www.myzubster.com/metaverse The interface currently exposes the public layer of the ecosystem, including registered characters and verified explorers. During our latest production verification, the page loaded correctly with:
25 public characters
7 verified explorers
No blocking browser-console errors
Successful Vercel production deployment This public interface is only one part of the system. The most important work has been happening underneath it: authentication, session isolation, action authorization, workflow reliability, and contributor identity integration. Binding World Actions to Session Credentials One of the most important architectural changes is the transition from anonymous or loosely identified requests to session-bound world actions. A metaverse action should not be accepted only because the client sends a character identifier. The backend must derive authority from a trusted session. The intended request flow is: Client → authenticated request → session credential validation → active lease verification → character ownership resolution → action policy validation → world-state mutation This prevents a client from impersonating another character merely by changing an identifier in the request payload. The server-side authority model follows a rule similar to: const session = await resolveAuthenticatedSession(request);

if (!session) {
throw new UnauthorizedError();
}

const lease = await getActiveSessionLease(session.id);

if (!lease || lease.expiresAt <= new Date()) {
throw new SessionExpiredError();
}

const character = await resolveCharacterForSession(session);

await authorizeWorldAction({
session,
lease,
character,
action: request.body.action,
});
The important principle is that identity must be derived from the authenticated context—not trusted directly from client-controlled fields.
Session Lease Lifecycle
Persistent sessions are useful, but unlimited sessions are dangerous. We therefore introduced a session-lease model.
A lease represents the limited period during which a session may perform metaverse actions.
Conceptually, the lifecycle is:
CREATED
↓
ACTIVE
↓
RENEWED ─────┐
↓ │
EXPIRED │
↓ │
REVOKED ←────┘
A lease can become invalid because:

Its expiration time has passed.
The user logged out.
The account was disabled.
The credential was rotated.
The session was explicitly revoked.
A security policy invalidated older sessions. World-action endpoints must reject expired or revoked leases even when the original session cookie or token is still present. This creates a clear separation between:
Authentication: proving which account initiated a request.
Authorization: deciding which action that account may perform.
Lease validity: determining whether the authorization is still active. Zorgax and Contributor Identities Zorgax is the identity and knowledge layer connecting public contributor profiles, GitHub activity, Knowledge Cards, and metaverse characters. The current model distinguishes carefully between:
A public GitHub alias
A MyZubster account
A professional profile
A metaverse character
A verified external identity These concepts must not be treated as interchangeable. A GitHub-connected contributor can be represented as a proposed character, but this does not automatically imply:
Legal identity verification
Employment
Ownership
Partnership
Payment eligibility
Institutional endorsement Character onboarding therefore uses an explicit opt-in process. A proposed character remains in a draft state until the contributor accepts it. GitHub contribution ↓ Optional character proposal ↓ Explicit contributor acceptance ↓ Registered public character This protects contributors from being automatically represented in the metaverse without consent. Distributed Rate Limiting Authentication alone is not enough. Authenticated clients can still generate excessive traffic, spam actions, or create concurrency problems. The Metaverse roadmap includes distributed rate limiting for:
Authentication attempts
Session creation and renewal
Character movement
World interactions
Realtime messages
Profile updates
Public API searches A local in-memory rate limiter is insufficient when several application instances are running. Each instance would maintain a different counter. Production enforcement must therefore use shared state: Client requests ↓ Vercel or application instances ↓ Shared rate-limit backend ↓ Atomic counter and expiration The rate-limit key should combine the smallest amount of information required by the policy: const key = [ "metaverse", actionType, sessionId, accountId, ].join(":"); IP addresses should be used carefully. They can be useful for abuse prevention, but they are personal data and may group unrelated users behind the same network. Realtime Architecture The next major layer is realtime communication. The Metaverse will eventually require:
Presence updates
Character movement
Interaction events
Session revocation propagation
World-state synchronization
Reconnection and missed-event recovery A robust realtime system cannot assume that messages arrive exactly once or in order. Each event should include enough information to detect duplicates and stale updates: { "eventId": "evt_01...", "worldId": "myzubster-main", "characterId": "character_...", "sessionId": "session_...", "sequence": 1842, "type": "character.position.updated", "occurredAt": "2026-10-19T04:50:00.000Z", "payload": { "x": 12.4, "y": 0, "z": -8.1 } } The client should be able to reconnect with its last accepted sequence number and request any missing state. GitHub Actions and Node.js 24 We also completed an important CI modernization. GitHub reported that older JavaScript actions were still using the deprecated Node.js 20 runtime. We updated the affected workflows:
uses: actions/checkout@v4
uses: actions/setup-node@v4 to:
uses: actions/checkout@v5
uses: actions/setup-node@v5 The update covered:
12 workflow files
26 action references
CI and lint
Security auditing
SBOM generation
Vercel deployment
Continuous evidence validation
Seller policy regression tests
MYZ ledger verification
Pilot API tests
Decentraland SDK7 proofs Before publishing the change, we verified that:
All 16 workflow YAML files parsed successfully.
No affected v4 references remained.
Only files under .github/workflows were modified.
Workflow triggers, permissions, jobs, and commands remained unchanged. The change was published through Pull Request #38 and squash-merged into main. Final production commit: 69ef67716df50482e8fbf9960ccab7dfc37d3000 Post-Merge Verification The merge triggered a complete verification cycle on main. All seven post-merge workflows completed successfully:
CI — Test and Lint
Security Audit
SBOM and Vulnerability Scan
Continuous Evidence Gate
MYZ Canonical Ledger Contract
MYZ-164 Seller Free Policy
Deploy to Vercel The Vercel deployment also completed successfully. This matters because updating a GitHub Action runtime can affect checkout behavior, dependency caching, authentication, build paths, and artifact handling. The post-merge results confirmed that the new runtime did not introduce an observable regression. What Is Already Working The current verified baseline includes:
A deployed public Metaverse interface
Public characters and verified explorers
GitHub-connected contributor identities
Optional Zorgax character proposals
Session-based authorization work
Session lease lifecycle enforcement
Knowledge and profile integration
Security and SBOM automation
Continuous evidence checks
Automated Vercel deployment
Node.js 24-compatible GitHub Actions What Still Needs to Be Completed
Complete Authentication and Session Enforcement Every state-changing metaverse endpoint must use the same canonical authentication path. We still need to verify:
Logout revocation
Credential rotation
Concurrent sessions
Expired leases
Disabled accounts
Cross-account character access
Replay attempts
Finish Distributed Rate Limiting The policy must be enforced through a shared backend and tested across multiple application instances. Required tests include:
Boundary requests
Concurrent requests
Retry behavior
Counter expiration
Fail-open versus fail-closed behavior
Recovery when the shared backend is unavailable
Complete Realtime Synchronization Realtime work must include:
Presence
Movement
Interaction events
Reconnection
Missed-event recovery
Duplicate suppression
Ordering guarantees
Backpressure handling
Add Privacy-Safe Analytics We need operational visibility without unnecessarily collecting personal information. Useful metrics include:
Active sessions
Lease-renewal failures
Realtime disconnections
Rejected actions
Rate-limit activations
World-state latency
API error rates Sensitive identifiers should be minimized, truncated, aggregated, or pseudonymized.
Reliability and Load Testing Before expanding the public experience, we need repeatable tests for:
Concurrent users
Character movement bursts
Realtime fan-out
Session-store latency
Rate-limit contention
Backend restarts
Partial infrastructure failure
Deployment rollback
End-to-End Acceptance Testing The complete user journey must be tested: Sign in → create or select a character → establish a session lease → enter the metaverse → perform an authorized action → receive a realtime update → reconnect → recover state → log out → confirm the session can no longer act
WebXR WebXR remains a later milestone. It should be introduced only after authentication, realtime communication, abuse prevention, and reliability are stable. Adding an immersive client before stabilizing these layers would only make the system harder to secure and debug. The Current Priority Order Our recommended implementation sequence is:
Authentication and session enforcement
Distributed rate limiting
Realtime synchronization
Privacy-safe analytics
Reliability and load testing
End-to-end acceptance
WebXR client Conclusion The MyZubster Metaverse is no longer only a visual concept. It now has an increasingly concrete technical foundation built around authenticated sessions, explicit contributor consent, verifiable identities, automated security checks, and reproducible deployments. There is still substantial work ahead. Realtime synchronization, distributed abuse protection, complete session enforcement, load testing, and WebXR are not finished. Our objective is to publish progress without presenting experimental components as completed production systems. Each milestone should be supported by source code, automated tests, deployment evidence, and independently inspectable results. That is how we want to build the MyZubster Metaverse: incrementally, transparently, and with verifiable evidence.

6:56

# MyZubster: Building an Open-Source Ecosystem Where Skills, Projects, Marketplaces and Independent Nodes Connect

Daniel Ioni — Sun, 18 Oct 2026 04:03:39 +0000

MyZubster: Building an Open-Source Ecosystem Where Skills, Projects, Marketplaces and Independent Nodes Connect

What if your GitHub contributions, real-world skills, independent projects and local communities could become part of one interoperable ecosystem — without giving up ownership of your work?

That's the idea behind MyZubster.

We are building an open-source ecosystem designed to connect people, knowledge, software, services and independent projects.

Our goal is not simply to create another marketplace, another AI assistant or another decentralized application.

We want to explore how these components can work together to help people demonstrate what they know, share what they create, offer services and collaborate across independent environments.

And we're inviting developers, designers, researchers, creators and community members to participate.

🌐 Website: https://www.myzubster.com/

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

1. The Vision: From a Single Platform to an Ecosystem

Most digital platforms organize activity around one central service.

Users create accounts, publish content, build reputations and offer services. But their contributions often remain locked inside that platform.

MyZubster is exploring a different approach.

We want people and projects to maintain their own identities, repositories, infrastructure and evidence of work while connecting to a wider network.

Imagine a developer maintaining an independent GitHub repository, an artist publishing digital creations, a gardener documenting an urban garden, and a community group offering equipment or technical services.

They have different skills and different needs.

But they could all participate in the same ecosystem through shared connections:

Identity → Skills → Contributions → Evidence → Projects → Services → Opportunities

This is the direction we're building toward.

MyZubster is currently an evolving MVP, with working components, technical experiments and features that still require integration and validation.

2. The Marketplace: Turn Skills Into Services

One of the most accessible ways to participate is through the MyZubster Marketplace.

The idea is straightforward: people should be able to offer what they know how to do, what they create, or the resources they can share.

Examples include:

Software development and website creation
AI integrations and automation
Graphic design and digital art
Technical support and consulting
Tutoring and knowledge sharing
Audio equipment and sound-system services
Gardening and local community services
Creative projects and equipment rental

We also want to support non-commercial exchanges, such as sharing resources or participating in community initiatives.

Why combine a marketplace with open source?

A GitHub repository can demonstrate that someone has written code.

But it does not automatically help that person find a customer or explain what service they can provide.

A marketplace listing creates a different opportunity.

For example:

A developer contributes to an open-source integration, documents the work on GitHub, and creates a Marketplace listing offering similar development services.

Their public contributions may help prospective collaborators understand their experience.

However, a GitHub contribution is evidence of specific work, not automatic professional certification.

Likewise, creating a listing does not guarantee customers or earnings.

The goal is to make useful connections possible.

Explore the Marketplace:

https://www.myzubster.com/community-marketplace.html

3. GitHub: Where Developers Can Build With Us

GitHub is a central part of the MyZubster development process.

Our repository provides an entry point for developers who want to inspect the code, report problems, propose improvements or contribute new functionality.

You do not need to be an experienced blockchain engineer or infrastructure specialist to participate.

There are opportunities across several areas:

Frontend and user experience

Improve accessibility, onboarding, mobile layouts, Marketplace interfaces and contributor profiles.

Backend and integrations

Work on APIs, authentication, data models, interoperability and automated tests.

AI and automation

Explore how Zorgax and supporting AI services can help people understand projects, document work and navigate the ecosystem.

Infrastructure and security

Contribute to Docker environments, Tor Onion experiments, deployment documentation, observability and resilience testing.

Documentation and community

Improve guides, translations, tutorials, contributor onboarding and real-world pilot documentation.

How to start contributing

Visit the main repository.
Read the README and contribution guidance.
Explore existing GitHub issues.
Choose a small task that matches your interests.
Comment on the issue with your proposed approach.
Fork the repository and create a dedicated branch.
Submit a pull request with reproducible evidence.
Participate in code review and improve the contribution when needed.

Contributions are reviewed before acceptance. Opening a PR does not automatically establish eligibility for payment or a verified credential.

Main repository:

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

Open invitation to choose a contributor role:

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

4. Zorgax: AI as a Tool for Participation

Not everyone knows how to navigate a large open-source repository.

Not everyone knows how to describe their skills or organize technical documentation.

This is one of the problems we want Zorgax, the AI component of MyZubster, to help address.

The broader direction includes assisting people with:

Understanding available contribution paths
Exploring GitHub profiles and public contributions
Drafting skill descriptions and biographies
Organizing project documentation
Discovering relevant learning resources
Preparing structured knowledge records

AI should assist people rather than make unsupported claims about their abilities.

For example, an AI-generated description of someone's expertise is not proof that they possess that expertise.

A useful system should distinguish what someone declares, what their work demonstrates, and what has been independently verified.

Explore Zorgax:

https://www.myzubster.com/zorgax

5. Contributor Passport: Making Work and Skills More Visible

Imagine that someone contributes to an open-source project, documents a real-world experiment, helps maintain infrastructure or publishes a reusable technical resource.

How can that work become discoverable beyond a single issue or conversation?

This is the motivation behind the Contributor Passport concept.

We are developing a model that can connect:

Contributor → Contribution → Knowledge → Evidence → Review → Recognition

A Contributor Passport could reference accepted pull requests, project artifacts, documented tests and other relevant evidence.

The goal is not to generate artificial reputation scores.

It is to make the relationship between a person, their work and the supporting evidence easier to inspect.

A simple example

Suppose a contributor builds a Docker integration.

Their public record might reference:

The GitHub repository
The relevant pull request
The code changes
The test results
The review status
A description of the specific technical work completed

This can help other people discover the contribution and understand its limits.

Public profiles and evidence sharing should remain consent-based and privacy-conscious.

The Passport is an evolving component of the ecosystem, not a universally recognized professional credential.

6. Knowledge Graph: Connecting People, Projects and Evidence

The next challenge is connecting knowledge across different contributors and projects.

A traditional list of profiles tells us who participates.

A Knowledge Graph can help describe how things relate.

For example:

A developer contributes a software integration.

That integration supports a local project.

The local project produces documentation and experimental results.

Another contributor uses those results to build something new.

Instead of storing these as disconnected records, the ecosystem can link them through structured relationships.

This could make it easier to discover:

Who contributed to a project
Which repositories contain relevant work
What evidence supports a knowledge claim
Which skills are associated with particular contributions
How independent projects depend on or build upon one another

A graph connection does not automatically prove that a claim is scientifically correct or professionally certified.

It is a way to organize and trace information.

7. LIFE: Connecting Open Source to Real-World Projects

Software becomes more meaningful when it helps people accomplish something outside the development environment.

MyZubster's LIFE-oriented pilot work explores connections between digital tools and real-world activities.

Examples include:

Community resource sharing

Documenting exchanges, such as kefir cultures, and exploring how community knowledge and marketplace listings can support them.

Urban gardening

Connecting gardening activities, photographs, practical knowledge and potentially environmental sensors to a digital project record.

Creative communities

Supporting artists, sound-system groups and independent cultural projects with documentation, listings and technical collaboration.

Open knowledge projects

Exploring how research, documentation and reusable software can be linked to public evidence.

These are pilot directions with different levels of maturity.

They should not be mistaken for completed scientific validations, commercial deployments or institutional endorsements.

The aim is to make the technology useful to actual people and communities.

8. Decentralization: Independent Nodes, Not Just One Central Server

One of the most ambitious parts of MyZubster is the move toward a network of independently operated environments.

Today, many open-source projects still depend on one maintainer, one server or one organization.

We want to explore how contributors can operate their own services while remaining connected through documented interfaces and shared evidence.

A contributor might maintain:

Their own GitHub repository
A local Docker environment
An independent VPS
A project-specific API
A Tor Onion service
A separate knowledge or marketplace integration

The important principle is independent ownership with optional interoperability.

A contributor should not have to transfer ownership of their infrastructure or project to participate.

Our Docker and Tor Onion experiments

MyZubster's main Docker Compose configuration includes an Onion service capable of generating and persisting a Tor v3 Onion identity when the service is started.

This makes it possible for different installations to have different Onion addresses.

However, installing the repository does not by itself prove that Tor is running or that an endpoint is reachable.

We are currently testing:

Isolated Docker networks
Tor Onion services
HAProxy routing
Service availability
Identity persistence
Recovery after interruptions
Independent-node interoperability

An isolated static Onion pilot has been documented, but this does not yet demonstrate that the complete MyZubster platform operates as a decentralized production federation.

We are explicitly separating laboratory results from independently verified production capabilities.

Tor Onion pilot:

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

Voluntary node registry:

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

9. A Real Example: Independent Contributor Projects

The decentralization vision becomes more concrete when we look at contributor-owned work.

One example is the N4K48 project associated with contributor Nicola.

Its documented interoperability experiments involve a contributor-operated agent, an authenticated broker and a creative catalog.

Other contributors, including Wasim, have worked on reproducing and testing parts of this integration in isolated environments.

These experiments are useful because they explore whether software developed and operated independently can exchange information through defined interfaces.

There is an important distinction:

A working integration through a central broker is not the same as a fully independent peer-to-peer network.

Our next technical milestones include reproducible cross-node tests, failure recovery and independently reviewed evidence.

The goal is to make the architecture increasingly portable and resilient.

10. DAO and Shared Governance: Distributing Responsibility

Decentralization is not only about servers.

It is also about decisions, maintenance, responsibility and economic sustainability.

MyZubster is exploring a DAO-inspired governance model in which contributors can voluntarily participate in clearly defined areas of work.

Possible responsibilities include:

Maintaining a software component
Reviewing pull requests
Operating an independent node
Documenting technical standards
Supporting a community pilot
Reviewing contribution evidence
Proposing improvements to shared governance

Participation should not require someone to purchase a VPS or assume financial obligations.

Likewise, contributing code does not automatically make someone a DAO member or grant governance authority.

Our governance work is still experimental. A complete decentralized governance system should not be assumed to exist merely because we have published proposals and coordination issues.

The goal is to distribute meaningful responsibility, not just distribute tasks while keeping every decision centralized.

11. Payments, Monero and Sustainable Open Source

For an ecosystem to last, it needs more than technical enthusiasm.

It needs a sustainable economic model.

MyZubster is experimenting with ways to connect services, marketplace activity and contributor rewards.

The broader payment direction includes conventional payment infrastructure and privacy-conscious cryptocurrency options, including Monero.

Monero is relevant to our exploration because financial privacy can matter to independent participants.

But payment infrastructure must be approached carefully.

There are important distinctions between:

A proposed reward and an approved budget
An accepted contribution and a payment obligation
An internal accounting unit and a transferable cryptocurrency
A transaction record and independently verified settlement
A marketplace listing and an actual customer purchase

The MYZ concept is currently treated as an internal reward/accounting mechanism unless a separate settlement arrangement is explicitly established.

We do not want to promise earnings, funded bounties or automatic cryptocurrency rewards that have not been approved and financed.

What would make MyZubster sustainable?

Our long-term hypothesis is that a useful marketplace, independently maintained services and verifiable contributions could reinforce one another.

People offer useful services.

Customers and communities receive value.

Contributors improve the software.

Independent operators maintain their own infrastructure.

A transparent, sustainable economic model could help fund shared services.

That cycle is a goal to validate, not an achievement we are claiming today.

12. How You Can Join MyZubster Today

There is no single correct way to participate.

You can choose the path that matches your interests.

Path A — Become a Marketplace seller

If you have a skill, service or creative product, explore the Marketplace and try creating a listing.

You might offer development, design, technical assistance, local services or another legitimate service.

Marketplace: https://www.myzubster.com/community-marketplace.html

Path B — Become a GitHub contributor

If you enjoy building software, start by exploring the repository.

Choose a small issue, discuss the proposed change and submit a pull request.

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

Path C — Connect your independent project

Already working on something?

You can explore how your project might connect through documentation, APIs, evidence or a pilot integration.

You do not need to give up your repository or infrastructure.

Contributor roles: https://github.com/MyZubster-Ecosystem/myzubster/issues/1622

Path D — Experiment with independent infrastructure

If you have experience with Linux, Docker, Tor or networking, you can help document and test independent-node architecture.

Participation is voluntary, and production access or infrastructure spending is not required.

Onion node registry: https://github.com/MyZubster-Ecosystem/myzubster/issues/1623

Path E — Contribute knowledge or a real-world pilot

You do not need to be a programmer.

You may be able to help through documentation, community initiatives, local projects, usability feedback or knowledge sharing.

Start with something small and demonstrable.

13. What We're Looking for Next

We're particularly interested in people who want to help us answer practical questions:

Can a new user create a useful Marketplace listing without assistance?
Can a first-time contributor complete a GitHub task with clear guidance?
Can independent projects exchange data through documented interfaces?
Can a contributor-operated Onion service be verified without exposing private information?
Can knowledge and contribution evidence be made portable?
Can the ecosystem generate enough real-world value to sustain its infrastructure and maintenance?

These are open engineering, product and community questions.

We believe the most useful way to answer them is to build small, reproducible experiments and share the results.

14. An Invitation to Build Together

MyZubster is not a finished decentralized economy.

It is an open-source project exploring how marketplaces, AI assistance, verifiable skills, community knowledge and independently operated infrastructure can work together.

Some components are operational.

Others are prototypes, proposals or experiments.

We're looking for people who want to help turn those ideas into useful, testable software and real-world applications.

You can start without spending money, operating a server or making a long-term commitment.

Create a listing.

Read an issue.

Submit a small improvement.

Document an experiment.

Introduce a project.

Help another contributor.

The network becomes meaningful when independent people can create value together.

Join the ecosystem

🌐 MyZubster: https://www.myzubster.com/

🛒 Marketplace: https://www.myzubster.com/community-marketplace.html

🤖 Zorgax: https://www.myzubster.com/zorgax

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

🤝 Choose your contribution path: https://github.com/MyZubster-Ecosystem/myzubster/issues/1622

🧅 Independent Onion nodes: https://github.com/MyZubster-Ecosystem/myzubster/issues/1623

What would you like to contribute: code, a service, a skill, a local project, or an independent node?

Tell us in the comments or join the discussion on GitHub.

Let's build useful connections between people, knowledge and independent technology.

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.