Coder Legion - Recent posts tagged metaverse

How We Secured the MyZubster Metaverse: Session Ownership, Verified Explorers and the Road to Realti

Sat, 17 Oct 2026 05:20:55 +0000

A technical update on the architecture, security controls, testing and remaining roadmap behind the open-source MyZubster Metaverse.
The MyZubster Metaverse is moving from an experimental interface toward a secure, testable multiplayer environment.
Our goal is not simply to display avatars in a browser. We want to create an open-source world connecting public profiles, verified contributors, Zorgax characters, community knowledge and software-development workflows.
The public Metaverse is available at:
https://www.myzubster.com/metaverse
This article describes what we have implemented, the security problem we recently solved and what remains before the platform can support realtime interaction at scale.
The current experience
A user can enter the MyZubster world as a guest without providing:

a cryptocurrency wallet;
identity documents;
a GitHub account;
an installed application.
The current interface supports guest onboarding through a public display name and also presents verified explorers associated with authorized public accounts.
This creates two identity levels:
1. Guest explorers use temporary world sessions.
2. Verified explorers have characters linked to a MyZubster account or confirmed GitHub identity.
  “Verified” does not mean KYC or legal identity verification. It only confirms control of the connected public account.
  Building the presence layer
  The backend maintains a presence record for every active participant.
  A simplified record may contain:
  {
  sessionId,
  displayName,
  characterId,
  accountId,
  githubLogin,
  position,
  status,
  lastSeenAt
  }
  This model supports the main world operations:
  Join
  Synchronize
  Move
  Chat
  Emote
  Leave
  Retrieve events
  Public players must be discoverable by other clients, so each presence has a public session identifier.
  However, a public identifier must never be treated as proof that a request belongs to that player.
  That distinction became the focus of our latest security milestone.
  The original session-ownership problem
  A multiplayer client needs to identify which session it wants to update.
  For example:
  {
  "sessionId": "public-session-id",
  "x": 120,
  "y": 80
  }
  If the backend trusts only sessionId, a malicious user may be able to submit another player’s identifier and perform actions on their behalf.
  Depending on the exposed routes, this could allow an attacker to:
move another character;
send chat messages under another identity;
publish unauthorized emotes;
retrieve session-specific events;
terminate another player’s session.
A public session ID is an identifier, not an authorization credential.
Implementing possession-bound sessions
We implemented a new security boundary in:
Pull Request #34 — Bind world actions to session credentials
The change was merged into main as commit:
148a798
Every new Metaverse session now receives two different values:
Public session ID
Private session token
The public ID can appear in world-state responses. The private token proves that the client controls the session.
Cryptographically random credentials
The server generates a token using 32 random bytes:
const sessionToken = crypto
.randomBytes(32)
.toString("base64url");
This provides 256 bits of entropy.
The raw token is returned only during session creation and is never included in public presence data.
Storing only a digest
The server does not persist the raw credential.
Instead, it calculates a SHA-256 digest:
const sessionTokenHash = crypto
.createHash("sha256")
.update(sessionToken)
.digest("hex");
Only sessionTokenHash is stored with the presence record.
This prevents a database reader from immediately obtaining active bearer credentials.
Constant-time comparison
When a protected request arrives, the server hashes the submitted credential and compares it with the stored digest.
The verification uses a constant-time comparison:
crypto.timingSafeEqual(expected, received);
A shared ownership middleware verifies that:
the session exists;
a credential was supplied;
the credential has the expected format;
its digest matches the stored value;
the caller owns the requested session.
Invalid or missing credentials return:
HTTP 401 Unauthorized
Protected world routes
Session ownership is now required for mutable and session-specific operations such as:
/sync
/move
/chat
/emote
/leave
/events
Knowing another participant’s sessionId is no longer sufficient to control their character.
The authorization rule is now:
Public session ID
```
  +
```
Private possession token
```
  =
```
Authorized world action
Keeping credentials out of public payloads
The frontend sends the private token through a dedicated HTTP header:
X-Metaverse-Session-Token: <private-token>
Example:
const createSessionHeaders = (sessionToken) => ({
"X-Metaverse-Session-Token": sessionToken,
});
The world-state body remains limited to operational data:
{
"sessionId": "public-session-id",
"x": 120,
"y": 80
}
This separation reduces the probability that credentials are accidentally copied into:
world events;
analytics;
public API responses;
application logs;
debugging output;
cached payloads.
The credential is also kept in React runtime memory instead of being written to localStorage or public profile objects.
An in-memory token is not a complete defense against browser compromise, but it reduces persistent credential exposure.
Identity boundaries
The Metaverse now distinguishes between several layers:
Account identity
```
↓
```
Public profile
```
↓
```
Character identity
```
↓
```
Temporary world session
```
↓
```
Private session credential
These layers have different meanings.
A verified GitHub account does not automatically prove legal identity, employment, payment eligibility or institutional affiliation.
Similarly, a public session ID identifies a player’s presence but does not authorize requests for that player.
Documenting these boundaries is essential for avoiding security and governance problems later.
Testing the implementation
The session-ownership change includes backend, frontend and architecture-level tests.
Backend tests
The targeted backend suites verify:
secure token generation;
SHA-256 digest storage;
valid credential acceptance;
missing credential rejection;
invalid credential rejection;
cross-session mutation prevention;
protected movement and chat;
protected emotes and leave operations;
exclusion of secrets from public responses.
Results:
3 backend suites
22 tests passed
Frontend tests
Frontend coverage verifies:
token retention in application memory;
use of the session-token header;
authenticated world operations;
removal of tokens from normal JSON bodies;
correct handling of protected session requests.
Results:
1 frontend suite
5 tests passed
Integration and deployment
The completed verification included:
Production frontend build: successful
git diff --check: clean
Marketplace regression suite: passed
Vercel preview deployments: successful
Main CI workflow: successful
Production deployment: successful
The public Metaverse route was also loaded after deployment.
Current architecture
The current system can be summarized as:
React Metaverse Client
```
  |
  | HTTPS
  | X-Metaverse-Session-Token
  v
```
Node.js / Express API
```
  |
  | Session ownership middleware
  | Hash verification
  v
```
Metaverse Presence Storage
```
  |
  v
```
Shared world synchronization
This is a practical foundation, but it is not yet the final realtime architecture.
What remains to be built
Realtime communication
The current synchronization model still depends on polling in important areas.
We need a versioned realtime protocol supporting:
authenticated WebSocket connections;
session-to-connection binding;
reconnect handling;
ordered events;
duplicate-event protection;
presence expiration;
backpressure;
slow-client management.
The protocol should remain usable by multiple clients, including future community-built and WebXR clients.
Distributed rate limiting
Per-process rate limiting is not enough when the backend runs across multiple instances.
We need a distributed limiter for:
Session creation
Authentication attempts
Movement
Chat
Emotes
Reconnects
Limits should be calculated using combinations of:
IP address;
account ID;
session ID;
route;
world ID;
time window.
Chat and authentication need stricter limits than normal movement updates.
Session expiration and revocation
The possession credential is now implemented, but lifecycle controls still need improvement:
explicit expiration;
server-side revocation;
abandoned-session cleanup;
token rotation;
reconnect-safe renewal;
active-session limits;
multi-device logout;
suspicious-session invalidation.
Canonical authentication
Verified characters require a stable account-linking process.
The remaining work includes:
canonical GitHub OAuth;
verified account-to-character relationships;
account-link substitution protection;
reauthorization;
identity-change audit trails;
account recovery procedures.
The backend must never trust a GitHub username supplied directly by a browser.
Privacy-safe analytics
We need enough telemetry to maintain the platform without introducing unnecessary tracking.
Useful operational metrics include:
concurrent sessions;
API latency;
reconnect frequency;
server errors;
world capacity;
rate-limit events;
event throughput.
Retention, aggregation and access rules must be documented before expanding analytics.
Reliability and load testing
Future tests must simulate:
simultaneous joins;
movement bursts;
reconnect storms;
malformed messages;
database latency;
backend restarts;
multiple server instances;
slow or disconnected clients.
We also need measurable targets for latency, error rate, recovery time and maximum concurrent participants.
Complete E2E acceptance testing
The complete guest flow should be automated:
Join
→ receive credential
→ become visible
→ move
→ chat
→ publish an emote
→ reject impersonation attempts
→ reconnect safely
→ leave or expire
The same acceptance flow is required for verified characters.
WebXR
WebXR remains part of the roadmap, but it should follow security and realtime stabilization.
The eventual world protocol should support:
2D web client
3D browser client
WebXR client
Mobile client
Independent community clients
All clients should use the same documented API and event protocol.
Dependency-security debt
The repository currently reports vulnerabilities during npm audit.
These findings were already present and were not introduced by the Metaverse session-ownership pull request, which did not change package manifests or lockfiles.
However, they remain technical debt.
A separate dependency-hardening milestone should include:
1. classifying production and development exposure;
2. updating direct dependencies;
3. reviewing transitive dependencies;
4. replacing abandoned packages;
5. regenerating lockfiles;
6. running complete regression tests;
7. updating SBOM and audit evidence.
  Disabling the audit to produce a green badge would hide the problem instead of solving it.
  Recommended roadmap
  The recommended implementation sequence is:
8. Session expiration and revocation
9. Distributed rate limiting
10. Canonical account authentication
11. Versioned realtime protocol
12. Authenticated WebSocket transport
13. Privacy-safe monitoring
14. Reliability and load testing
15. Complete E2E acceptance tests
16. Dependency-security remediation
17. WebXR client development
  Security, reliability and protocol stability must come before graphical complexity.
  Open-source participation
  We are looking for contributors interested in:
React;
Node.js and Express;
MongoDB;
Redis;
WebSockets;
application security;
privacy engineering;
abuse prevention;
load testing;
WebXR;
technical documentation.
Repository:
https://github.com/danieldirimini-myzubster/myzubster
Public Metaverse:
https://www.myzubster.com/metaverse
Security implementation:
https://github.com/danieldirimini-myzubster/myzubster/pull/34
Conclusion
The MyZubster Metaverse now has a stronger session-security foundation.
We moved from public identifier-based operations to possession-bound authorization using:
256-bit random credentials;
SHA-256 token digests;
constant-time verification;
dedicated authorization headers;
memory-only client credentials;
protected world routes;
backend and frontend security tests.
The next milestone is transforming this foundation into a distributed realtime system with strong authentication, rate limiting, privacy-safe observability and measurable reliability.
The Metaverse is online, but the deeper work is still ahead: building an open world protocol that other developers can inspect, test and extend.

Engineering a Browser-First Metaverse: WebXR Fallbacks, Server-Authoritative Rooms, and Versioned

Mon, 12 Oct 2026 13:23:15 +0000

Engineering a Browser-First Metaverse: WebXR Fallbacks, Server-Authoritative Rooms, and Versioned Scene Manifests

The MyZubster Metaverse is being developed as a browser-first platform rather than a VR-only application.
Our baseline requirement is straightforward:
A user must be able to access the experience from a normal desktop or mobile browser. WebXR should enhance the experience when available, but its absence must never block access.

During the latest development cycle, we implemented two foundational components:

A browser and WebXR capability-detection layer with graceful fallback
A versioned scene-manifest contract validated by the backend before publication
This article explains the architecture, implementation details, validation rules, current production evidence, and the remaining roadmap.
Project Links
- Repository: MyZubster-Ecosystem/myzubster
- Live Metaverse: myzubster.com/metaverse
- WebXR fallback: Pull Request #1597
- Scene-manifest validation: Pull Request #1601
- LIFE Pilot entry point: myzubster.com/life-pilot
  System Architecture
  The current metaverse architecture separates device capabilities, presentation, room authority, scene configuration, and evidence.
  ┌─────────────────────────────────────────────────────────┐
  │ React Browser UI │
  │ │
  │ Capability checks → status UI → 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 │
  └────────────────────────────┬────────────────────────────┘
```
                    │
                    ▼
```
  ┌─────────────────────────────────────────────────────────┐
  │ LIFE Evidence Layer │
  │ │
  │ Pilot → provenance → evidence → KPI/MRV → visualization │
  └─────────────────────────────────────────────────────────┘
  The separation creates several important boundaries:
- The browser reports its capabilities.
- The server decides whether a room transition is valid.
- The manifest describes what the client may load.
- The evidence layer determines what real-world claims can be displayed.
- The 3D client is never the authority for authentication or environmental evidence.
  What Currently Works
  Neon Plaza can be entered through a normal browser without installing a native application or connecting a VR headset.
  In a 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
- Non-blocking fallback when immersive WebXR is unavailable
  This was a desktop production verification. Real mobile devices and physical WebXR headsets still require a structured validation matrix.
  Part 1: Browser and WebXR Capability Detection
  The first milestone was implemented in PR #1597.
  Explicit WebXR States
  WebXR availability is not represented as a simple boolean.
  export const WEBXR_STATUS = Object.freeze({
  CHECKING: 'checking',
  SUPPORTED: 'supported',
  UNSUPPORTED: 'unsupported',
  ERROR: 'error'
  });
  This distinguishes between four different conditions:
  checking
  │
  ├── supported
  ├── unsupported
  └── error
  A browser that does not expose navigator.xr is different from a browser that exposes the API but fails during capability detection.
  That distinction is useful for both debugging and user communication.
  Browser Baseline
  The client checks a small browser baseline independently of WebXR:
  export function browserCapabilityBaseline(browser = window) {
  return [ { label: 'JavaScript', ok: true }, { label: 'Fetch API', ok: typeof browser.fetch === 'function' }, { label: 'Local storage', ok: Boolean(browser.localStorage) }, { label: 'CSS Grid', ok: Boolean( browser.CSS?.supports?.('display', 'grid') ) }, { label: 'Connection', ok: browser.navigator?.onLine !== false } ];
  }
  WebXR is checked separately because it is an enhancement rather than a baseline dependency.
  Detecting Immersive VR
  The detection function accepts a navigator-like dependency:
  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'
};

}
}
Passing navigatorLike as an argument makes the function easier to test.
For example:
const fakeNavigator = {
xr: {

isSessionSupported: async (mode) =>
  mode === 'immersive-vr'

}
};

const result =
await detectImmersiveVr(fakeNavigator);

expect(result.status).toBe('supported');
The unsupported case can also be tested without a real headset:
const result =
await detectImmersiveVr({});

expect(result).toEqual({
status: 'unsupported',
reason: 'api-unavailable'
});
Non-Blocking Fallback
The UI maps the capability state to a user-facing message:
const XR_COPY = {
[WEBXR_STATUS.CHECKING]:

'Checking WebXR support…',

[WEBXR_STATUS.SUPPORTED]:

'Immersive WebXR is available',

[WEBXR_STATUS.UNSUPPORTED]:

'Browser mode active: a headset is not required',

[WEBXR_STATUS.ERROR]:

'WebXR could not be verified: continue in browser mode'

};
The important behavior is that an unsupported or failed WebXR check does not produce a fatal application state.
{xr.status !== WEBXR_STATUS.SUPPORTED && (

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

)}
The capability model therefore follows progressive enhancement:
Standard browser

↓

Browser-based Neon Plaza

↓

Optional capabilities

  ├── WebGL enhancements
  ├── spatial audio
  ├── immersive WebXR
  └── headset controllers

Part 2: Server-Authoritative Room State
The metaverse room lifecycle is enforced by the backend rather than trusted to client-side state.
Forward-Only State Machine
The backend defines valid transitions:
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([])
});
The resulting lifecycle is:
draft
│
▼
published
│
├──────────────┐
▼ ▼
scheduled live
│ │
└──────►───────┘

The backend rejects invalid transitions:
if (
patch.state &&
patch.state !== room.state
) {
const allowed =

ROOM_TRANSITIONS[room.state]?.has(patch.state);

if (!allowed) {

return {
  valid: false,
  status: 409,
  error:
    `Invalid room transition ` +
    `${room.state} -> ${patch.state}`
};

}

room.state = patch.state;
}
A modified browser therefore cannot return an ended room to the live state simply by changing its local representation.
Access Policies
Rooms support three access policies:
accessPolicy: {
type: String,
enum: [

'public',
'authenticated',
'private'

],
default: 'authenticated'
}
The room model also includes bounded capacity:
capacity: {
type: Number,
min: 1,
max: 500,
default: 100
}
Join Validation
Before joining, the backend checks session state, blocklists, private-room access, and capacity:
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'
};

}

const privateAccessDenied =

room.accessPolicy === 'private' &&
!(room.allowedUserIds || []).includes(actor) &&
actor !== String(room.hostUserId);

if (privateAccessDenied) {

return {
  valid: false,
  status: 403,
  error: 'Private room access denied'
};

}

const current =

new Set(session.participantUserIds || []);

const capacityReached =

!current.has(actor) &&
current.size >= session.capacity;

if (capacityReached) {

return {
  valid: false,
  status: 409,
  error: 'Session is at capacity'
};

}

return { valid: true };
}
This is important because client-side room membership cannot be considered authoritative.
Part 3: Realtime Session Tokens
After a successful join, the backend issues a short-lived token scoped to the metaverse session.
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 token binds the connection to:

A user
A specific purpose
A session
A room
A scene-manifest version
Using a dedicated purpose value reduces the risk of using a generic application token in the wrong context.
The short expiration also limits the useful lifetime of a captured realtime credential.
Future work will include:
Token refresh
Explicit revocation
Reconnect behavior
Redis-backed realtime coordination
Horizontal scaling
Multi-region latency handling
Replay-resistance analysis
Part 4: Privacy-Aware Moderation References
Moderation interfaces do not need to expose raw account IDs.
The backend generates opaque session-scoped participant references:
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);
}
The public session response returns a count rather than the participant-ID array:
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
};
}
This does not provide anonymity by itself, but it limits unnecessary identifier exposure.
Part 5: Versioned Scene Manifest v1
The next milestone was delivered in PR #1601.
The manifest is the contract between:
Room configuration
Backend validation
Client runtime
Asset delivery
Capability requirements
Future rollback behavior
Supported Contract Values
const SCENE_MANIFEST_SCHEMA_VERSION = '1';

const ASSET_TYPES = new Set([ 'gltf', 'glb', 'image', 'audio', 'video' ]);

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' ]);
The schema is deliberately constrained.
An unrestricted JSON document would make compatibility, validation, migration, and rollback increasingly difficult.
Safe Default Manifest
New rooms receive a minimal valid scene definition:
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: []

};
}
The room creation service applies it automatically:
const room = await VirtualRoom.create({
roomId: crypto.randomUUID(),
slug: safeSlug,
name: safeName,
hostUserId: String(actorUserId),
accessPolicy,
capacity: numericCapacity,
stagePolicy,
sceneManifest: defaultSceneManifest()
});
This avoids creating rooms with an undefined scene state.
Example Scene Manifest
A more complete 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-audio",
  "type": "audio",
  "url": "https://cdn.myzubster.com/audio/neon-plaza.7.ogg"
},
{
  "id": "life-dashboard",
  "type": "image",
  "url": "https://cdn.myzubster.com/life/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"

]
}
The manifest contains only declarative scene information. It does not grant permissions or override room authority.
Part 6: Manifest Validation
Identifier Validation
Identifiers use a restricted character set:
function validId(value) {
return (

typeof value === 'string' &&
/^[a-zA-Z0-9][a-zA-Z0-9_-]{0,63}$/.test(value)

);
}
This avoids IDs containing markup, control characters, or unexpected path syntax.
Vector Validation
Positions must contain exactly three finite values:
function validVector(value) {
return (

Array.isArray(value) &&
value.length === 3 &&
value.every(Number.isFinite)

);
}
These values are invalid:
[0, 1] [0, 1, null]
[0, 1, NaN] [0, 1, Infinity]
HTTPS-Only URLs
External resources 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 rejects examples such as:
http://example.com/scene.glb
javascript:alert(1)
invalid-url
HTTPS is only the first boundary. Future validation should also enforce:

Approved asset origins
Content-Type checks
Download timeouts
File-size limits
Redirect restrictions
Content hashes
glTF structural validation
Geometry budgets
Texture budgets
CORS requirements
Bounded Collections
Manifest collections are explicitly bounded:
if (
!Array.isArray(input.assets) ||
input.assets.length > 100
) {
errors.push(
'assets must be an array with at most 100 entries'
);
}
Spawn points require at least one entry and allow a maximum of 32:
if (
!Array.isArray(input.spawnPoints) ||
input.spawnPoints.length < 1 ||
input.spawnPoints.length > 32
) {
errors.push(
'spawnPoints must contain between 1 and 32 entries'
);
}
These limits reduce accidental or malicious resource amplification before the runtime even begins downloading scene assets.
Part 7: Publication Gate
A scene is validated when its manifest is updated and again when the room is published.
const manifestCandidate =
patch.sceneManifest !== undefined
? patch.sceneManifest
: room.sceneManifest;

if (
patch.sceneManifest !== undefined ||
patch.state === 'published'
) {
const validation =

validateSceneManifest(manifestCandidate);

if (!validation.valid) {

return {
  valid: false,
  status: 400,
  error: 'Invalid scene manifest',
  details: validation.errors
};

}

room.sceneManifest =

validation.manifest;

}
This establishes an important invariant:
Invalid scene manifest

      │
      ▼

Backend validation failure

      │
      ▼

Publication rejected
The frontend may eventually provide immediate validation feedback, but frontend checks are not authoritative.
An API consumer could bypass the official interface. The backend must enforce the contract independently.
Part 8: Persistence Model
The room currently stores:
sceneManifestVersion: {
type: String,
default: '1'
},

sceneManifest: {
type: mongoose.Schema.Types.Mixed,
default: null
}
The public room response includes both fields:
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 sufficient for the current validation milestone, but the next persistence model should introduce immutable historical versions.
Part 9: Automated Tests
The manifest tests cover:

The safe default manifest
Versioned asset bundles
HTTPS asset references
Valid spawn points
Valid interaction zones
Portal destinations
Unsupported schema versions
Insecure URLs
Malformed vectors
Duplicate IDs

Unsupported capabilities
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'
])

);
}
);
The implementation passed:

Backend lint
Backend unit tests
Frontend unit tests
Backend build
Frontend build
Security audit
Continuous evidence checks
Production Evidence and Current Limits
The following behavior was verified against the production desktop experience:
Authentication was active
Neon Plaza loaded
The session appeared online
Movement controls were visible
Emotes were available
Chat was available
The capability panel rendered
Browser baseline checks passed
WebXR fallback messaging appeared
The browser experience remained available without immersive WebXR
The following items remain unverified or incomplete:
Real-device Android testing
Real-device iOS testing
Physical WebXR headset entry and exit
Controller compatibility
Long-running realtime reliability
High-concurrency room testing
Versioned CDN asset loading
Manifest rollback
Full accessibility verification
Complete LIFE evidence integration
This separation is intentional. A roadmap entry is not evidence that a capability is complete.
Connecting the Metaverse to LIFE
MyZubster is also exploring LIFE-oriented environmental and circular-economy workflows.
The metaverse can provide a public and educational interface for those projects, but it must not replace the underlying evidence system.
The proposed flow is:
Real-world pilot
```
↓
```
Measurement or observation
```
↓
```
Data provenance
```
↓
```
Evidence classification
```
↓
```
KPI / MRV calculation
```
↓
```
MyZubster project record
```
↓
```
Metaverse representation
```
↓
```
Educational mission
```
↓
```
Community feedback
A scene might contain:
A portal to a pilot
A visualization of measurements
A description of the methodology
A list of missing evidence
A contribution mission
Replication instructions
KPI and MRV status
However:
3D visualization ≠ verified measurement
simulation ≠ field result
self-declaration ≠ independent validation
project goal ≠ achieved environmental impact
These distinctions should be visible in the interface.
Possible Evidence Contract
A future scene object could include an evidence reference:
{
"id": "water-savings-display",
"type": "evidence-panel",
"position": [4, 1.5, -2],
"evidence": {
"status": "measured",
"source": "pilot-observation-2026-10",
"methodologyVersion": "0.2",
"independentVerification": false
}
}
Possible evidence states might include:
planned
self-declared
observed
measured
methodology-reviewed
independently-verified
disputed
superseded
The client could render these states differently without misrepresenting their confidence level.
Remaining Engineering Work
Immutable Manifest History
The current active manifest should eventually become a pointer to an immutable history.
{
roomId: 'room-123',
version: '7',
schemaVersion: '1',
assetBundleVersion: '42',
checksum: 'sha256:...',
manifest: {},
createdBy: 'account-reference',
createdAt: '2026-10-12T00:00:00Z'
}
The structure should become:
VirtualRoom
│
└── activeManifestVersion: 7

SceneManifestVersion

├── version 5
├── version 6
└── version 7

Safe Rollback
Rollback should create a new version based on a previous snapshot:
v5 → v6 → v7

      │
      └── rollback to v6
                ↓
               v8

Version 7 should not be deleted or overwritten. This preserves auditability.
CDN Asset Pipeline
A future pipeline should follow:
upload
↓
validate
↓
scan
↓
optimize
↓
calculate hash
↓
assign immutable version
↓
publish to CDN
↓
reference from manifest
Asset URLs should be immutable:
/scenes/neon-plaza.42.glb
/textures/neon-floor.18.webp
/audio/neon-ambient.7.ogg
Client-Side Scene Loader
The client will eventually need a structured loading pipeline:
fetch room
↓
fetch active manifest
↓
validate schema version
↓
compare required capabilities
↓
load critical assets
↓
load optional assets
↓
report failures
↓
enter scene
Graceful Asset Failure
Not every asset failure should destroy the whole scene.
critical asset missing

→ load fallback scene

important asset missing

→ continue with visible warning

optional asset missing

→ omit it and continue

A future asset entry could declare this:
{
"id": "neon-plaza",
"type": "glb",
"url": "https://cdn.myzubster.com/scenes/neon-plaza.42.glb",
"criticality": "critical",
"fallbackAssetId": "basic-plaza"
}
Runtime Resource Budgets
Valid JSON does not guarantee safe runtime performance.
We still need budgets for:

File size
Polygon count
Texture dimensions
Texture memory
Draw calls
Animation count
Shader complexity
Audio duration
Video resolution
Concurrent requests
Scene initialization time
Mobile Validation
A real-device test matrix should include:
Android Chrome
Android Firefox
iOS Safari
iPadOS Safari
Low-memory devices
Slow networks
Small screens
Touch-only interaction
Screen rotation
Background and resume behavior
WebXR Device Validation
Physical-headset testing should cover:
Entering immersive mode
Exiting immersive mode
Session interruption
Controller input
Focus loss
Boundary changes
Sleep and resume
Spatial audio
Motion comfort
Performance degradation
Realtime Reliability
Load tests should cover:
Concurrent joins
Concurrent leaves
Chat bursts
Stage requests
Moderation operations
Reconnect storms
Token refresh
Database latency
Redis degradation
Server restart
Network partitions
Accessibility
Browser-first also means accessible-first.
The remaining accessibility work includes:
Keyboard navigation
Screen-reader semantics
Focus management
Reduced motion
Colour contrast
Text scaling
Captions
Touch-target sizing
Non-spatial alternatives
Cognitive-load review
Important project information must never be available only through an immersive 3D interaction.
Proposed Roadmap
C2.1 — Immutable Manifest Versions
create version model
→ validate manifest
→ calculate checksum
→ store immutable snapshot
→ update active pointer
C2.2 — Rollback
select previous version
→ validate snapshot
→ create a new version
→ update active pointer
→ preserve audit history
C2.3 — Asset Pipeline
upload
→ validate
→ optimize
→ hash
→ version
→ publish
→ reference
C2.4 — Client Scene Loader
fetch
→ validate
→ negotiate capabilities
→ load
→ apply fallbacks
→ expose status
C2.5 — First LIFE Scene
select pilot
→ define evidence contract
→ define KPI/MRV boundaries
→ generate manifest
→ implement scene
→ run public test
How to Contribute
The most useful contributions currently include:
Mobile browser test reports
Real-headset WebXR test reports
Scene-manifest reviews
glTF and GLB validation
Asset optimization
Accessibility testing
Realtime load tests
Security reviews
CDN design
Rollback implementation
LIFE evidence modelling
KPI/MRV data contracts
Technical documentation
A useful test report should contain:
device
operating system
browser
exact version
network conditions
steps performed
expected result
observed result
logs or screenshots when safe
related issue or pull request
Do not include:
Passwords
Authentication tokens
Private keys
Wallet seed phrases
Unredacted personal information
Sensitive participant details
Precise private locations
Conclusion
The MyZubster Metaverse now has two important engineering foundations:
1. A browser-first capability layer where WebXR is progressive enhancement
2. A server-validated scene contract that blocks invalid manifests from publication
  The completed work is publicly traceable:
PR #1597 — Browser and WebXR fallback
PR #1601 — Versioned scene-manifest validation
The next phase is not simply about adding more 3D content.
It is about creating a reliable technical chain:
code
→ validated contract
→ immutable version
→ versioned asset
→ reliable session
→ real-world pilot
→ evidence
→ understandable visualization
→ community contribution
That is the direction of the MyZubster Metaverse: an open, browser-first environment connecting virtual experiences to public code, documented projects, explicit evidence boundaries, and real-world collaboration.
Status verified: October 12, 2026.

15:21

How We Built Revocable Sessions and Refresh-Token Replay Protection for the MyZubster Metaverse

Mon, 28 Sep 2026 01:35:52 +0000

Ecco la versione in inglese pronta per CoderLegion.
How We Built Revocable Sessions and Refresh-Token Replay Protection for the MyZubster Metaverse
Authentication in a Metaverse platform is more than a login form.
An authenticated identity may control characters, social relationships, private spaces, Marketplace activity and, eventually, payment-related operations. For MyZubster, relying only on long-lived JSON Web Tokens was no longer a sufficient security model.
Under MYZ-71 — Authentication, Sessions & Account Security, we started replacing stateless browser authentication with persistent, revocable and observable server-side sessions.
This article describes what we implemented, how refresh-token rotation works, how we detect token replay, what we tested and what still needs to be completed before production deployment.
The implementation is currently in a Draft pull request. It has not been merged or declared production-ready.

Why stateless JWT authentication was not enough
JWTs are useful because a server can validate them without loading a database record for every request.
However, a completely stateless model creates important limitations:

logout cannot reliably invalidate an existing token;
users cannot see which devices are authenticated;
administrators cannot revoke one compromised device;
a stolen token remains valid until expiration;
password changes do not automatically terminate sessions;
long-lived tokens increase the potential impact of credential theft;
tokens stored in localStorage can be accessed by malicious JavaScript after an XSS compromise.
We therefore introduced a hybrid architecture:
Authentication
```
↓
```
Persistent server-side session
```
↓
```
Short-lived JWT access token
```
↓
```
Rotating opaque refresh token
```
↓
```
Replay detection and session revocation
JWTs are still used for request authentication, but the server-side session is now the final source of authority.
Persistent server-side sessions
We added a MongoDB AuthSession model.
A separate session is created for each authenticated device. The record contains:
a unique session identifier;
the user who owns the session;
creation and expiration timestamps;
the last activity timestamp;
revocation state and reason;
limited device metadata;
a privacy-preserving client-IP digest;
the current refresh-token hash;
a bounded history of consumed refresh-token hashes;
refresh-token rotation metadata.
MongoDB TTL indexing is used to remove expired session records automatically.
This enables real session lifecycle management. A valid JWT is rejected whenever its associated session is expired, missing or revoked.
Session-bound access tokens
New JWT access tokens include a server-generated sid claim.
A simplified payload looks like this:
{
"sub": "user-id",
"sid": "session-uuid",
"jti": "access-token-uuid",
"iat": 1790540000,
"exp": 1790540900
}
Authentication now involves two checks:
1. Verify the JWT signature and expiration
2. Validate the persistent session referenced by sid
  This architecture preserves the advantages of JWTs while restoring the ability to revoke access immediately.
  If the user removes a device from the account-security page, the session becomes invalid even if its most recent JWT has not expired.
  Opaque refresh tokens
  The refresh token is not a JWT and does not contain trusted user data.
  Its conceptual format is:
  myzr.<session-id>.<cryptographically-random-secret>
  The random section is produced using a cryptographically secure random-number generator.
  The complete refresh token is sent to the authenticated browser, but it is never stored directly in MongoDB.
  Instead, the backend calculates:
  HMAC-SHA256(server secret, raw refresh token)
  Only the resulting digest is saved.
  This prevents a database leak from immediately exposing usable refresh credentials.
  Protected authentication cookies
  Refresh tokens are stored in cookies configured with:
  HttpOnly
  SameSite=Lax
  Secure in production
  Path=/api/auth
  HttpOnly prevents frontend JavaScript from reading the credential.
  The restricted path reduces the number of requests carrying the refresh cookie.
  Access tokens can also be received through an HttpOnly cookie. Bearer-token authentication remains temporarily supported to avoid breaking clients during the migration.
  Atomic refresh-token rotation
  A refresh token is single-use.
  When the browser calls:
  POST /api/auth/refresh
  the backend:
3. reads the refresh cookie;
4. extracts the session identifier;
5. calculates the HMAC digest of the submitted token;
6. generates a new opaque token;
7. atomically compares the submitted hash with the current stored hash;
8. replaces the stored hash;
9. records the consumed hash;
10. issues a new access token;
11. sends new access and refresh cookies.
  The database update only succeeds if:
the session exists;
the session has not expired;
the session has not been revoked;
the submitted hash is still the current refresh-token hash.
This is effectively a compare-and-swap operation.
If two requests try to use the same refresh token simultaneously, only one can rotate it successfully.
Refresh-token replay detection
Rotation prevents normal reuse, but the system must also detect when an old token appears again.
After every successful rotation, the consumed token hash is placed in a bounded history.
If a token from that history is submitted again, the server treats it as a possible credential compromise.
Previously consumed token submitted
```
          ↓
```
Replay detected
```
          ↓
```
Entire server-side session revoked
```
          ↓
```
Authentication cookies cleared
```
          ↓
```
A new login is required
The session receives the revocation reason:
refresh-token-replay
The history is limited to the latest 50 hashes so the MongoDB document cannot grow indefinitely.
Replay does not necessarily prove malicious activity. It could also indicate an outdated client or an unusual concurrency condition. Revoking the session is nevertheless the safest response.
New authentication endpoints
The current implementation provides the following endpoints.
Refresh the session
POST /api/auth/refresh
This endpoint rotates the refresh token and issues a new access token.
The raw refresh token is never included in the JSON response.
Log out
POST /api/auth/logout
Logout is idempotent.
Authentication cookies are cleared even when the access token is missing, malformed, expired or already revoked.
When possible, the refresh token is used to find and revoke the persistent session.
Retrieve the authenticated account
GET /api/auth/me
Returns the authenticated user and safe session metadata.
List active devices
GET /api/auth/me/sessions
Returns the user’s active sessions and indicates the current device.
Revoke a device
DELETE /api/auth/me/sessions/:sessionId
Allows users to terminate another session remotely.
Revoking the current session also clears local authentication state and returns the user to the login flow.
Password and social authentication
Password registration and login now create persistent sessions and issue both access and refresh cookies.
Verified social-login flows use the same architecture.
The raw refresh token is not placed inside:
redirect URLs;
OAuth query parameters;
signed callback tickets;
public API responses.
This reduces the risk of credentials leaking through browser history, analytics systems, proxy logs or referrer headers.
Account-security interface
The React frontend now includes:
/account/security
The page displays:
active sessions;
the current device;
session creation time;
last activity;
expiration time;
limited device information.
Users can remotely revoke another device or terminate the current session.
The page is linked from the authenticated account panel and Neon Plaza.
The deployment configuration also supports the route as a single-page application path and applies:
X-Robots-Tag: noindex, nofollow
Account-security pages should not be indexed by search engines.
Privacy-preserving session metadata
The system does not store raw client IP addresses.
Instead, it saves an HMAC-derived digest. This provides a limited correlation signal for security purposes without retaining the original IP address as normal application data.
Device metadata is also intentionally limited.
Session security should help users recognize their devices without becoming an invasive tracking mechanism.
Legacy migration support
The existing frontend still contains API clients that expect a token in localStorage or use:
Authorization: Bearer
Removing this immediately would break existing routes and clients.
The migration is therefore divided into stages:
Persistent sessions and cookie support
```
          ↓
```
Rotating refresh tokens
```
          ↓
```
Centralized access-token renewal
```
          ↓
```
CSRF protection
```
          ↓
```
Cookie-only authentication
```
          ↓
```
Expiration of legacy browser tokens
```
          ↓
```
Strict server-session enforcement
```
          ↓
```
Removal of localStorage and bearer migration
An environment option is available for strict enforcement:
REQUIRE_SERVER_SESSION=true
It should only be activated after existing clients and legacy credentials have been migrated.
Testing the implementation
The focused authentication implementation currently passes:
Backend: 30/30 tests
Frontend: 12/12 tests
The React production build also completes successfully.
Real MongoDB integration coverage verifies the complete replay lifecycle:
Create persistent session
```
  ↓
```
Use current refresh token
```
  ↓
```
Rotate successfully
```
  ↓
```
Submit the old token again
```
  ↓
```
Reject the replay
```
  ↓
```
Revoke the server-side session
```
  ↓
```
Persist refresh-token-replay as the reason
The following authentication suites also pass in GitHub Actions:
tests/authSessionService.test.js
tests/authSessionController.test.js
tests/socialIdentityService.test.js
Repository-wide CI status
The complete repository pipeline is not yet green.
The latest full backend execution reported:
141 test suites passed
42 test suites failed

738 tests passed
44 tests failed
The failing tests mainly concern pre-existing behavior in:

Zorgax payments and payment intents;
Marketplace flows;
seller-membership policies;
older Metaverse authentication expectations;
Metaverse observability;
legacy source-code assertion tests.
The Security Audit and MYZ-164 policy workflows also remain red because of previously identified repository-wide conditions.
The new MYZ-71 session and refresh-token suites are green, but the pull request must remain a Draft until the wider baseline and the remaining authentication work are addressed.
What still needs to be implemented
Centralized access-token renewal
The frontend needs a shared API layer that can:
1. identify an expired access token;
2. call /api/auth/refresh;
3. retry the original request;
4. prevent simultaneous refresh calls;
5. redirect to login when renewal fails.
  Without a centralized implementation, individual pages may respond differently when the access token expires.
  CSRF protection
  Cookie-based authentication requires explicit protection for state-changing operations.
  The final design should combine appropriate controls such as:
origin validation;
CSRF tokens;
double-submit cookies;
carefully selected SameSite policies;
rejection of unsafe cross-origin requests.
SameSite=Lax should not be considered the only defence.
Removal of browser-stored tokens
The current frontend still updates the legacy localStorage token as a temporary compatibility bridge.
The final architecture should not expose reusable authentication credentials to frontend JavaScript.
Before removing localStorage, we must migrate:
every authenticated API client;
protected React routes;
realtime and websocket authentication;
mobile or embedded clients;
old sessions and legacy JWTs.
Passkeys and magic links
The MYZ-71 roadmap includes passwordless authentication based on flows such as:
/auth/start
/auth/verify
Passkey support will require correct WebAuthn management for:
relying-party configuration;
allowed origins;
challenge creation and expiration;
credential counters;
credential revocation;
account recovery.
Magic links will require short-lived, single-use verification tokens and replay protection.
Step-up authentication
Sensitive operations should require recent stronger verification.
Examples include:
changing the primary email;
changing a password;
registering or deleting passkeys;
deleting the account;
accessing wallet or payment functionality;
modifying high-impact Marketplace settings.
A valid session should not automatically authorize every sensitive action indefinitely.
Password-change session policy
The application must define what happens after a password change:
revoke every session;
keep only the current session;
allow the user to choose;
require step-up authentication.
This policy must be enforced on the server and tested with real session records.
Production OAuth validation
Google, GitHub and Facebook login still need production verification for:
exact callback URLs;
public frontend and API origins;
provider secrets;
redirect allowlists;
account-linking behavior;
missing-email cases;
cookie behavior across domains.
MongoDB Atlas validation
The production deployment must verify:
TTL-index creation;
refresh-token indexes;
cleanup of expired sessions;
document growth;
rolling-deployment compatibility;
session behavior under concurrent refresh requests.
Rate limiting
Authentication endpoints need dedicated abuse protection.
This includes limits for:
password login;
refresh requests;
password recovery;
magic-link generation;
WebAuthn challenge creation;
social-auth callbacks.
Security monitoring
Structured security events should be produced for:
login success and failure;
session creation;
session revocation;
remote device removal;
refresh-token replay;
password changes;
passkey registration;
suspicious authentication activity.
Logs must never contain passwords, raw access tokens, raw refresh tokens, OAuth authorization codes or provider secrets.
Recommended deployment sequence
The safest rollout order is:
1. review the Draft pull request;
2. deploy with legacy compatibility enabled;
3. verify MongoDB indexes;
4. validate cookies using the real public domains;
5. test login, refresh, logout and remote revocation;
6. execute a controlled refresh-token replay test;
7. implement centralized frontend renewal;
8. add and validate CSRF protection;
9. monitor session and replay events;
10. allow legacy credentials to expire;
11. activate strict server-session enforcement;
12. remove localStorage and legacy bearer authentication;
13. introduce passkeys, magic links and step-up authentication.
  Current progress
  Persistent server-side sessions DONE
  Session-bound JWT access tokens DONE
  Real logout DONE
  Active-device listing DONE
  Remote session revocation DONE
  Opaque rotating refresh tokens DONE
  Refresh-token replay detection DONE
  Password and social-login integration DONE
  Account-security interface DONE
  Focused backend and frontend testing DONE

Centralized access-token renewal PENDING
CSRF hardening PENDING
Cookie-only migration PENDING
Removal of localStorage authentication PENDING
Passkeys and magic links PENDING
Step-up authentication PENDING
Production OAuth validation PENDING
MongoDB Atlas production validation PENDING
Repository-wide green CI PENDING
Final thoughts
Secure authentication is not just about generating a token.
It requires a complete lifecycle:
Issue
Verify
Renew
Observe
Revoke
Recover
Monitor
MyZubster now has the foundation for persistent multi-device sessions, secure refresh-token rotation and automatic replay response.
The next major objective is completing the browser migration safely through centralized renewal, CSRF protection and the removal of JavaScript-accessible authentication credentials.
Only after those controls are validated should strict session enforcement be activated in production.
The current implementation can be reviewed in the Draft pull request:
https://github.com/danieldirimini-myzubster/myzubster/pull/10

Building MyZubster as a Verifiable AI Development Ecosystem

Tue, 22 Sep 2026 15:42:36 +0000

uilding MyZubster as a Verifiable AI Development Ecosystem: Metaverse, GitHub Evidence, Zorgax Knowledge, and DevelopmentRequest
Today we had the opportunity to present and demonstrate part of the MyZubster ecosystem during an institutional hearing.
Instead of presenting only slides or a conceptual roadmap, we showed the system directly. We opened the MyZubster metaverse, explained a real pilot involving an actual user, discussed how GitHub activity can become technical evidence, and described the architecture we are building around Zorgax, verified knowledge, software development, wallets, and human review.
The most important outcome for us was not the meeting itself.
It was realizing that the different components we have been building are starting to form a coherent technical system.
The architecture is moving toward this loop:
Real Person

↓

Real Activity

↓

Data / Evidence

↓

MyZubster

↓

Verified Knowledge

↓

Zorgax AI

↓

DevelopmentRequest

↓

Developer

↓

Code / GitHub

↓

Tests

↓

Independent Verification

↓

New Knowledge

↓

Identity / Wallet

↓

Metaverse Interaction
The goal is not simply to build another AI assistant, another marketplace, or another metaverse.
The goal is to connect all of these components around one principle:
AI can assist the process, but evidence and verification should remain inspectable.

The Metaverse Is Only the Interface
One of the things we demonstrated was the MyZubster metaverse.
For us, the metaverse is not the entire product.
It is one possible user interface for a much larger system.
The long-term idea is that a user should eventually be able to enter the environment with a digital identity, connect a wallet, interact with people or services, and have access to a history of technical contributions and activities.
That means the visible environment may look like a metaverse, but behind it we want something closer to a verifiable contribution graph.
A person may have:
Identity
↓
Wallet
↓
GitHub Account
↓
Issues
↓
Pull Requests
↓
Commits
↓
Tests
↓
Reviews
↓
Verified Contributions
The important distinction is that a wallet alone does not prove contribution.
A GitHub account alone does not prove contribution either.
What matters is the history of actions and the evidence attached to them.
A commit may be evidence.
A passing test may be evidence.
A reviewed pull request may be evidence.
A reproducible result may be evidence.
But none of these should automatically be interpreted as proof of everything.
That distinction becomes very important once AI is involved.
A Real Pilot: Nicola
We also presented a real pilot involving Nicola, one of the people testing and contributing to the ecosystem.
The first experiment was intentionally simple.
A physical kefir handover was performed and digitally recorded through MyZubster.
The workflow represented something like:
HAND_DELIVERY

↓

Receiver confirms receipt

↓

Status updated

↓

RECORDED
There was no payment involved.
The specific transaction was also not recorded as an on-chain blockchain transaction.
That is important because we do not want to describe the experiment as something it was not.
The purpose was not to scientifically validate kefir.
The purpose was to answer a much more technical question:
Can a real-world event be represented digitally in a way that produces useful evidence?

The answer was yes.
From there, Nicola also tested other parts of MyZubster, reported problems, and worked on his own software.
That gave us a more interesting participation model.
Instead of thinking about users as static roles, we can model participation as a progression:
User
↓
Tester
↓
Contributor
↓
Developer
↓
Evidence Producer
↓
Knowledge Contributor
This is one of the ideas that could eventually connect the metaverse, GitHub, wallets, community reputation, and Zorgax.
Zorgax: Chat Is Not Knowledge
One of the most important architectural decisions we have made recently concerns Zorgax.
We do not want to treat an AI-generated answer as verified knowledge.
That sounds obvious, but many systems effectively do exactly that.
A language model generates a response.
The response is stored.
Later the system retrieves that response as if it were truth.
That is dangerous.
So our architecture starts from a different assumption:
A message is not knowledge.

A message may contain useful information.
It may become a candidate for knowledge.
But it must go through additional stages.
Our conceptual flow looks like this:
User Question

↓

AI Response

↓

Candidate Information

↓

Sources

↓

Evidence

↓

Human / System Review

↓

Verified Knowledge
Only after that should the information become part of a trusted knowledge layer.
The Zorgax Knowledge Layer
We have been building a dedicated Knowledge Layer for Zorgax.
The knowledge model is designed to preserve more than just text.
A useful knowledge object needs context.
It may include concepts such as:
Knowledge
├── contributionId
├── title
├── content
├── contentHash
├── version
├── status
├── visibility
├── provenance
├── source
├── evidence
└── lineage
The contentHash is particularly important.
It gives us a deterministic identity for the canonical content.
If the content changes, the hash changes.
This allows downstream systems to know exactly which version of knowledge they are using.
For example, a development task may reference:
{
"contributionId": "ZK-123",
"contentHash": "f30c...",
"version": 3,
"title": "Metaverse Identity Architecture"
}
Later, the knowledge may evolve to version 4.
The development task should still be able to show:
This implementation was based on version 3.

That creates much better provenance.
Preview Before Persistent Writes
Another principle we implemented is:
The AI should not silently perform consequential writes.

For operations such as creating a DevelopmentRequest, the system first produces a preview.
Conceptually:
User Intent

↓

Normalized Input

↓

Knowledge Snapshot

↓

Preview

↓

Digest

↓

Explicit Confirmation

↓

Persistent Write
A digest is generated from the preview.
Then the user must confirm using a value such as:
CONFERMA DEV a1b2c3d4
If the preview changes, the digest changes.
If the digest does not match, the operation fails.
This prevents a situation where the user approves one thing and the system writes something different.
DevelopmentRequest: Turning Knowledge Into Work
The next architecture problem was:
How do we transform verified knowledge into software development?

Our solution is a new neutral object called DevelopmentRequest.
A DevelopmentRequest is not a bounty.
It is not a GitHub issue.
It is not a payment request.
It represents the work that needs to be done.
The current lifecycle is:
DRAFT
↓
OPEN
↓
IN_PROGRESS
↓
SUBMITTED
↓
VERIFIED
or:
SUBMITTED
↓
REJECTED
The model also supports cancellation.
Conceptually, the object contains:
DevelopmentRequest {
requestId
requestHash
createdBy

title
description

knowledgeRefs[]

requirements[]
acceptanceTests[]
evidenceRequired[]

status
assigneeId

submission
review

bountyReference // optional
}
The important part is that the development request is anchored to verified knowledge.
Snapshotting Knowledge
When a DevelopmentRequest is created, Zorgax does not simply store a knowledge ID.
It stores a snapshot reference.
For example:
knowledgeRefs: [
{

contributionId: "ZK-123",
contentHash: "abc123...",
version: 2,
title: "Verified Architecture"

}
]
Before the request is actually committed, the system revalidates those knowledge references.
If the underlying content has changed between preview and commit, the operation fails.
Conceptually:
if (
expected.contentHash !== current.contentHash ||
expected.version !== current.version
) {
throw new Error(

"Knowledge changed after preview"

);
}
This gives us something extremely useful:
development provenance.
We can eventually say:
Feature X
was implemented because of
DevelopmentRequest Y
which was based on
Knowledge Z version 2
which came from
Evidence A + Evidence B
That is much stronger than simply linking a GitHub issue to a random conversation.
Submission Is Not Verification
This is another important rule.
A developer may submit something.
That does not mean the work is verified.
So the workflow separates:
SUBMITTED
from:
VERIFIED
The contributor submits evidence such as:
{
"evidenceRefs": [

"test:integration:green",
"demo:https://..."

],
"commitRefs": [

"commit:abc123"

]
}
But a separate reviewer is responsible for verification.
The reviewer cannot be the creator or the assigned developer.
Conceptually:
if (
reviewer === request.createdBy ||
reviewer === request.assigneeId
) {
throw new Error(

"Review must be independent"

);
}
This is one of the foundations for future contribution reputation.
Strengthening the Evidence Model
We are now tightening this further.
The first implementation verified that evidence existed.
But that is not enough.
Imagine this DevelopmentRequest:
Evidence required:

Unit tests pass
Security review completed
Metaverse integration demonstrated
And the developer submits only:
commit:abc123
Technically, evidence exists.
But the required evidence is not actually satisfied.
So the stronger model connects each requirement to a specific reference.
For example:
{
"evidence": [ { "requirement": "Unit tests pass", "reference": "ci:test-run:4821" }, { "requirement": "Security review completed", "reference": "review:security:913" }, { "requirement": "Metaverse integration demonstrated", "reference": "demo:metaverse:42" } ]
}
Then the verification rule becomes:
VERIFIED
only if
every evidenceRequired item
has corresponding evidence
Conceptually:
const missingEvidence =
requiredEvidence.filter(
requirement =>
!coveredRequirements.has(requirement)
);

if (missingEvidence.length) {
throw new Error(

`Missing required evidence: ${missingEvidence.join(", ")}`

);
}
This may look like a small implementation detail.
It is not.
It changes the meaning of VERIFIED.
Without this rule:
VERIFIED = someone attached something
With this rule:
VERIFIED = the declared evidence requirements were actually covered
That is a much stronger guarantee.
DevelopmentRequest Is Not a Bounty
Another architectural decision we intentionally made was separating development from economics.
A DevelopmentRequest can exist without any reward.
That means:
Knowledge
↓
DevelopmentRequest
↓
Implementation
↓
Verification
can operate independently.
Then, optionally:
DevelopmentRequest
↓
Bounty
↓
Reward
↓
Settlement
may be attached later.
This distinction matters.
A university research project may not use bounties.
An open-source volunteer may contribute without payment.
A company may use fixed contracts.
A decentralized community may use tokens.
A marketplace may use fiat.
The technical work object should not care.
That is why the model contains only:
bountyReference: null
as an optional link.
The economics remain a separate subsystem.
GitHub as Evidence, Not Truth
GitHub is also important in the architecture, but we do not want to make the mistake of treating GitHub itself as truth.
A commit proves that a commit exists.
It does not automatically prove:
the feature works
the requirement is satisfied
the code is secure
the architecture is correct
the scientific result is valid
So GitHub becomes one evidence source among others.
Future DevelopmentRequest verification could combine:
GitHub commit
+
CI test result
+
integration test
+
human review
+
external evidence
This is also why we are working toward a Contribution Graph.
The graph can connect:
Developer
↓
Issue
↓
DevelopmentRequest
↓
Commit
↓
Pull Request
↓
Test
↓
Review
↓
Verified Contribution
That provides a much richer representation of technical reputation.
Where the Metaverse Fits Back In
At first glance, the metaverse and DevelopmentRequest may seem unrelated.
But they are actually part of the same architecture.
Imagine a person entering MyZubster.
The environment could eventually know:
Identity
Wallet
GitHub History
Verified Contributions
Knowledge Contributions
Development Activity
Community Activity
The user does not need to see all of this as raw database records.
The metaverse can become an interface for it.
For example, someone could enter a virtual lab or development room and interact with a project.
Behind the scene:
Metaverse Project

↓

DevelopmentRequest

↓

Verified Knowledge

↓

GitHub Repository

↓

Contributors

↓

Evidence
The virtual environment therefore becomes a way to navigate a real technical graph.
What We Demonstrated Today
During the hearing, we were able to connect several of these concepts in one presentation.
We demonstrated the MyZubster metaverse directly.
We explained Nicola's real-world pilot.
We discussed his AI-related development work.
We explained how user activity can evolve into testing and software contribution.
We described the role of GitHub history.
We explained Zorgax.
We described the difference between AI conversation and verified knowledge.
We presented our university outreach and the idea that scientific pilots require scientific methodology.
And we explained the broader direction:
People perform real activities, software records evidence, AI assists the process, developers build solutions, and independent verification creates new trusted knowledge.

Universities and Scientific Validation
We also discussed the academic side of the project.
We have started conversations with several universities and research groups around areas including AI, food science, fermentation, circular economy, environmental measurement, LCA/LCSA, and water reuse.
We are intentionally keeping the wording precise.
These are exploratory discussions.
They are not formal partnerships unless and until they are formally established.
The reason universities matter is structural.
MyZubster can build:
software
traceability
data collection
knowledge infrastructure
AI assistance
development workflows
evidence systems
But scientific validation requires additional layers:
scientific protocol
experimental design
control groups
measurement methodology
ethical assessment
statistical analysis
domain expertise
An AI system should not pretend to replace those responsibilities.
LIFE 2027 as a Possible Pilot Framework
We are also exploring whether some of these ideas could eventually fit into a LIFE 2027 project.
Again, this is an exploratory direction.
There is no approved or funded MyZubster LIFE project at this stage.
The interesting part for us is the possibility of connecting environmental pilots with the same verifiable architecture.
For example:
Circular Water Pilot

↓

Sensors / Data

↓

Evidence

↓

University Protocol

↓

Verified Knowledge

↓

Zorgax

↓

DevelopmentRequest

↓

Software Improvement
The same architecture could theoretically apply to fermentation, environmental monitoring, circular economy, Living Labs, or other pilot domains.
That is one reason we are trying to keep the core infrastructure domain-neutral.
The Broader Architecture
If we compress the whole system, the current direction looks like this:

                ┌──────────────────┐
                │    Real World    │
                └────────┬─────────┘
                         │
                         ▼
                ┌──────────────────┐
                │ Data / Evidence  │
                └────────┬─────────┘
                         │
                         ▼
                ┌──────────────────┐
                │ MyZubster        │
                │ Knowledge Layer  │
                └────────┬─────────┘
                         │
                         ▼
                ┌──────────────────┐
                │      Zorgax      │
                │   AI Assistant   │
                └────────┬─────────┘
                         │
                         ▼
                ┌──────────────────┐
                │DevelopmentRequest│
                └────────┬─────────┘
                         │
                         ▼
                ┌──────────────────┐
                │    Developer     │
                └────────┬─────────┘
                         │
                         ▼
                ┌──────────────────┐
                │ GitHub / CI      │
                └────────┬─────────┘
                         │
                         ▼
                ┌──────────────────┐
                │ Evidence Review  │
                └────────┬─────────┘
                         │
                         ▼
                ┌──────────────────┐
                │ Verified Result  │
                └────────┬─────────┘
                         │
                         ▼
                ┌──────────────────┐
                │  New Knowledge   │
                └────────┬─────────┘
                         │
                         ▼
                ┌──────────────────┐
                │ Identity/Wallet  │
                │ Metaverse Layer  │
                └──────────────────┘

This creates a feedback loop.
The output of development can become new knowledge.
That knowledge can generate new development requests.
Those development requests create more evidence.
The evidence can improve the knowledge layer.
What We Have Implemented So Far
At the technical level, the recent work includes:

a Zorgax Knowledge Layer with provenance, content hashing, versioning, visibility and evidence metadata;
explicit distinction between conversation, candidate information and verified knowledge;
fail-closed behavior for sensitive knowledge operations;
preview + digest + explicit human confirmation before persistent DevelopmentRequest creation;
snapshotting of Knowledge references using contentHash and version;
idempotent DevelopmentRequest creation;
a lifecycle covering DRAFT, OPEN, IN_PROGRESS, SUBMITTED, VERIFIED, REJECTED and CANCELLED;
contributor assignment;
submission of commit and evidence references;
independent review rules;
strict separation between DevelopmentRequest and bounty/payment systems;
integration points for future GitHub contribution tracking;
an evidence model being strengthened so every required evidence item must be satisfied before VERIFIED.
This is still evolving.
There are important areas we still want to improve, including stronger revision models, more precise evidence objects, route-level tests, better contribution graph integration, and stronger lineage across Knowledge revisions.
The Principle Behind the Architecture
The most important idea is probably this:
We are not trying to automate trust.

We are trying to make trust more inspectable.
AI can help generate code.
AI can help search.
AI can help organize knowledge.
AI can help transform requirements into development tasks.
AI can help developers.
But an AI response should not automatically become truth.
A commit should not automatically become proof.
A wallet should not automatically become reputation.
A submission should not automatically become verification.
The architecture should preserve the difference.
That is what we are trying to encode in the system itself.
What Comes Next
The next engineering steps are straightforward.
We want to finish the stronger DevelopmentRequest evidence invariant, integrate the workflow into the operational branch, and then continue toward the GitHub and Contribution Graph bridge.
After that, we want Zorgax to be able to move through a much richer development loop:
Question
↓
Verified Knowledge
↓
Architecture
↓
DevelopmentRequest
↓
Implementation
↓
Tests
↓
Independent Verification
↓
Delivery
↓
Optional Reward
↓
New Knowledge
At the same time, we will keep exploring how this architecture can work with real users, academic research, environmental pilots, and the MyZubster metaverse.
The meeting today was useful because we did not have to describe this only as an abstract roadmap.
We were able to show pieces of it working.
There is still a lot to build.
But the architecture is becoming increasingly clear.
Real people create activity. Activity creates evidence. Evidence can become verified knowledge. Knowledge can generate development. Development creates new evidence. AI assists the entire loop without becoming the sole authority.

That is the direction we are building toward with MyZubster and Zorgax.
MyZubster
Open Source • Verified Knowledge • AI-Assisted Development • GitHub Evidence • Metaverse • Digital Identity • Community

AI #OpenSource #SoftwareArchitecture #SoftwareDevelopment #GitHub #Metaverse #Web3 #KnowledgeGraph #ArtificialIntelligence #NodeJS #Developers #MyZubster #Zorgax

# MyZubster Is Becoming an Identity and Interaction Layer: Authentication → Zorgax → GitHub → Metave

Fri, 18 Sep 2026 10:04:10 +0000

MyZubster Is Becoming an Identity and Interaction Layer: Authentication → Zorgax → GitHub → Metaverse → NFTs

Over the last few months, MyZubster has changed significantly.

What started as an open-source ecosystem of experiments is beginning to converge around a much simpler entry point:

Authentication → Zorgax → Profile → GitHub → Interactions → Metaverse → Digital Assets

The interesting part isn't any single technology in that chain.

It's what happens when they share the same identity and evidence layer.

Authentication Is the Starting Point

When someone authenticates with MyZubster, we don't want the result to be just another empty account.

Authentication should become the beginning of a persistent ecosystem identity.

From there, the user can progressively connect:

a MyZubster profile;
interests and skills;
projects;
GitHub activity;
Marketplace activity;
knowledge and experiments;
Metaverse identity;
and, eventually, qualifying digital assets or NFTs.

This distinction matters:

Authentication proves access to an account.

It does not automatically prove every claim that appears in a profile.

Zorgax Helps Build the Profile

This is where Zorgax becomes useful.

Instead of presenting a new user with a huge registration form, Zorgax can help progressively construct the profile.

The conversation can start with simple questions:

Who are you?

What are you building?

What do you know?

What would you like to learn?

What can you contribute?

The architecture becomes:

USER → AUTH → ZORGAX → PROFILE

Zorgax can help organize the information, improve descriptions, identify missing information and connect the user to relevant parts of MyZubster.

But the human remains the source of the identity.

That's why we keep an important boundary:

HUMAN WORK ≠ AI ASSISTANCE ≠ VERIFIED EVIDENCE

Then GitHub Makes the Profile Inspectable

For developers and open-source participants, GitHub adds another dimension.

A person can move from saying:

I build software.

to linking actual public work:

PROFILE → REPOSITORY → ISSUE → COMMIT → PULL REQUEST → PROJECT

This is important for MyZubster because we don't want Zorgax to simply generate impressive biographies.

Where evidence exists, the profile should be able to point to it.

GitHub becomes part of the interaction graph.

MYZUBSTER IDENTITY ↔ GITHUB WORK ↔ ZORGAX

A project can then become discoverable through the person's profile and potentially through other MyZubster experiences.

The Same Identity Can Enter the Metaverse

Now things become more interesting.

The MyZubster identity doesn't have to stop at a web profile.

It can also represent the person inside the MyZubster Metaverse.

Imagine entering a digital space and meeting another avatar.

That avatar could connect back to:

PERSON
↓
MYZUBSTER PROFILE
↓
PROJECTS
↓
GITHUB
↓
KNOWLEDGE
↓
DOCUMENTED ACTIVITY

The Metaverse then stops being only a graphical chat environment.

It becomes another interface for discovering people, projects, communities and interactions.

GitHub + Metaverse Creates a New Kind of Interaction

This is one of the directions we're interested in exploring.

A developer contributes to an open-source project.

The contribution exists on GitHub.

The MyZubster profile references that work.

The same identity enters the Metaverse.

Other participants can discover the project.

That can lead to another contribution, collaboration, mission or community interaction.

The loop becomes:

GITHUB
↓
MYZUBSTER PROFILE
↓
METAVERSE
↓
HUMAN INTERACTION
↓
NEW PROJECT / CONTRIBUTION
↓
GITHUB

Now GitHub isn't isolated from the social environment around the project.

Where NFTs Become Interesting

This also changes how we think about NFTs.

Instead of starting with:

MINT NFT → TRY TO CREATE UTILITY

we can explore the opposite direction:

PARTICIPATE
↓
BUILD
↓
INTERACT
↓
DOCUMENT
↓
VERIFY WHEN POSSIBLE
↓
QUALIFY
↓
OPTIONAL NFT / DIGITAL ASSET

In that model, the NFT isn't necessarily the product.

It can become a digital artifact produced by an interaction.

For example, future assets could reference:

an open-source contribution;
a Metaverse event;
a creator collectible;
a completed mission;
a community artifact;
a documented project milestone;
or another qualifying MyZubster interaction.

That creates a potential distribution network for digital assets.

MyZubster Becomes the Connector

The architecture we're moving toward can be represented like this:

PERSON
↓
AUTHENTICATION
↓
MYZUBSTER IDENTITY
↓
ZORGAX
↓
PROFILE
↓
GITHUB + PROJECTS + KNOWLEDGE + MARKETPLACE
↓
INTERACTIONS
↓
EVIDENCE
↓
METAVERSE
↓
OPTIONAL NFT / DIGITAL ASSET

And then it loops.

A GitHub repository can bring somebody into MyZubster.

A MyZubster profile can bring somebody into the Metaverse.

A Metaverse interaction can create a new collaboration.

That collaboration can produce GitHub activity.

And a qualifying interaction could eventually generate a collectible or another digital asset.

The Important Part: Don't Confuse Identity With Evidence

Connecting all these systems also creates an obvious risk.

If we're not careful, a profile could appear to prove things that it doesn't actually prove.

So we're keeping these concepts separate:

IDENTITY ≠ CLAIM ≠ ACTIVITY ≠ EVIDENCE ≠ VERIFICATION ≠ NFT

Authentication doesn't prove expertise.

A GitHub account doesn't automatically prove that somebody authored everything connected to it.

Zorgax-generated text doesn't prove a claim.

A Metaverse interaction doesn't automatically prove a physical-world event.

And an NFT doesn't magically make its metadata true.

The architecture becomes more useful when those boundaries remain explicit.

What MyZubster Is Becoming

I used to think mostly about what features MyZubster should contain.

Now the more interesting question is:

What happens when identity, AI assistance, open-source work, digital interaction and verifiable artifacts become connected?

That's the direction we're exploring.

AUTHENTICATE
↓
MEET ZORGAX
↓
BUILD YOUR PROFILE
↓
CONNECT YOUR WORK
↓
ENTER THE METAVERSE
↓
INTERACT
↓
CREATE
↓
DOCUMENT
↓
DISTRIBUTE

MyZubster is gradually becoming less like a collection of separate applications and more like an identity and interaction layer connecting people, Zorgax, GitHub, the Metaverse and future digital assets.

And that's the next experiment we're building in public.

Build → Connect → Interact → Document → Verify → Distribute → Repeat

MyZubster #Zorgax #OpenSource #GitHub #Metaverse #NFT #DigitalIdentity #AIAgents #BuildInPublic

Building MyZubster World: The Metaverse Infrastructure We Have Implemented

Tue, 15 Sep 2026 16:59:49 +0000

Building MyZubster World: The Metaverse Infrastructure We Have Implemented
MyZubster is evolving from a marketplace into a circular digital ecosystem connecting verified identities, virtual communities, knowledge sharing, real-world projects, and privacy-conscious services.
The virtual layer of this ecosystem is called MyZubster World.
It is still experimental. We are not presenting it as a finished metaverse, but we have already implemented the technical foundations for identity, rooms, access control, invitations, scheduling, moderation, stage permissions, communication, and persistent progress.
This article explains what currently works and what we want to build next.
Explore MyZubster
These links include readable UTM parameters that can be monitored through Vercel Analytics.
Enter MyZubster World:
https://www.myzubster.com/metaverse?utm_source=coderlegion&utm_medium=article&utm_campaign=myzubster_metaverse_build&utm_content=enter_metaverse
Explore the marketplace:
https://www.myzubster.com/marketplace?utm_source=coderlegion&utm_medium=article&utm_campaign=myzubster_metaverse_build&utm_content=explore_marketplace
Learn how MyZubster works:
https://www.myzubster.com/come-funziona?utm_source=coderlegion&utm_medium=article&utm_campaign=myzubster_metaverse_build&utm_content=how_it_works
Explore the source code:
https://github.com/MyZubster-Ecosystem/myzubster?utm_source=coderlegion&utm_medium=article&utm_campaign=myzubster_metaverse_build&utm_content=github_repository
The architecture
MyZubster World currently uses:
React frontend

↓

Express API

↓

Authentication and authorization

↓

Metaverse services

↓

MongoDB persistence

↓

Vercel deployment and analytics
The frontend handles rendering, interaction, room controls, movement, forms, chat presentation, and user feedback.
The backend remains authoritative for:

Character identity
Room access
Session lifecycle
Private invitations
Capacity
Scheduling
Participant moderation
Stage permissions
Room chat
Message moderation
The browser can request an operation, but only the server can approve it.
Verified character identity
A name stored in localStorage cannot be treated as a verified identity because it can be modified through browser developer tools.
For authenticated users, the backend retrieves the canonical character from MongoDB:
const character = await MetaverseCharacter.findOne({
accountUserId: userId,
worldId: WORLD.id,
identityStatus: "account-linked"
});
The frontend replaces outdated local data with the server-provided identity.
MyZubster distinguishes between:
Guest character
└── Temporary and unverified

Account-linked character
└── Persistent and verified
A client-submitted character name, GitHub username, or MYZ-ID is never considered proof of identity.
Expired-session recovery
We implemented recovery for expired JWT sessions:
if (error.status === 401) {
localStorage.removeItem("myzubster-token");
setAuthenticated(false);
setMessage(

"Session expired. Please sign in again."

);
}
The interface can now recover from an invalid authentication state instead of repeatedly sending an expired token.
The login system also preserves private-room invitation URLs, allowing users to authenticate and return to the original invitation.
Persistent exploration progress
Verified characters can discover landmarks inside MyZubster World.
Progress is recorded server-side:
await MetaverseCharacter.findOneAndUpdate(
{

accountUserId: userId,
worldId: WORLD.id,
identityStatus: "account-linked"

},
{

$addToSet: {
  "missionProgress.visitedLandmarks":
    landmarkId
}

}
);
Using $addToSet prevents duplicate landmark records.
Progress survives browser refreshes, local-storage deletion, new sessions, and device changes.
Shared presence
The current world supports:

Player entry and exit
Online-character discovery
Position synchronization
Temporary chat
Emotes
Reconnection states
Presence expiration
The client retrieves shared state through an incremental synchronization request:
const result = await syncMetaverse(
sessionId,
cursor
);
The cursor allows the server to return only data that appeared after the previous synchronization.
Why polling is currently used
MyZubster runs in a serverless environment.
Long-lived in-memory connections can be unreliable when requests are distributed between stateless instances. A connection owned by one instance may not exist on another.
The current model uses MongoDB as shared state:
Client A ─┐
```
    ├── API instances ── MongoDB
```
Client B ─┘
This is a pragmatic solution for the current stage. A dedicated realtime infrastructure remains on our roadmap.
Server-authoritative rooms
MyZubster World supports persistent virtual rooms with a controlled lifecycle:
Draft
↓
Published
↓
Scheduled
↓
Live
↓
Ended
↓
Archived
Allowed transitions are defined on the server:
const ROOM_TRANSITIONS = {
draft: new Set(["published"]),
published: new Set([ "scheduled", "live" ]),
scheduled: new Set(["live"]),
live: new Set(["ended"]),
ended: new Set(["archive"]),
archive: new Set()
};
A modified client cannot move a completed room back into a live state.
Room access policies
Rooms support three access policies:
Public
Authenticated
Private
Public rooms can be discovered without authentication.
Authenticated rooms require a valid MyZubster account.
Private rooms require explicit authorization and are excluded from public room discovery.
Unauthorized requests receive a generic 404 response. This limits the amount of information revealed about private spaces.
Host controls
Room hosts can currently:
Create a room draft
Configure its access policy
Set capacity
Configure its stage policy
Select an optional session date
Publish the room
Create a session
Start the session
Cancel a scheduled session
End a live session
Generate and revoke private invitations
Remove or block participants
Restore blocked participants
Approve speaking requests
Revoke stage access
Delete room-chat messages
Every operation is verified on the backend:
function canManage(
actorUserId,
actorRole,
hostUserId
) {
return Boolean(
actorUserId &&
(
```
actorRole === "admin" ||
String(actorUserId) ===
  String(hostUserId)
```
)
);
}
Frontend button visibility is used for usability, not authorization.
Capacity controls
Hosts can configure a room capacity between 1 and 500 participants.
The server rejects values outside this range.
A new participant cannot enter a full room, while someone already registered in the session can reconnect without being counted again.
Capacity and other structural settings become locked once the session has been scheduled.
Secure private-room invitations
Private-room links are generated using cryptographically secure randomness:
const code = crypto
.randomBytes(24)
.toString("base64url");
The raw code is shown to the host only when created. The database stores its SHA-256 hash:
const hash = crypto
.createHash("sha256")
.update(code)
.digest("hex");
An invitation:
Expires after 24 hours
Can be redeemed once
Can be revoked immediately
Is replaced when a new invitation is created
Cannot override the blocklist
Survives the authentication redirect
Is never stored in plain text
Atomic invitation redemption
One-time invitations must remain one-time even when multiple requests arrive together.
The invitation is consumed through one conditional MongoDB operation:
const claimedRoom =
await VirtualRoom.findOneAndUpdate(
{
```
roomId,
accessPolicy: "private",
inviteTokenHash: suppliedHash,
inviteExpiresAt: {
  $gt: new Date()
},
blockedUserIds: {
  $ne: actorUserId
}
```
},
{
```
$addToSet: {
  allowedUserIds: actorUserId
},
$set: {
  inviteTokenHash: null,
  inviteExpiresAt: null
}
```
},
{
```
new: true
```
}
);
The same atomic operation checks the code, verifies expiration, checks the blocklist, authorizes the account, and destroys the invitation.
Only one concurrent request can succeed.
Privacy-conscious participant moderation
Hosts receive a participant list containing an opaque session reference, character name, and archetype:
{
"ref": "8af39a3d42b781b821003c14",
"characterName": "ExampleCharacter",
"archetype": "explorer"
}
Internal account IDs are not returned.
The opaque reference is scoped to a specific session:
function moderationParticipantRef(
sessionId,
userId
) {
return sha256(
${sessionId}:${userId}
).slice(0, 24);
}
Hosts can remove participants or remove and block them.
When a private-room participant is blocked, their authorization is also removed so they cannot immediately re-enter.
Blocklist management
Hosts can inspect blocked characters without receiving their internal account IDs.
Blocklist references are scoped to the room:
function blockedParticipantRef(
roomId,
userId
) {
return sha256(
blocklist:${roomId}:${userId}
).slice(0, 24);
}
The host can restore access for a selected character.
Unblocking does not automatically add the user back to a private room. The user must receive another valid invitation.
Moderated stage
Rooms can use two stage policies:
Host only
Host-approved speakers
In a host-approved room, a joined participant can request permission to speak.
The full workflow is:
Request access
```
↓
```
Host review
```
↓
```
Approve or reject
```
↓
```
Participant receives updated status
Participants can:
Request permission to speak
Cancel a pending request
Leave the stage voluntarily
Hosts can:
Inspect pending requests
Approve or reject requests
See current speakers
Revoke stage permission
Account IDs remain hidden throughout the process.
Session scheduling
Hosts can configure an optional date and time.
The browser converts the local date into an ISO timestamp:
const scheduledFor =
new Date(localValue).toISOString();
The server rejects invalid or past dates.
A session cannot start before the configured date, even if someone manually calls the API.
Rooms without a date can start immediately.
Safe cancellation
A scheduled session can be cancelled before starting.
Cancellation:
Archives the scheduled session
Returns the room to the published state
Restores access to its settings
Allows the host to correct and reschedule
Generates a lifecycle event
Starting and cancelling use conditional database updates. If both commands arrive simultaneously, only one can claim the scheduled state.
Automatic room synchronization
Room pages retrieve authoritative state every five seconds.
Without reloading, users can see:
Session start
Session cancellation
Participant-count changes
Their participation status
Session completion
Timeline updates
Cancelled sessions are excluded from current-session results. The latest completed session remains visible for timeline inspection.
Privacy-safe session history
The operational timeline can contain events such as:
session_created
session_started
participant_joined
participant_left
participant_removed
participant_blocked
stage_approved
stage_rejected
stage_left
stage_revoked
session_cancelled
session_ended
Public events contain aggregate data instead of participant IDs:
{
"type": "participant_joined",
"participantCount": 4,
"sequence": 12
}
Room-scoped chat
Each virtual session now has an isolated chat.
Chat access requires:
Authentication
Session membership or host capability
Absence from the room blocklist
Messages can be sent only while the session is live.
A public message contains:
{
"id": "message-id",
"characterName": "H4x0r",
"text": "Hello room",
"createdAt":
"2026-09-15T10:00:00.000Z"
}
Account, room, and internal session identifiers are omitted.
Messages are:
Sanitized
Limited to 280 characters
Rate-controlled
Retrieved incrementally
Deduplicated by the client
Rendered as text
Automatically deleted after 24 hours
Chat moderation
Hosts and administrators can remove individual messages.
Deletion is scoped to:
Message ID
- Session ID
- Room namespace
  An ID from another room cannot be used to delete its message through the current session.
  The frontend does not need the sender’s account ID.
  Connecting the metaverse to the marketplace
  MyZubster World is not intended to remain an isolated virtual experiment.
  It will become a visual entry point into marketplace areas such as:
Underground and alternative cultures
Kefir communities
Plant cultivation and documentation
University assistance
Creative collaboration
Privacy-conscious technology
The proposed ecosystem is circular:
Discover
↓
Learn
↓
Collaborate
↓
Exchange
↓
Document
↓
Share
↓
Discover again
A user could discover a community in the virtual world, enter its room, exchange knowledge, request help through the marketplace, and share the result with the same community.
What we still need to build
Dedicated realtime infrastructure
The current system uses polling. Future development should evaluate:
WebSockets
Managed realtime channels
Room-scoped broadcasts
Regional routing
Horizontal scaling
Reliable reconnection
Abuse protection
Immersive room scenes
Room authorization and lifecycle management are implemented, but entering a room does not yet launch a complete dedicated immersive scene.
The intended connection is:
Authorized session
```
 ↓
```
Short-lived room token
```
 ↓
```
Realtime room channel
```
 ↓
```
Immersive scene
Audio and video
Stage permissions are stored and enforced as application state, but they do not yet activate a production WebRTC transport.
This will require device permissions, speaker enforcement, network recovery, media infrastructure, and privacy documentation.
Message reporting
Hosts can delete messages, but participant reporting still needs:
Reason categories
Minimal evidence retention
Abuse prevention
Review procedures
Appeal policies
Stronger distributed rate limiting
The current chat uses a basic recent-message check.
Production hardening should introduce atomic distributed limits so concurrent requests cannot bypass the interval.
Marketplace destinations
The virtual world should eventually contain destinations connected to real marketplace information:
Neon Plaza
├── Underground Culture
├── Kefir and Cultivation
├── University Collaboration
├── Creators
└── Privacy Technology
Monero research
We are evaluating Monero for appropriate marketplace transactions.
A production integration still requires work on wallet architecture, payment verification, confirmations, refunds, exchange rates, accounting, security, and regulatory responsibilities.
It remains a research and development objective rather than a completed payment feature.
Monitoring this article with Vercel Analytics
All public links in this article use:
utm_source=coderlegion
utm_medium=article
utm_campaign=myzubster_metaverse_build
Each link has a separate utm_content value so traffic from different calls to action can be distinguished.
Authorized project members can inspect the results here:
https://vercel.com/myzubster/my-zubster-app/analytics
The Vercel dashboard is private. Readers should use the public MyZubster links.
Follow the project
Enter MyZubster World:
https://www.myzubster.com/metaverse?utm_source=coderlegion&utm_medium=article&utm_campaign=myzubster_metaverse_build&utm_content=final_metaverse_cta
Explore the marketplace:
https://www.myzubster.com/marketplace?utm_source=coderlegion&utm_medium=article&utm_campaign=myzubster_metaverse_build&utm_content=final_marketplace_cta
Learn how the ecosystem works:
https://www.myzubster.com/come-funziona?utm_source=coderlegion&utm_medium=article&utm_campaign=myzubster_metaverse_build&utm_content=final_how_it_works_cta
View the source code:
https://github.com/MyZubster-Ecosystem/myzubster?utm_source=coderlegion&utm_medium=article&utm_campaign=myzubster_metaverse_build&utm_content=final_github_cta
MyZubster World remains experimental, but it is becoming a server-authoritative platform with real identity, privacy, lifecycle, moderation, scheduling, and communication systems.
We are building it publicly, one verifiable layer at a time.
What should we implement next: immersive rooms, realtime infrastructure, participant reporting, or marketplace destinations?

Building MyZubster World: The Architecture We Have Implemented and What Is Still Missing

Tue, 15 Sep 2026 00:18:22 +0000

Building MyZubster World: The Architecture We Have Implemented and What Is Still Missing
MyZubster started as a marketplace, but our long-term vision is broader: we want to build a circular ecosystem connecting digital identity, virtual communities, knowledge sharing, real-world projects, and privacy-conscious transactions.
That vision is becoming MyZubster World, an experimental metaverse connected directly to the MyZubster marketplace.
This is not a post announcing a finished metaverse. It is a technical development log explaining what is already implemented, how the main components work, and what still needs to be built before the platform can offer a complete immersive experience.
The architecture
The current system is divided into several layers:
React frontend

↓

Express API

↓

Authentication and authorization

↓

Metaverse services

↓

MongoDB persistence

↓

Vercel deployment
The frontend renders the world, room controls, character state, marketplace destinations, and user feedback.
The backend remains authoritative for identity, access, room lifecycle, invitations, capacity, and session state. The browser can request an action, but it cannot declare that the action succeeded.
This distinction is important. Client-side controls can improve usability, but they cannot provide real security.
Verified character identity
One of the first problems we addressed was identity.
A character name stored only in localStorage is not a verified identity. Anyone can open the browser’s developer tools and change it.
For authenticated users, the backend now retrieves the character linked to the account:
const character = await MetaverseCharacter.findOne({
accountUserId: userId,
worldId: WORLD.id,
identityStatus: 'account-linked'
});
The server returns the canonical character profile:
{
"characterName": "H4x0r",
"identityStatus": "account-linked",
"archetype": "explorer",
"worldId": "neon-plaza"
}
The frontend replaces any stale local profile with this server-provided identity.
Guest identities remain possible, but they are explicitly treated as unverified:
const verified =
player.identityStatus === 'account-linked';
This gives us two distinct modes:
Guest → temporary and unverified
Account-linked character → persistent and verified
We do not treat a client-supplied name, GitHub username, or MYZ-ID as proof of identity.
Authentication recovery
We also implemented expired-session handling.
A common failure occurred when the frontend still contained an old JWT. The interface appeared authenticated, but protected API calls returned 401 Unauthorized.
The frontend now recognizes this state:
if (profileError.status === 401) {
localStorage.removeItem('myzubster-token');
setAuthenticated(false);
setMessage('Session expired. Please sign in again.');
}
This prevents the application from remaining trapped between authenticated and unauthenticated states.
The GitHub OAuth callback and production environment configuration were also reviewed so authenticated users can return to the metaverse after login.
Persistent mission progress
The metaverse includes landmarks that users can discover.
For authenticated characters, visited landmarks are recorded server-side:
await MetaverseCharacter.findOneAndUpdate(
{

accountUserId: userId,
worldId: WORLD.id,
identityStatus: 'account-linked'

},
{

$addToSet: {
  'missionProgress.visitedLandmarks': landmarkId
}

}
);
Using $addToSet prevents duplicate landmark entries.
This allows progress to persist across:

Browser refreshes
New sessions
Different devices
Local-storage deletion
Local state is still used for responsiveness, but MongoDB is the durable source of truth for verified accounts.
Shared presence
MyZubster World currently uses database-backed synchronization rather than a permanent WebSocket connection.
The frontend periodically sends the active session identifier:
const result = await syncMetaverse(
sessionId,
cursor
);
The server returns:
{
"players": [],
"messages": [],
"online": 0,
"cursor": "2026-09-15T00:00:00.000Z",
"transport": "shared-polling"
}
The current shared state supports:
Player presence
Position updates
Join and leave events
Chat messages
Emotes
Online-player counts
Reconnection states
The synchronization cycle is intentionally predictable:
const SYNC_INTERVAL_MS = 1800;
If a request temporarily fails, the frontend enters a reconnecting state and tries again instead of immediately removing the player.
Why we currently use polling
MyZubster is deployed in a serverless environment.
Long-lived connections can be unreliable when requests are distributed between stateless instances. An in-memory event stream on one server instance may not be visible to another instance.
For this reason, the current architecture favors shared persistence:
Client A ─┐
```
    ├── API instances ── MongoDB
```
Client B ─┘
This is less immediate than a dedicated realtime server, but it provides a coherent shared state during the experimental phase.
The older event-stream endpoint remains available for compatibility, but the current web client uses shared polling.
Presence expiration
Player presence must not remain online forever after a browser closes unexpectedly.
Presence records therefore include expiration timestamps:
{
lastSeenAt: Date,
expiresAt: Date
}
Each synchronization refreshes the expiration time. MongoDB’s expiration strategy removes abandoned presence records after their retention window.
This handles cases such as:
Closing the browser without pressing “Leave”
Losing the network connection
Browser crashes
Mobile operating systems suspending the tab
Chat and emotes
The current world includes temporary chat and emote actions.
Chat input is cleaned and limited before persistence:
const text = cleanText(req.body?.text, 280);

if (!text) {
return res.status(400).json({

success: false,
error: 'Message is empty'

});
}
Actions also use rate limits to reduce spam:
if (!allowAction(sessionId, 'chat', 700)) {
return res.status(429).json({

success: false,
error: 'Chat rate exceeded'

});
}
Chat history is intentionally temporary. It is not designed as permanent public content.
Production logging excludes message bodies, authorization headers, tokens, query strings, and session identifiers.
Server-authoritative virtual rooms
We have implemented persistent virtual rooms with an explicit lifecycle:
Draft
↓
Published
↓
Scheduled
↓
Live
↓
Ended
↓
Archived
The permitted transitions are represented on the backend:
const ROOM_TRANSITIONS = {
draft: new Set(['published']),
published: new Set(['scheduled', 'live']),
scheduled: new Set(['live']),
live: new Set(['ended']),
ended: new Set(['archive']),
archive: new Set()
};
A request attempting an invalid transition is rejected:
if (!ROOM_TRANSITIONS[room.state]?.has(nextState)) {
return {

valid: false,
status: 409,
error: `Invalid room transition`

};
}
The frontend cannot move a room from ended back to live, even if someone manually modifies the request.
Host permissions
Room-management actions verify the account on the server:
function canManage(
actorUserId,
actorRole,
hostUserId
) {
return Boolean(

actorUserId &&
(
  actorRole === 'admin' ||
  String(actorUserId) === String(hostUserId)
)

);
}
Only the room host or an administrator can:

Update room settings
Publish a room
Create a session
Start a session
End a session
Generate an invitation
Inspect invitation status
Revoke an invitation
Showing or hiding a button in React is not the authorization mechanism. Every operation is validated again by the backend.
Room access policies
Rooms currently support three policies:
accessPolicy: {
type: String,
enum: [ 'public', 'authenticated', 'private' ]
}
Public rooms
Public rooms can be discovered without authentication.
Authenticated rooms
These rooms require a valid MyZubster account.
Private rooms
Private rooms require explicit authorization.
Private rooms do not appear in the public discovery response:
function roomDiscoveryQuery(authenticated) {
return {
state: {
```
$in: ['published', 'scheduled', 'live']
```
},
accessPolicy: authenticated
```
? { $in: ['public', 'authenticated'] }
: 'public'
```
};
}
Even authenticated users cannot discover private rooms unless they have received access through the invitation system.
Unauthorized requests return a generic 404 response. This reduces information leakage about the existence of private spaces.
Room capacity
Hosts can configure room capacity between 1 and 500 participants.
The value is validated server-side:
const capacity = Number(input.capacity);

if (
!Number.isInteger(capacity) ||
capacity < 1 ||
capacity > 500
) {
return {

valid: false,
status: 400,
error: 'Capacity must be between 1 and 500'

};
}
When a session is full, new participants cannot join. An existing participant, however, can reconnect without being rejected as an additional person.
Room access and capacity become locked after session scheduling. This avoids changing fundamental rules while a session is already underway.
Session participation
The platform now supports:
Create session

↓

Start session

↓

Participant joins

↓

Participant leaves

↓

Host ends session
When joining, the backend checks:

Authentication
Session state
Room blocklist
Private-room authorization
Capacity
Existing participation
A simplified version of the logic looks like this:
if (session.state !== 'live') {
return deny('Session is not live');
}

if (room.blockedUserIds.includes(userId)) {
return deny('Access blocked');
}

if (
room.accessPolicy === 'private' &&
!room.allowedUserIds.includes(userId) &&
userId !== room.hostUserId
) {
return deny('Private room access denied');
}

if (
!alreadyJoined &&
participantCount >= session.capacity
) {
return deny('Session is at capacity');
}
Short-lived realtime tokens
After authorization, the backend can generate a short-lived token for future room-scoped realtime connections:
jwt.sign(
{

sub: userId,
purpose: 'metaverse-realtime',
sessionId: session.sessionId,
roomId: session.roomId,
sceneManifestVersion:
  session.sceneManifestVersion

},
secret,
{

expiresIn: '5m'

}
);
These tokens expire after five minutes.
The current room page does not pretend this token launches a complete immersive realtime client. That integration is still pending.
Privacy-safe session history
Room sessions produce technical events:

session_created
session_started
participant_joined
participant_left
session_ended
The frontend polls for new events using an incremental cursor.
Public event representations contain aggregate information, such as participant count, but do not expose participant account IDs.
{
"type": "participant_joined",
"participantCount": 4,
"sequence": 12
}
Events are retained temporarily and are presented as operational history, not permanent user tracking.
Private invitation links
The latest implementation makes private rooms practically accessible.
A host can generate an invitation code:
const code = crypto
.randomBytes(24)
.toString('base64url');
The raw code is returned once to the host. It is not stored in the database.
Instead, the backend stores a SHA-256 hash:
const hash = crypto
.createHash('sha256')
.update(code)
.digest('hex');
During redemption, the submitted code is hashed and compared using timingSafeEqual:
const valid =
expected.length === supplied.length &&
crypto.timingSafeEqual(expected, supplied);
The invitation:
Expires after 24 hours
Can be redeemed once
Can be revoked immediately
Is replaced when a new invitation is generated
Cannot override a blocklist
Survives the login redirect
Never exposes its stored hash through the status API
After successful redemption, the authenticated account is added to the room allowlist and the invitation is cleared.
Invitation management
An host can inspect only safe invitation metadata:
{
"active": true,
"expiresAt": "2026-09-16T00:00:00.000Z"
}
The response never includes:
The invitation code
Its hash
The invited user ID
The room blocklist
The host can revoke the invitation through an authenticated DELETE request:
DELETE /api/metaverse/rooms/:room/invitations
After revocation, the old link can no longer authorize a new account.
The connection with the marketplace
MyZubster World is not intended to remain separate from the marketplace.
The marketplace explores areas such as:
Underground and alternative subcultures
Kefir communities
Plant cultivation and documentation
University assistance
Creative and technical collaboration
Privacy-conscious services
Our proposed cycle is:
Discover
↓
Learn
↓
Collaborate
↓
Exchange
↓
Document
↓
Share
↓
Discover again
A user may discover a cultivation project inside the metaverse, join its community room, contribute knowledge, request assistance through the marketplace, and document the result for other members.
This is what we mean by a circular ecosystem: the virtual environment should lead to useful activity rather than functioning only as decoration.
What is still missing
The foundations are growing, but several important systems are not complete.
1. Immersive room connection
  The authorization and session layers exist, but entering a room does not yet launch a dedicated immersive scene.
  We still need to connect:
  Authorized room session
```
 ↓
```
  Short-lived realtime token
```
 ↓
```
  Room-specific transport
```
 ↓
```
  Immersive scene
  The scene must preserve the same access, capacity, and moderation rules enforced by the API.
2. Dedicated realtime transport
  Database polling is appropriate for the current prototype, but larger rooms will require a dedicated realtime service.
  We need to evaluate:
WebSockets
Managed realtime infrastructure
Horizontal scaling
Reconnection strategies
Presence consistency
Regional latency
Abuse protection
The migration should be driven by measurements, not by the assumption that WebSockets are automatically better.
1. Participant moderation
  Hosts need privacy-conscious moderation tools.
  The roadmap includes:
Removing a participant
Blocking future access
Restoring access
Revoking private-room membership
Recording moderation events
Preventing immediate unauthorized re-entry
We must provide these controls without publishing internal account identifiers.
1. Stage requests
  Rooms already contain a stage policy:
  stagePolicy: {
  type: String,
  enum: [ 'host-only', 'host-approved' ]
  }
  However, the complete interaction is not yet implemented.
  The intended flow is:
  Participant requests to speak
```
    ↓
```
  Host reviews the request
```
    ↓
```
  Host approves or rejects
```
    ↓
```
  Server assigns stage capability
```
    ↓
```
  Capability expires or is revoked
2. Room-specific chat
  The global prototype supports chat, but room-scoped communication still needs stronger boundaries.
  Messages should be associated with:
A room
A session
An authorized participant
A defined retention policy
Moderation state
1. Marketplace destinations
  Marketplace categories currently need a deeper connection with the virtual world.
  Our plan is to turn categories into interactive destinations:
  Neon Plaza
  ├── Underground Culture
  ├── Kefir and Cultivation
  ├── University Collaboration
  ├── Creators
  └── Privacy Technology
  Each destination should load real marketplace information rather than static decorative content.
2. Collaborative activities
  The long-term experience should support useful interaction:
Workshops
Study sessions
Community presentations
Cultivation journals
Project showcases
Mentoring
Marketplace demonstrations
These activities still require data models, permissions, interfaces, and moderation rules.
1. Automated testing
  We have policy and interface-wiring tests, but the project still needs broader coverage:
Integration tests with MongoDB
Authentication tests
Invitation race-condition tests
Capacity concurrency tests
OAuth callback tests
Browser end-to-end tests
Accessibility tests
Load testing
One particularly important case is simultaneous redemption of a monouso invitation. The final production implementation should use an atomic database update so two requests cannot consume the same code at nearly the same time.
1. Monitoring
  The application uses Vercel Analytics and deployment observability, but product-specific monitoring needs to improve.
  We want to measure:
Metaverse entry funnel
Successful authenticated joins
Room creation
Session starts
Invitation redemption
Marketplace transitions
Reconnection frequency
API errors and latency
Analytics events must remain privacy-conscious and avoid collecting unnecessary identity or message data.
1. Accessibility and mobile interaction
  The metaverse must remain usable outside a desktop keyboard environment.
  We still need:
Touch controls
Keyboard navigation
Reduced-motion support
Screen-reader labels
High-contrast states
Responsive room controls
Accessible chat
Performance testing on low-end devices
1. Monero research
  We are evaluating Monero as a possible payment option for appropriate marketplace transactions.
  A production integration still needs research and implementation for:
Wallet architecture
Payment verification
Unique payment identification
Confirmation policies
Refunds
Disputes
Exchange-rate handling
Accounting
Regulatory responsibilities
Secret management
Operational security
Monero payment support should therefore be considered a roadmap item, not a finished production feature.
How we are building
We are developing MyZubster through small, reviewable increments.
Recent pull requests introduced:
Persistent mission progress
Canonical character identity
Expired-JWT recovery
Filtered room discovery
Authoritative room details
Room lifecycle management
Join and leave controls
Private-room authorization
Privacy-safe session events
Host room settings
Secure invitation links
Invitation status and revocation
This approach lets us review each security and privacy boundary before adding more visual complexity.
The infrastructure underneath the world may be less visible than a 3D animation, but it determines whether the final experience can be trusted.
Explore MyZubster
Enter MyZubster World
Explore the Marketplace
Learn how MyZubster works
View the source code
MyZubster World is still experimental, but its identity, access, lifecycle, invitation, persistence, and privacy foundations are now taking shape.
We are building it publicly, one verifiable layer at a time.
What would you implement next: immersive rooms, realtime transport, marketplace destinations, or host moderation?

Building MyZubster: A Circular Marketplace Connected to a Social Metaverse

Mon, 14 Sep 2026 12:43:38 +0000

Building MyZubster: A Circular Marketplace Connected to a Social Metaverse
MyZubster is an open-source ecosystem that connects a circular marketplace, local communities, educational support, underground culture, visual storytelling and an experimental social metaverse.
The project is based on a cyclical model:
Discover → Connect → Exchange → Use → Learn → Repair → Reuse → Recover → Contribute
Instead of building another isolated marketplace or virtual world, MyZubster connects these activities through shared navigation, account-linked characters and measurable user journeys.
The MyZubster Marketplace
The Marketplace is the operational discovery layer of the ecosystem. It organizes products, services, skills and community activities into accessible categories and subcategories.
The current demo explores areas including:

local food and independent producers;
kefir and fermented products;
underground music and alternative culture;
sound-system equipment;
event and creative services;
university and educational assistance;
programming and digital services;
repair and reuse;
recycling and material recovery;
sustainable everyday products.
Explore the Marketplace:
🛒 https://www.myzubster.com/marketplace?utm_source=coderlegion&utm_medium=article&utm_campaign=myzubster_circular_funnel&utm_content=marketplace_overview
Why Kefir Is Part of the Ecosystem
Kefir is a useful example of how a small local product can become part of a larger circular process.
A visitor can discover a producer, learn about the production process, contact the seller and understand what happens to the packaging after consumption.
Local production
↓
Marketplace discovery
↓
Informed purchase
↓
Consumption
↓
Container reuse
↓
Recycling or material recovery
MyZubster does not automatically certify food safety, production standards or health benefits. Those claims require evidence and compliance from the responsible producer.
The platform’s role is to make sellers, information and provenance easier to discover and inspect.
Open the local-products Marketplace funnel:
🌱 https://www.myzubster.com/marketplace?category=food&utm_source=coderlegion&utm_medium=article&utm_campaign=myzubster_circular_funnel&utm_content=kefir_local_producers
Supporting Underground and Independent Culture
Underground communities often depend on informal networks connecting musicians, artists, technicians, venues and equipment owners.
MyZubster can provide optional infrastructure for discovering:
DJs, musicians and independent performers;
sound-system equipment;
audio repair specialists;
rehearsal and event services;
visual artists and graphic designers;
alternative clothing and records;
independent venues and cultural initiatives;
reusable creative materials.
A sound system can move through a complete circular lifecycle:
Equipment discovery
↓
Purchase or rental
↓
Event use
↓
Maintenance
↓
Repair
↓
Resale and reuse
↓
Component recovery
The objective is not to control underground culture. It is to give independent communities tools they can use on their own terms.
Explore the underground and sound-system funnel:
🔊 https://www.myzubster.com/marketplace?category=sound-system&utm_source=coderlegion&utm_medium=article&utm_campaign=myzubster_circular_funnel&utm_content=underground_sound_system
University and Educational Assistance
Education is another important part of the MyZubster cycle.
Students can discover legitimate support such as:
tutoring;
programming guidance;
language practice;
research-method explanations;
document and presentation formatting;
portfolio support;
study groups;
guidance toward internships;
open-source contribution opportunities.
Educational support should help students learn. It must not be used to impersonate students, complete prohibited examinations or submit deceptive academic work.
The educational cycle is:
Ask for support
↓
Learn
↓
Practise
↓
Build a project
↓
Document the work
↓
Contribute
↓
Help another learner
Explore the educational Marketplace funnel:
🎓 https://www.myzubster.com/marketplace?category=education&utm_source=coderlegion&utm_medium=article&utm_campaign=myzubster_circular_funnel&utm_content=university_help
Entering the MyZubster Metaverse
The MyZubster Metaverse is the visual and social navigation layer of the ecosystem.
Its current environment, Neon Plaza, allows visitors to:
enter as guests or authenticated users;
use account-linked characters;
move around a shared environment;
see other active visitors;
communicate through chat and emotes;
discover nearby participants;
visit ecosystem portals;
complete an exploration mission;
preserve visited-zone progress;
discover experimental virtual rooms.
Enter Neon Plaza:
🪐 https://www.myzubster.com/metaverse?utm_source=coderlegion&utm_medium=article&utm_campaign=myzubster_circular_funnel&utm_content=metaverse_entry
Account-Linked Characters
A visitor can explore without creating a verified identity claim.
Authenticated users can use persistent account-linked characters. The server determines which character belongs to the authenticated account instead of trusting a name supplied by the browser.
The current system includes:
canonical server-side character profiles;
account-linked character ownership;
authenticated profile retrieval;
server-backed mission progress;
visited-zone persistence;
live player presence;
session recovery;
expired-JWT handling;
protected character-progress updates.
A display name is not considered legal identity evidence. The MYZ VERIFIED label indicates that the character is linked to a MyZubster account, not that a person’s legal identity, professional skills or qualifications have been certified.
Mission Progress
Visitors receive an initial mission: move through Neon Plaza and reach one of its portals.
For guests, progress remains local to the browser. For authenticated characters, visited zones can be stored on the account-linked server profile.
The server accepts only known landmark identifiers. It derives character ownership from the verified authentication token and does not trust a character name submitted by the client.
This creates a safer progression model:
Authenticated account
↓
Canonical character
↓
Visit a valid landmark
↓
Server validates the landmark
↓
Progress is attached to the account-owned character
Try the mission funnel:
🧭 https://www.myzubster.com/metaverse?utm_source=coderlegion&utm_medium=article&utm_campaign=myzubster_circular_funnel&utm_content=first_mission
Experimental Virtual Rooms
MyZubster is beginning to connect Neon Plaza with persistent virtual rooms.
The discovery system applies access rules on the server:
guests can discover public rooms;
authenticated users can also discover account-only rooms;
private rooms remain hidden;
drafts and archived rooms are excluded;
only published, scheduled or live spaces are discoverable.
These rooms are still experimental. A dedicated room experience will be introduced only after navigation, access control, moderation and lifecycle handling are ready.
Follow the virtual-room funnel:
🏛️ https://www.myzubster.com/metaverse?utm_source=coderlegion&utm_medium=article&utm_campaign=myzubster_circular_funnel&utm_content=virtual_rooms
MyZubster Visual
MyZubster Visual provides the storytelling layer.
Illustrations, interactive popups and visual narratives can explain connections between:
physical products;
circular lifecycles;
environmental projects;
characters;
community contributions;
Marketplace categories;
Metaverse destinations.
A popup can introduce a story, provide additional context and direct a visitor toward the next relevant part of the ecosystem.
The intended funnel is:
Visual story
↓
Interactive popup
↓
Context and explanation
↓
Marketplace category or project
↓
Metaverse exploration
↓
Community participation
Explore the visual-story funnel:
🎨 https://www.myzubster.com/fumetto?utm_source=coderlegion&utm_medium=article&utm_campaign=myzubster_circular_funnel&utm_content=visual_popups
How the Complete Circular Funnel Works
Consider a visitor interested in locally produced kefir:
1. They discover MyZubster through this article.
2. They open the Marketplace.
3. They explore local food and producer listings.
4. They learn about the product and its provenance.
5. They contact or purchase from an authorized seller.
6. They reuse or correctly recycle the packaging.
7. They enter the Metaverse.
8. They visit the Marketplace or LIFE Projects portal.
9. They document or share a useful contribution.
10. That contribution helps another visitor discover the circular pathway.
  The same model can apply to underground sound equipment:
11. Discover equipment.
12. Use it for an event.
13. Maintain and repair it.
14. Resell or reuse it.
15. Recover components at the end of its usable life.
16. Share repair knowledge with the community.
  It can also apply to educational support:
17. Request tutoring.
18. Learn a skill.
19. Build a project.
20. Publish the code.
21. Contribute to MyZubster.
22. Help another learner.
  Technical Architecture
  The current implementation combines:
React for the user interface;
Node.js and Express for backend services;
MongoDB for persistent characters, progress and room records;
authenticated API routes;
server-authoritative access rules;
short-lived presence and chat records;
GitHub for open-source development;
Vercel for deployment and web analytics.
The architecture maintains an important boundary:
The client presents the experience, but the server controls identity, ownership, persistence and access decisions.
Measuring the Funnel
Each link in this article contains UTM parameters designed to distinguish traffic from Coder Legion.
The campaign uses:
utm_source=coderlegion
utm_medium=article
utm_campaign=myzubster_circular_funnel
The utm_content value identifies the selected journey:
marketplace_overview
kefir_local_producers
underground_sound_system
university_help
metaverse_entry
first_mission
virtual_rooms
visual_popups
github_repository
This makes it possible to compare which concepts attract attention and which destinations visitors choose next.
Build With Us
MyZubster is being developed openly. Developers can inspect the implementation, review the architecture, propose improvements and contribute code.
💻 https://github.com/MyZubster-Ecosystem/myzubster?utm_source=coderlegion&utm_medium=article&utm_campaign=myzubster_circular_funnel&utm_content=github_repository
The project remains an evolving prototype. Experimental functionality, verified evidence and operational services are kept clearly distinguishable.
The objective is not simply to create another marketplace or virtual environment. It is to build a connected system in which software helps communities discover opportunities, learn, exchange value, extend product lifecycles and create new contributions.
Explore the Ecosystem
🛒 Marketplace Demo
https://www.myzubster.com/marketplace?utm_source=coderlegion&utm_medium=article&utm_campaign=myzubster_circular_funnel&utm_content=marketplace_overview
🪐 MyZubster Metaverse
https://www.myzubster.com/metaverse?utm_source=coderlegion&utm_medium=article&utm_campaign=myzubster_circular_funnel&utm_content=metaverse_entry
🎨 MyZubster Visual
https://www.myzubster.com/fumetto?utm_source=coderlegion&utm_medium=article&utm_campaign=myzubster_circular_funnel&utm_content=visual_popups
💻 Open-source Repository
https://github.com/MyZubster-Ecosystem/myzubster?utm_source=coderlegion&utm_medium=article&utm_campaign=myzubster_circular_funnel&utm_content=github_repository
MyZubster #OpenSource #WebDevelopment #Metaverse #Marketplace #CircularEconomy #ReactJS #NodeJS #MongoDB #BuildInPublic

Building MyZubster in Public: From Visual Storytelling to an Interactive Metaverse

Sun, 13 Sep 2026 00:23:59 +0000

Building MyZubster in Public: From Visual Storytelling to an Interactive Metaverse

MyZubster has recently evolved from a collection of open-source repositories and visual concepts into a more connected, interactive, and measurable ecosystem.

Our latest development cycle focused on five areas:

visual content and videos;
the MyZubster comic;
the Darkode historical page;
Neon Plaza and character onboarding;
the collaboration with Nicola and his N4K48 character.

This is a technical overview of what we built, what is live, and what still remains experimental.

Visuals as part of the product

We created and organized new images, comic panels, and videos related to:

MyZubster;
Zorgax;
Neon Plaza;
the Space Station;
circular economy;
environmental pilot concepts;
characters and community contributors;
the cultural history represented by Darkode.

These assets are not treated only as marketing material. They help us describe the ecosystem, explain future product directions, and connect technical components with a shared narrative.

However, we maintain a strict distinction between:

narrative representation;
prototype;
implemented feature;
production deployment;
verified result.

A visual may describe a future interface or environment without implying that every depicted feature is already available.

The MyZubster comic

The comic has become one of the main narrative interfaces of the project.

It connects characters, software components, environmental projects, digital culture, and MyZubster’s broader vision.

The public comic gallery is available at:

https://www.myzubster.com/fumetto

The comic currently includes themes such as:

the city as a living organism;
Zorgax as an ecosystem guide;
Neon Plaza;
the Space Station;
community and bot networks;
circular economy;
digital identity;
early online-community culture.

The comic is narrative content, not technical evidence. Claims about features, deployments, contributors, or results must still be supported by source code, commits, documentation, or other verifiable evidence.

Darkode as a digital memory layer

We also created a public Darkode page:

https://www.myzubster.com/darkode

Darkode documents part of the cultural and personal history behind MyZubster.

Instead of presenting every historical element as a verified fact, the page separates:

documented information;
personal recollections;
archived material;
narrative interpretation;
details still requiring verification.

This gives MyZubster a digital memory layer without turning incomplete evidence into definitive claims.

The page has also been connected to the main website navigation, making it discoverable from the homepage.

Neon Plaza: guest access before registration

A major problem with many Metaverse experiences is onboarding friction.

Users are often asked to create an account, connect a wallet, or install software before they understand what the experience provides.

We changed that flow.

Neon Plaza is now accessible as a guest:

https://www.myzubster.com/metaverse

A visitor can:

select a public display name;
automatically create a guest character;
enter without registering;
enter without connecting a wallet;
use the experience without a VR headset;
move with the arrow keys or WASD;
use chat and emotes;
encounter other active characters;
reach portals connected to MyZubster services.

The homepage now uses a more direct call to action:

Enter Neon Plaza — try it without registering

The goal is to let users experience the product before asking them to create an account.

Introducing a first mission

A digital world without an immediate objective can feel empty, even when several features are available.

We therefore added a simple onboarding mission:

Move your character and reach one of Neon Plaza’s glowing portals.

This provides an immediate interaction and helps users understand how the environment works.

The current journey is:

visit the homepage;
enter Neon Plaza as a guest;
create a character;
start the first mission;
reach a portal;
complete the mission;
receive an invitation to verify the character;
register to preserve progress.

The first mission converts passive traffic into a measurable product interaction.

Character verification

After completing the mission, guest users see a new action:

Verify your character

In MyZubster, a verified character is a character connected to a recognized account.

This does not mean:

legally verified identity;
certified professional skills;
automatic rewards;
ownership of third-party materials;
authorization to publish personal information.

Additional public information requires separate consent.

An account-linked character can provide:

persistent progress;
a reusable public character name;
personal missions;
links to authorized contributions;
recognizable participation in the ecosystem.

This approach allows us to increase trust without overstating what technical account verification proves.

Nicola and N4K48

One of our current experiments involves Nicola and his character, N4K48.

Using AI-assisted creative tools, Nicola produced three new comic panels:

“From a Software Idea to the Metaverse”;
“The Software Takes Shape”;
“Towards Neon Plaza.”

The panels describe his journey from a software idea to a possible presence inside the MyZubster Metaverse.

They are available in Nicola’s public repository:

https://github.com/nicolaususnicola-lgtm/myzubster-mvp/tree/main/docs/n4k48-comics

The panels have been connected to his N4K48 profile and project documentation.

Previously existing MyZubster comics remain external references. They are not attributed to Nicola.

This distinction helps keep authorship, provenance, and project context separate.

Preparing an NFT candidate without pretending it has been minted

Nicola proposed the first panel, “From a Software Idea to the Metaverse,” as a potential NFT candidate.

No mint has been executed.

At the moment:

no blockchain has been selected;
no wallet has been registered for the operation;
no smart contract has been selected or deployed;
no token ID exists;
no transaction hash exists.

Instead of immediately minting the image, we created a preliminary provenance and rights-review document.

The draft pull request is available here:

https://github.com/nicolaususnicola-lgtm/myzubster-mvp/pull/14

The review process covers:

authorship confirmation;
the AI tool and creative process used;
the original source file;
manual modifications;
third-party assets and fonts;
applicable licenses;
authorization to use MyZubster elements;
commercial terms and royalties;
Nicola’s explicit final authorization.

The current status is:

Ready for rights review — not ready to mint.

This evidence-first approach prevents documentation from presenting a planned blockchain operation as an already completed result.

Measuring the conversion funnel

We also introduced product analytics for the new user journey.

Facebook is currently an important discovery source, so we are measuring this funnel:

Facebook → homepage → Neon Plaza → mission → character verification → registration

The events include:

metaverse_cta_clicked
metaverse_loaded
first_interaction
mission_started
mission_completed
character_verification_started
character_verification_completed
signup_start
signup_completed
contact_request
pilot_interest

These events let us distinguish between visitors who:

only view the homepage;
open Neon Plaza;
interact with the experience;
begin a mission;
complete a mission;
begin character verification;
complete registration;
express interest in a pilot;
request contact.

Traffic alone does not tell us whether the product is producing meaningful engagement.

The objective is to identify where users abandon the journey and improve each transition independently.

What we learned

The main lesson from this iteration is that adding more features does not automatically create a stronger ecosystem.

The different layers need to reinforce one another:

videos generate discovery;
comics provide narrative context;
Darkode preserves cultural memory;
Neon Plaza creates an interactive experience;
Zorgax guides the user;
missions provide immediate objectives;
character verification supports continuity;
analytics measures actual behavior;
documentation protects provenance and accuracy.

The collaboration with Nicola and N4K48 also demonstrates the importance of working with real contributors while keeping authorship, consent, implementation status, and evidence clearly separated.

Next steps

Our next priorities are:

complete the provenance and rights review for the N4K48 NFT candidate;
improve character onboarding;
reduce abandonment between mission completion and registration;
make active characters and missions more visible;
connect the comic, Metaverse, Marketplace, and environmental pilots;
use analytics to validate changes;
publish only results supported by evidence.

MyZubster remains an open-source ecosystem built in public.

The goal is not to present a future vision as a finished product. The goal is to document each experiment, verify each result, and progressively transform ideas, visits, and community contributions into usable technology.

Project links

MyZubster:

https://www.myzubster.com

GitHub:

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

Neon Plaza:

https://www.myzubster.com/metaverse

Darkode:

https://www.myzubster.com/darkode

Comic:

https://www.myzubster.com/fumetto

N4K48 comic gallery:

https://github.com/nicolaususnicola-lgtm/myzubster-mvp/tree/main/docs/n4k48-comics

Building the Realtime Foundation of the MyZubster Metaverse

Wed, 09 Sep 2026 00:12:26 +0000

Building the Realtime Foundation of the MyZubster Metaverse

We are upgrading the MyZubster Metaverse from a REST-synchronized experience into an authenticated realtime multiplayer environment.

Before continuing with the next development phase, here is a transparent update on what is already working and what we are implementing next.

From polling to realtime communication

The first version of the Metaverse uses REST endpoints to manage:

player sessions;
character movement;
shared presence;
chat messages;
emotes;
verified identities;
world synchronization.

This gave us a reliable starting point, but periodic polling is not the final architecture we want for a persistent shared world.

We have now introduced a Socket.IO gateway mounted at:

/realtime

It supports WebSocket communication with HTTP polling available as a compatibility fallback.

The preview runtime is online

The realtime infrastructure has been deployed to an isolated Vercel preview environment.

We verified it using the public health endpoint:

GET /api/realtime/health

The current response is:

{
  "success": true,
  "status": "ok",
  "transport": "socket.io",
  "socketPath": "/realtime",
  "presence": "local-fallback",
  "privacy": "aggregate-only"
}

This confirms that the application is running, Socket.IO is attached correctly, the preview database is reachable, and observability is configured to avoid exposing private user data.

Secure realtime authentication

Clients cannot connect anonymously to protected realtime features.

An authenticated user first requests a short-lived token from:

POST /api/realtime/token

The server creates a dedicated JWT containing only the information required by the realtime gateway.

The gateway verifies:

signature and expiration;
issuer and audience;
realtime-specific purpose;
user identity;
user role.

Authentication alone does not grant access to every channel. Each subscription is authorized independently by the server.

Every user also receives a private channel:

user:<userId>

This provides a controlled foundation for private notifications and direct message delivery.

Presence, messaging, and reconnects

The new gateway already supports the core operations required by a multiplayer environment:

presence.join
presence.heartbeat
presence.leave
channel.subscribe
channel.unsubscribe
chat.send
realtime.resume

When a client reconnects, it can request restoration of its previous subscriptions. The server verifies every channel again before restoring access.

Messages are validated, persisted, deduplicated, and delivered only to authorized recipients.

We also added backpressure controls so the service can reject excess work safely during temporary overload.

Preview database isolation

The preview deployment does not reuse unrestricted production credentials.

We created:

a dedicated MongoDB preview user;
a custom least-privilege role;
access limited to the preview database;
cluster-level restrictions;
encrypted Vercel environment variables;
branch-specific configuration.

The MongoDB URI and realtime signing secret are never committed to GitHub or exposed to frontend code.

Privacy-aware observability

Realtime systems need monitoring, but operational visibility should not become user surveillance.

Our observability layer collects aggregate technical information such as:

connection attempts;
successful and rejected connections;
active connections;
disconnects;
message failures;
duplicate messages;
resume operations;
processing duration;
Redis failures.

Private conversations and raw personal identifiers are not included in public metrics.

The detailed metrics endpoint is restricted to authenticated administrators.

Why presence is still using a fallback

The health response currently reports:

presence: local-fallback

This means presence works inside the active application instance, but it is not yet coordinated across multiple Vercel instances.

It is an important distinction: the realtime runtime is operational, but distributed presence is still the next step.

Redis will provide:

shared presence state;
cross-instance Socket.IO delivery;
instance coordination;
presence expiration;
better horizontal scaling.

What we are working on next

Our next development phase is focused on:

connecting the Metaverse frontend to Socket.IO;
keeping REST synchronization as a temporary fallback;
introducing the Socket.IO Redis adapter;
configuring an isolated preview Redis instance;
testing multiple simultaneous clients;
verifying disconnect and resume behavior;
validating privacy-safe metrics;
completing the production review and merge.

Current project status

Realtime server: implemented
Vercel preview: online
MongoDB connection: verified
Health endpoint: verified
Socket authentication: implemented
Channel authorization: implemented
Presence lifecycle: implemented
Reconnect support: implemented
Aggregate observability: implemented
Frontend Socket.IO connection: in progress
Distributed Redis coordination: next
Production release: pending validation

Building a world, not just a page

The MyZubster Metaverse is intended to become a shared digital space connected to identities, creators, projects, collaboration, and community experiences.

Making that possible requires more than adding a WebSocket. It requires strong security boundaries, failure handling, database isolation, reconnect logic, privacy-aware monitoring, and distributed state management.

The server-side foundation is now online.

The next step is connecting the world to it.

MyZubster: https://www.myzubster.com

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

The MyZubster Metaverse has reached a new technical milestone.

Tue, 08 Sep 2026 16:14:01 +0000

The MyZubster Metaverse has reached a new technical milestone.

We have merged a major realtime observability and reliability update into the main MyZubster repository.

Pull Request:
https://github.com/MyZubster-Ecosystem/myzubster/pull/1042

Merged commit:
https://github.com/MyZubster-Ecosystem/myzubster/commit/57fa5be2c315cb9bf55bd306969291ea10ccf766

What we implemented

The new system introduces privacy-safe monitoring for the Socket.IO realtime gateway.

It can measure:

active connections;
connection and resume attempts;
delivered and failed messages;
notification delivery;
Redis failures;
queued operations;
backpressure rejections;
operation latency percentiles;
SLO evaluations and alert candidates.

The telemetry does not include message content, authentication tokens, private keys, or raw user identifiers.

Controlled backpressure

Realtime systems can become unstable when they receive more work than they can process.

We added a bounded operation queue around critical Socket.IO operations.

When the system is temporarily busy, an operation can wait in the queue. If the configured capacity is reached, the client receives a retryable error instead of allowing unlimited memory consumption.

This gives us safer behavior during traffic bursts and measurable capacity limits.

Durable messaging

Messages and notifications are now stored before realtime delivery is attempted.

The new sequence is:

Validate the operation.
Save the message or notification.
Attempt Socket.IO delivery.
Record the delivery result.
Allow clients to recover stored information later.

A temporary socket or notification failure therefore does not destroy a message that was already saved successfully.

Redis recovery

Redis supports distributed presence when multiple realtime workers are running.

The presence layer now records Redis connection failures and can temporarily degrade to local in-memory presence.

This fallback keeps a single worker usable, while metrics clearly identify that distributed presence is unavailable.

Failed Redis clients are also invalidated so that future operations can reconnect.

Administrative metrics

We added an administrator-only endpoint:

GET /api/realtime/metrics

It provides aggregate metrics, latency information, SLO evaluations, and alert candidates.

The response is protected by authentication and uses Cache-Control: no-store.

Testing

The implementation includes tests covering:

observability counters and latency;
Redis degradation;
notification durability;
chat delivery failures;
administrator authorization;
connection bursts;
message bursts and backpressure.

We also created two operational commands:

npm run metaverse:realtime-self-check

npm run metaverse:load-baseline

A local self-check successfully processed:

12 simultaneous connections;
48 messages;
44 queued operations;
zero rejected operations;
approximately 186 ms message p95 latency.

All modified JavaScript files passed syntax validation, and the 20 files uploaded to GitHub were verified against their remote hashes.

What the production check revealed

The Vercel deployment completed successfully, and the existing metaverse is online:

https://www.myzubster.com/metaverse

The metaverse health endpoint reports MongoDB as connected and the existing shared-polling transport as healthy:

https://www.myzubster.com/api/metaverse/health

However, the new realtime metrics endpoint is not publicly active yet.

The current Vercel deployment executes:

api/index.js → server.js

The persistent Socket.IO service is implemented in:

backend/src/index.js

This means that the code is merged, but the long-running realtime backend still needs its own production deployment.

Next infrastructure phase

The next step is to deploy the realtime backend on a persistent Node.js service with:

MongoDB;
Redis;
a secure realtime token secret;
WebSocket support;
routing for /realtime;
routing for /api/realtime/*;
monitoring dashboards and alerting;
Redis and worker restart tests;
production load testing.

Vercel can continue serving the frontend and serverless APIs, while a persistent Node.js runtime handles Socket.IO traffic.

An important engineering lesson

A successful monorepo deployment does not necessarily mean that every service in the repository is running.

Testing the production URLs helped us discover the exact boundary between the Vercel application and the persistent realtime backend.

The code foundation is ready. The next objective is to connect it safely to the public MyZubster infrastructure.

Project links:

MyZubster Metaverse:
https://www.myzubster.com/metaverse

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

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

Building Social Life: Engineering a Social + WebXR Metaverse Platform

Sun, 06 Sep 2026 02:18:28 +0000

We're turning Social Life / MyZubster Metaverse from a concept into an actual engineering roadmap.

The idea is to connect three layers that are usually built separately:

Social Network + Real-World Communities + WebXR Metaverse

Instead of creating another isolated virtual world, we're designing the metaverse as a native extension of a social platform.

A user should be able to discover a community, follow its activity, join conversations, discover a public cultural event, enter its virtual twin and continue interacting with that community after the event ends.

All using the same identity and permission system.

The Architecture

Our current technical direction is:

Next.js / React
TypeScript
PostgreSQL
Redis
Object storage + CDN
WebSockets for realtime communication and presence
WebRTC / SFU for live media
Three.js or Babylon.js
WebXR
glTF-based 3D asset pipeline

The architecture is intentionally modular.

The metaverse isn't a separate product.

It sits on top of the same services used by the social platform.

Conceptually:

Identity → Social Graph → Communities → Content → Realtime → Events → WebXR Rooms

Before touching the more exciting immersive features, we're starting with the boring-but-critical infrastructure.

The first engineering block contains:

Database → Authentication → Profiles → Social Graph

From there we expand into:

Communities
Posts
Comments
Reactions
Feed
Discover
API contract tests
End-to-end tests

Authentication is designed around modern session management with revocation and server-side authorization.

Privacy is also introduced during onboarding instead of being treated as an afterthought.

Phase B: Make Everything Realtime

The second layer introduces a WebSocket-based realtime gateway.

The realtime architecture covers:

User presence
Community presence
Virtual-room presence
Direct messages
Community channels
Notifications
Blocking
Muting
Reporting
Moderation
Rate limiting
Anti-spam controls

Channels can conceptually represent:

user:{id}

community:{id}

session:{id}

The important rule is that the server remains authoritative.

The client doesn't decide whether someone belongs in a private community or virtual room.

Phase C: Enter WebXR

This is where the social platform becomes an immersive environment.

We're designing browser-accessible virtual rooms using WebXR.

The runtime will combine:

React + Three.js/Babylon.js + WebXR + WebAudio + WebSocket + WebRTC

Rooms use a defined lifecycle:

Draft → Published → Scheduled → Live → Ended → Archive

Each environment is represented through a versioned scene manifest referencing CDN-hosted assets.

That gives us a controlled pipeline for:

glTF environments
Media screens
Portals
Interactive zones
Spatial audio
Avatars
Live stages

One Metaverse, Multiple Devices

A major requirement is graceful degradation.

VR hardware should improve the experience, not become a requirement.

The same room should be accessible from:

VR/XR headsets
Desktop browsers
Mobile browsers

That means every immersive feature needs a sensible non-XR fallback.

We're also defining performance budgets, LOD strategies and asset constraints early rather than trying to optimize an enormous 3D application later.

Avatars + Realtime Presence

Avatars are tied to the existing Social Life identity.

We're starting lightweight.

The realtime layer synchronizes ephemeral information such as:

Position
Rotation
Presence
Basic interaction state

Durable identity and permissions stay in the backend.

Transient spatial state belongs in the realtime system.

Keeping those two concerns separate should make the system considerably easier to scale.

Physical Events → Virtual Twins

Another part of the architecture connects intentionally public cultural events with virtual rooms.

A creator or community can publish a public event and optionally attach a virtual environment.

The lifecycle becomes:

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

The virtual experience doesn't have to disappear when the physical event finishes.

Parts of it can remain accessible as:

Replay
Highlights
Community content
Archived rooms

We're deliberately keeping sensitive or concealed real-world location logistics outside the public product model. The event layer is designed around lawful, intentionally public information.

Creator Tools

Eventually creators need to operate these spaces without developers manually editing everything.

So we're designing a Creator Studio around:

Community management
Event publishing
Room publishing
Session management
Media management
Virtual-twin linking
Archive controls

The long-term goal is to make creating a virtual community experience closer to managing a social page than building a game.

Creator Economy Comes Later

We've also mapped out potential monetization:

Memberships
Subscriptions
Digital goods
Avatar cosmetics
Virtual-room assets
Paid virtual sessions
Creator revenue sharing

But we're intentionally not implementing this first.

Payments introduce a completely different set of engineering and regulatory problems:

Payments → Ledger → Refunds → Revenue Split → Payouts → Tax/VAT → Compliance

So the roadmap contains a mandatory legal/product/compliance gate before production payment functionality.

We're also not requiring a blockchain or token for the MVP.

Digital ownership can start with ordinary server-side entitlement records.

If decentralized ownership eventually solves a real product problem, it can be evaluated later.

Turning Architecture Into Linear Issues

One thing we've been focusing on heavily is converting architecture into executable engineering work.

The project is now organized into five milestones:

A — Social Foundation

B — Realtime Social

C — WebXR Metaverse

D — Public Events & Virtual Twins

E — Creator Economy Gate

Each milestone has been decomposed into implementation-level issues with dependencies and acceptance criteria.

For example, the WebXR milestone isn't simply:

Build the metaverse.

It's broken down into:

WebXR runtime
Scene manifest and asset pipeline
Avatar synchronization
Room lifecycle
Spatial audio
WebRTC/SFU media
Portals and interactive zones
Performance and LOD
End-to-end WebXR acceptance

That makes the project much easier to reason about.

The Bigger Engineering Question

The interesting challenge isn't really:

"How do we build a metaverse?"

It's:

"How do we make immersive environments behave like a normal part of the web?"

A virtual room should ultimately be another destination in the application.

You discover it.

You have permission to access it.

You enter it.

Your identity follows you.

Your community follows you.

Realtime services connect you to everyone else.

And when you leave the 3D environment, you're still inside the same social ecosystem.

That's the architecture we're working toward with Social Life / MyZubster Metaverse.

What's Next

We're now moving from architecture into implementation.

The first development sequence is deliberately simple:

Database → Auth → Profiles → Social Graph → Communities → Content → Feed

Then:

Realtime → Messaging → Presence

And finally:

WebXR Runtime → Rooms → Avatars → Live Media → Virtual Twins

I'll share more as individual components move from Linear issues into working code.

I'm especially interested in hearing from developers working with WebXR, Three.js/Babylon.js, WebRTC, realtime infrastructure or large social architectures.

How would you approach a browser-first social metaverse?

And where do you think the hardest scaling problem will appear first?

# MyZubster Overnight Update: Metaverse Safety and a Live Space Station

Fri, 04 Sep 2026 00:38:10 +0000

MyZubster Overnight Update: Metaverse Safety and a Live Space Station

Last night we shipped two important improvements to the MyZubster open-source ecosystem: a formal safety baseline for our Metaverse and a public connection to the MyZubster Space Station.

Neon Plaza is becoming a real shared environment

The MyZubster Metaverse is available here:

https://www.myzubster.com/metaverse

Neon Plaza already supports:

Shared MongoDB-backed presence
Keyboard and touch movement
Public chat and emotes
Proximity awareness
Guest and account-linked characters
Portals to Marketplace, LIFE, Identity, Visual and Zorgax
Session and browser capability dashboards

The current synchronization model uses serverless-compatible shared polling. WebSockets, 3D/WebXR rendering and spatial voice remain part of the future roadmap.

Privacy and abuse-control baseline

We merged PR #920, which documents the verified privacy and retention boundaries of Neon Plaza.

The baseline establishes that:

Presence expires after 90 seconds of inactivity
Public chat expires after one hour
User-controlled inputs are sanitized and length-limited
Logs exclude chat content, tokens and session identifiers
Authenticated characters are resolved through MyZubster accounts
Client-provided identity claims are never considered verified
Permanent movement history is not collected

The change passed CI, frontend and backend tests, lint, Security Audit, Continuous Evidence Gate and Vercel checks.

We also documented the remaining gaps honestly: distributed rate limiting, spam detection, mute, block, reporting, moderator auditing and formal deletion procedures are not complete yet.

MyZubster Space Station is online

We also merged PR #921, introducing the public Space Station dashboard:

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

The website now accesses station health, robot and mission information through same-origin API proxy routes. Backend secrets are never exposed to the browser.

The live health service currently reports:

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

Browser access remains read-only. Inventory mutations, economic operations and robot commands will not be exposed until a production authentication and authorization layer is available.

A broader read-only integration for spaces, inventory, MYZ balances and missions is under development in PR #919.

Where this is going

The goal is to connect several real components:

Neon Plaza as the social and immersive layer
Space Station as the robotics and mission layer
MyZubster Identity for persistent participants
Marketplace for creator services and digital resources
LIFE projects for environmental data and verifiable missions
Evidence gates for reproducible technical claims

The priority is not to call everything “complete.” The priority is to build openly, test each layer and distinguish production functionality from experiments and roadmap ideas.

MyZubster is gradually becoming an open ecosystem where people, software agents, robots and real-world data can interact through verifiable identities and transparent infrastructure.

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

OpenSource #Metaverse #Robotics #NodeJS #React #MongoDB #WebDevelopment

We’re Taking Zorgax From GitHub Into the Real World — And N4K48 Is One of the First Experiments

Wed, 02 Sep 2026 01:08:38 +0000

We’re Taking Zorgax From GitHub Into the Real World — And N4K48 Is One of the First Experiments

For a long time, most of the work around MyZubster and Zorgax happened where you would expect an open-source project to live:

GitHub repositories.

APIs.

Tests.

CI pipelines.

Architecture diagrams.

Infrastructure experiments.

But eventually every ambitious software project reaches an uncomfortable point:

Does any of this actually help a real person do something?

That is the phase we are entering now.

And one of our first experiments has a name:

Nicola.

Inside the MyZubster Metaverse, his character is N4K48.

But the interesting part isn't the avatar.

It's what is happening outside the Metaverse.

From AI assistant to execution loop

Zorgax started as an intelligence and coordination layer inside the broader MyZubster ecosystem.

The model we are exploring is:

Knowledge → Reasoning → Recommendation → Human Approval → Action → Measurement → Learning

The important part is the middle.

We don't want AI to silently make consequential decisions and then tell humans what happened.

We want it to help people move from uncertainty to structured action while keeping important decisions human.

So we started testing that idea with real participants.

Nicola is one of them.

Nicola started with an idea

The experiment is simple.

Can Zorgax help someone move from an idea toward a small, testable digital product without pretending that AI already knows whether the idea will succeed?

The process looks roughly like this:

IDEA
  ↓
STRUCTURE
  ↓
VALIDATION
  ↓
EVIDENCE
  ↓
HUMAN DECISION
  ↓
MVP
  ↓
TEST
  ↓
MEASURE
  ↓
LEARN

No guaranteed revenue.

No invented market demand.

No AI-generated success story.

If the evidence is weak, the system should say that the evidence is weak.

Then something interesting happened

Nicola didn't stop at discussing the idea.

He started building.

A GitHub repository appeared.

Then the initial MVP structure.

Then automated testing.

Then GitHub Actions.

Then the inevitable debugging.

Test discovery needed fixing.

Dependencies needed fixing.

The server startup process needed fixing.

Tests needed restructuring.

HTTP expectations needed correcting.

And commit by commit, the project started becoming something executable rather than something hypothetical.

That distinction matters to me.

There is an enormous difference between:

"AI gave me an idea."

and:

"AI helped me organize a process that resulted in me actually building and testing something."

The second one is what we're interested in.

A result that isn't revenue

There is another outcome I find interesting.

Nicola told us that working through this process increased his motivation enough that he decided to buy a computer so he could continue working on the project and with Zorgax.

I'm deliberately careful about how I describe that.

It isn't a financial KPI.

It isn't proof of product-market fit.

It isn't proof that his MVP will become a business.

But it is evidence of behavioral change.

An idea became activity.

Activity became code.

Code became tests.

And the participant invested in his own ability to continue.

For an experimental human-AI workflow, that's worth paying attention to.

So why put Nicola in a Metaverse?

This is where N4K48 enters the picture.

MyZubster already has a browser-based shared environment called Neon Plaza.

Users can enter as guests, while authenticated users can have account-linked characters.

The important architectural rule is that a manually entered guest identity is not treated as verified.

Why?

Because eventually the Metaverse is supposed to connect to things that matter:

GitHub contributions;
missions;
bounties;
projects;
community roles;
environmental initiatives;
creator activity;
potentially economic transactions.

If reputation matters, we can't manufacture it with an arbitrary username.

N4K48

Nicola's character is:

N4K48

Archetype:

Explorer

World:

Neon Plaza

The long-term idea is that N4K48 shouldn't simply be a visual avatar.

It should become a representation of Nicola's verifiable journey through the ecosystem.

Imagine this:

Real contribution
       ↓
GitHub evidence
       ↓
Verification
       ↓
MyZubster identity
       ↓
Metaverse achievement

Instead of buying a shiny "developer badge", you earn it because there is actual evidence that you contributed.

Instead of claiming that you completed a project, the project can point back to its evidence.

Instead of the Metaverse creating reputation, the Metaverse visualizes reputation created elsewhere.

That's a much more interesting problem.

The Metaverse becomes an interface

This changes how I think about virtual worlds.

A Metaverse doesn't necessarily have to be a replacement reality.

It could be an interface to real activity.

A GitHub issue could become a mission terminal.

An environmental sensor network could become a digital twin.

A community project could have its own district.

A contributor could walk through Neon Plaza and discover something they can actually work on.

And a character like N4K48 could carry a history based on real contributions rather than fictional statistics.

Zorgax shouldn't control this world

There's another boundary we're trying to preserve.

Zorgax should not become the invisible ruler of the ecosystem.

It can:

analyze;
compare;
organize;
suggest;
detect inconsistencies;
prepare actions;
measure outcomes.

But sensitive decisions still need explicit human authority.

That applies to publishing.

Payments.

Commercial communication.

Important identity changes.

And decisions about whether evidence is sufficient.

The architecture we're aiming for is therefore not:

AI → ACTION

It's closer to:

DATA
  ↓
ZORGAX
  ↓
RECOMMENDATION
  ↓
HUMAN DECISION
  ↓
ACTION
  ↓
MEASUREMENT
  ↓
LEARNING

Slower?

Sometimes.

More auditable?

Hopefully.

The same principle applies to money

The economic layer we're building follows a similar philosophy.

MyZubster is exploring non-custodial payment flows.

The platform shouldn't need someone's private keys.

A simplified model is:

Payment intent
      ↓
External wallet
      ↓
Blockchain transaction
      ↓
Independent verification
      ↓
Entitlement / result

But even here, a blockchain transaction isn't magical proof that something happened.

A payment can prove that funds moved.

It cannot automatically prove that a product was delivered.

It cannot prove that a GitHub contribution was good.

It cannot prove that an environmental intervention worked.

Different claims require different evidence.

That's becoming one of the recurring principles behind MyZubster.

From virtual identity to real-world evidence

The same architecture becomes even more interesting when we move outside purely digital projects.

We're exploring concepts involving:

IoT;
environmental monitoring;
water;
biodiversity;
territorial projects;
digital twins;
measurable environmental results.

A future workflow might look like:

PHYSICAL WORLD
      ↓
SENSORS
      ↓
DATA
      ↓
ZORGAX
      ↓
HUMAN DECISION
      ↓
ACTION
      ↓
MEASUREMENT
      ↓
VERIFICATION
      ↓
METAVERSE

The virtual representation comes after the evidence.

Not before it.

That's important.

What exists today

There is still a huge amount to build.

Neon Plaza is an early environment, not some finished decentralized universe.

Today we have foundations such as:

browser-based Metaverse access;
guest and authenticated characters;
account-linked identities;
shared presence;
movement;
chat and emotes;
temporary data retention;
production monitoring;
automated testing;
a roadmap toward missions, economy and federation.

And now we are beginning to connect that infrastructure with real participants.

N4K48 is one of the first examples.

What Nicola's experiment actually tells us

Not that Zorgax can create successful companies.

We don't know that.

Not that every AI-assisted idea will work.

Obviously not.

And certainly not that writing prompts magically creates entrepreneurship.

What we can say is much smaller — but more useful:

a participant moved from an idea to structured activity and technical execution.

There is now something we can observe.

Something we can test.

Something that can fail.

Something that can improve.

That is much more valuable to an engineering project than another hypothetical AI demo.

Building in public means showing the unfinished parts

This experiment could fail.

Nicola's MVP might need to change direction.

Users might not care about it.

Our assumptions about the Metaverse might be wrong.

Some parts of Zorgax might turn out to be unnecessarily complicated.

That's fine.

The objective isn't to document a predetermined success.

The objective is to build an evidence loop.

BUILD
  ↓
TEST
  ↓
OBSERVE
  ↓
DECIDE
  ↓
IMPROVE

And repeat.

N4K48 is just the beginning

Eventually I want to walk into Neon Plaza and see characters whose histories actually mean something.

A developer with contributions you can inspect.

A researcher connected to a real project.

A participant building their first digital product.

A community running an environmental initiative.

An explorer completing an open-source mission.

Not because a centralized game database awarded them 5,000 XP.

Because something happened in the real world — and there is evidence for it.

That's the experiment.

Nicola is building.

N4K48 is entering Neon Plaza.

And Zorgax is slowly moving from repositories and architecture diagrams into the much messier environment that actually matters:

reality.

MyZubster
https://www.myzubster.com

Enter Neon Plaza
https://www.myzubster.com/metaverse

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

If you're building open-source systems around AI agents, verifiable identity, virtual worlds, IoT, human-in-the-loop automation or evidence-based reputation, I'd be interested in comparing approaches.

We're still building this in public.

We’re Building Zorgax as a Consent-Driven AI Operating Layer

Mon, 31 Aug 2026 01:24:49 +0000

We’re Building Zorgax as a Consent-Driven AI Operating Layer

We’re currently experimenting with a different approach to AI agents inside MyZubster.

The goal is not to build an agent that “does everything automatically.”

The goal is to build an agent that can operate across projects, identity, evidence, GitHub workflows, and eventually economic actions — while keeping consent, auditability, and human approval as first-class constraints.

That agent is Zorgax.

The current pilot

We’re testing Zorgax with a real participant in a digital entrepreneur workflow.

The process is intentionally structured:

Idea → Validation → Evidence → Human Choice → Blueprint → MVP → Approval → Possible Launch → Measurement → Learning

Instead of letting AI jump directly from “idea” to “build,” Zorgax first collects and evaluates evidence.

For the current pilot, two possible product ideas are being validated with real users.

Before evaluating the next responses, we created a fixed scoring model.

Each response can be scored against six criteria:

real problem;
urgency/intensity;
weakness of current solution;
willingness to test;
clarity of expected result;
clarity of required feature.

The model is defined before seeing the full dataset.

This avoids one of the easiest failure modes in AI-assisted decision making: changing the evaluation logic after seeing the answers.

If the evidence is insufficient, Zorgax should not invent confidence.

It returns:

MORE EVIDENCE REQUIRED

If the evidence is equivalent:

TIE / HUMAN CHOICE

That distinction matters.

Consent-driven automation

We are now adding another layer:

Zorgax Participant Profile Automation v0.1

The idea is to let Zorgax automatically maintain a participant’s project profile, but only inside an explicit consent boundary.

The intended flow is:

Consent → Authorized Scope → Data Processing → Proposed Update → Review → Human Approval

The participant can authorize Zorgax to use things like:

confirmed questionnaire responses;
project goals;
public GitHub activity;
documented progress;
validated evidence;
roadmap status.

Sensitive data stays outside the automation:

passwords;
tokens;
2FA codes;
wallet secrets;
private keys;
banking data;
unnecessary personal information.

If a field is unknown, the system should preserve that uncertainty instead of filling it with generated content.

GitHub becomes the audit layer

One design choice we are testing is using GitHub as the operational audit trail.

The preferred workflow is:

ZORGAX → BRANCH → COMMIT → PULL REQUEST → HUMAN REVIEW → MERGE

This makes AI-generated work inspectable.

You can see:

what Zorgax changed,

why it changed,

what evidence supported the change,

and whether a human approved it.

That is much safer than giving an agent unrestricted write access to production state.

Identity and the Metaverse

We’re also applying the same principle to MyZubster Metaverse identities.

Instead of treating avatars as disconnected aliases, we’re working toward account-linked characters.

A participant can choose:

character name;
archetype;
starting world;

while the identity link is based on a verified account flow.

The interesting part is not the 3D character.

It is the identity graph behind it.

A character could eventually represent:

verified participation;
contributions;
project history;
achievements;
evidence;
reputation.

Without exposing credentials to the AI.

Human-in-the-loop is not a limitation

A lot of agent systems treat human approval as friction.

We’re treating it as architecture.

For example, Zorgax can prepare recommendations, profile changes, project updates, and code changes automatically.

But sensitive actions remain gated:

merge to protected branches;
public commercial publication;
real pricing;
spending;
payments;
wallet actions;
destructive database changes;
external commercial communications.

The larger model is:

Knowledge → Reasoning → Decision → Human Approval → Action → Measurement → Learning

That is the direction we are building Zorgax toward.

Why we think this matters

AI agents are becoming more capable very quickly.

But capability without boundaries is not enough.

When an agent starts interacting with real identity, money, public reputation, infrastructure, or business decisions, we need stronger operational guarantees.

We need:

consent, provenance, auditability, reversibility, and human authority.

Our current hypothesis is simple:

the best AI operating layer is not the one that removes the human.

It is the one that removes repetitive work while making important decisions easier to understand and safer to execute.

That is what we are trying to build with MyZubster + Zorgax.

AI #AIAgents #OpenSource #Zorgax #MyZubster #HumanInTheLoop #GitHub #Automation #DigitalIdentity #Metaverse #BuildInPublic

Yassen Mainardi Enters the MyZubster Universe

Thu, 27 Aug 2026 23:50:11 +0000

Yassen Mainardi Enters the MyZubster Universe

The MyZubster universe continues to grow.

Today we introduce Yassen Mainardi, a new character connected to the evolving world of MyZubster — where real-world participation, digital identity, environmental action, technology, culture, music and community can become part of a persistent digital story.

A character is more than an avatar

One of the ideas behind MyZubster is that a character should not simply be a profile picture.

A character can become the representation of a journey.

Actions, projects, contributions and verified experiences can progressively build its history.

For Yassen Mainardi, we want to explore exactly this concept:

real person → digital character → activities → evidence → evolving story

Instead of creating a static fictional biography, the character can grow alongside the real activities that are actually documented.

The MyZubster Character Layer

Our longer-term architecture connects several components:

Real-world identity

↓

MyZubster Character

↓

Verified activities

↓

Photos / evidence / contributions

↓

Reputation & achievements

↓

Persistent digital history

↓

MyZubster Universe

This allows characters such as Yassen Mainardi to potentially participate across different MyZubster categories rather than being locked into a single experience.

Environment.
Music.
Sport.
Culture.
Technology.
Community projects.
Creative work.

Each category can become another part of the character's history.

From characters to a living ecosystem

This is also why we're developing MyZubster characters alongside our work on maps, environmental pilots, evidence verification and decentralized infrastructure.

The goal isn't simply to populate a metaverse with avatars.

The interesting question is:

What happens when a digital character can carry a verifiable history of what its human counterpart has actually contributed?

Yassen Mainardi represents another step in exploring that idea.

The character starts here.

The story will be written by what happens next.

Welcome to MyZubster, Yassen.

MyZubster #OpenSource #DigitalIdentity #Metaverse #Community #BuildInPublic #Web3

The Internet Is Ruined: Can the Metaverse Still Be Saved?

Fri, 20 Mar 2026 05:25:59 +0000

The Internet Is Ruined: Can the Metaverse Still Be Saved?

We live in an era of digital exhaustion. For many, logging onto the modern internet feels less like an exploration of infinite possibilities and more like walking through a crowded, neon-lit shopping mall where every storefront is screaming for your attention, data, and wallet. The promise of the early web—a decentralized, open landscape for human connection—has been supplanted by the walled gardens of massive conglomerates. Algorithmic feeds, relentless surveillance capitalism, and the erosion of privacy have turned our digital public square into a battlefield of noise. The internet, in its current iteration, is effectively ruined.

The Decline of the Digital Commons

To understand why the internet feels broken, we must look at the transition from Web 2.0 to the platform-centric model we inhabit today. Initially, the web was about discovery. You surfed pages, you visited distinct sites, and you learned things. Today, the internet is about ‘consumption environments.’ We do not ‘browse’ the web anymore; we scroll through feeds curated by black-box algorithms designed to keep us agitated and engaged. This model has stripped the internet of its spontaneity and replaced it with a flattened, homogenized experience. The result? A digital landscape that feels claustrophobic, repetitive, and increasingly hostile to genuine human interaction.

Enter the Metaverse: A Second Chance or a Second Scam?

Against this backdrop, the concept of the Metaverse has emerged. Initially marketed as a rebranding exercise for Big Tech, the term has become a lightning rod for criticism. Is it just a glorified video game? Is it a dystopian surveillance trap? These are valid concerns, especially given the current trajectory of centralized technology providers. However, if we peel back the marketing jargon and the shiny VR headsets, the core premise of the Metaverse represents a radical shift in how we relate to digital space.

The vision of a spatial internet—one where we are ‘in’ the experience rather than ‘looking’ at it—could be the antidote to the flat, algorithmic noise of our current web. Instead of being passive consumers of content, we can become active participants in persistent, communal spaces. The Metaverse offers the opportunity to decouple our social and professional lives from the data-harvesting social media platforms that have dominated the last two decades.

Building for Sovereignty

For the Metaverse to save us from the ruin of the current internet, it must be fundamentally different from its predecessor. It cannot be owned by a single corporation. It must be built on open standards, interoperability, and digital sovereignty. The decentralization movement within Web3 is not just about finance; it is about infrastructure. If we can create virtual spaces where users own their digital assets, their identity, and their data, we fundamentally change the power dynamic. The platform no longer owns the user; the user owns the space.

Imagine a digital world where you can take your avatar, your clothes, your tools, and your reputation from one experience to another without needing permission from a central authority. This is the promise of an interoperable Metaverse. It is the antithesis of the ‘locked-in’ ecosystem that defines our current mobile experience. By prioritizing open-source code and decentralized protocols, we can build a digital architecture that serves the user first, rather than the advertiser.

Reframing the Immersive Experience

The skepticism surrounding the Metaverse is largely driven by the ‘gimmick’ factor. People associate it with clunky headsets and low-resolution avatars. But the Metaverse is not a hardware problem; it is a connectivity and infrastructure problem. It is about the ability to share a sense of ‘presence’ with others regardless of physical distance. Think of the difference between reading a text message and sitting across the table from a friend. The current internet is all text messages. A properly realized Metaverse provides that sense of shared space.

This is crucial for the future of work, education, and socialization. We have spent the last few years discovering that digital communication is efficient but emotionally hollow. A persistent, spatial web could restore the nuance of human interaction, allowing for spontaneous meetings, collaborative creative endeavors, and complex environmental design that is simply impossible on a flat 2D webpage.

Addressing the Dystopian Risks

Of course, the Metaverse is not inherently benign. If we replicate the mistakes of the current web—centralization, lack of moderation, and unchecked surveillance—we will simply be building a more effective cage. The risks of digital addiction, harassment, and the further erosion of physical reality are significant. To save the internet through the Metaverse, we need a strong focus on ethics, accessibility, and governance.

We need to develop new social contracts for virtual spaces. How do we ensure that these environments are inclusive? How do we protect users from toxic behavior without resorting to the censorship models that currently plague social media? These are the questions that technologists, sociologists, and policymakers need to solve right now. The Metaverse should be a tool for human flourishing, not a way to isolate ourselves further from the real world.

The Road Ahead: A Call for Openness

The current internet is ruined because we let it become a commodity. We traded our privacy and our attention for convenience. Saving the digital future requires a conscious effort to support open, transparent, and user-focused technologies. We must demand interoperability, reject proprietary ecosystems, and push for a web that feels human again.

The Metaverse is still in its infancy, which means it is still malleable. We have the chance to define what it becomes before it is finalized by monolithic entities. If we treat it as an extension of the open web—a continuation of the dream of a decentralized, free-flowing information network—we might just find that the internet isn’t broken beyond repair. We might find that we have simply reached the end of one cycle and are ready to build the next one, better, stronger, and more human than before.

The future of the internet is not something that happens to us; it is something we build. Let us make sure that when we step into the next phase of our digital evolution, we are walking into a world that reflects our best intentions, not our worst habits.

The post The Internet Is Ruined: Can the Metaverse Still Be Saved? first appeared on Insight Ginie.

Coder Legion - Recent posts tagged metaverse

How We Secured the MyZubster Metaverse: Session Ownership, Verified Explorers and the Road to Realti

Engineering a Browser-First Metaverse: WebXR Fallbacks, Server-Authoritative Rooms, and Versioned

How We Built Revocable Sessions and Refresh-Token Replay Protection for the MyZubster Metaverse

Building MyZubster as a Verifiable AI Development Ecosystem

AI #OpenSource #SoftwareArchitecture #SoftwareDevelopment #GitHub #Metaverse #Web3 #KnowledgeGraph #ArtificialIntelligence #NodeJS #Developers #MyZubster #Zorgax

# MyZubster Is Becoming an Identity and Interaction Layer: Authentication → Zorgax → GitHub → Metave

MyZubster Is Becoming an Identity and Interaction Layer: Authentication → Zorgax → GitHub → Metaverse → NFTs

Authentication Is the Starting Point

Zorgax Helps Build the Profile

Then GitHub Makes the Profile Inspectable

The Same Identity Can Enter the Metaverse

GitHub + Metaverse Creates a New Kind of Interaction

Where NFTs Become Interesting

MyZubster Becomes the Connector

The Important Part: Don't Confuse Identity With Evidence

What MyZubster Is Becoming

MyZubster #Zorgax #OpenSource #GitHub #Metaverse #NFT #DigitalIdentity #AIAgents #BuildInPublic

Building MyZubster World: The Metaverse Infrastructure We Have Implemented

Building MyZubster World: The Architecture We Have Implemented and What Is Still Missing

Building MyZubster: A Circular Marketplace Connected to a Social Metaverse

MyZubster #OpenSource #WebDevelopment #Metaverse #Marketplace #CircularEconomy #ReactJS #NodeJS #MongoDB #BuildInPublic

Building MyZubster in Public: From Visual Storytelling to an Interactive Metaverse

Building MyZubster in Public: From Visual Storytelling to an Interactive Metaverse

Visuals as part of the product

The MyZubster comic

Darkode as a digital memory layer

Neon Plaza: guest access before registration

Introducing a first mission

Character verification

Nicola and N4K48

Preparing an NFT candidate without pretending it has been minted

Measuring the conversion funnel

What we learned

Next steps

Project links

Building the Realtime Foundation of the MyZubster Metaverse

Building the Realtime Foundation of the MyZubster Metaverse

From polling to realtime communication

The preview runtime is online

Secure realtime authentication

Presence, messaging, and reconnects

Preview database isolation

Privacy-aware observability

Why presence is still using a fallback

What we are working on next

Current project status

Building a world, not just a page

The MyZubster Metaverse has reached a new technical milestone.

What we implemented

Controlled backpressure

Durable messaging

Redis recovery

Administrative metrics

Testing

What the production check revealed

Next infrastructure phase

An important engineering lesson

Building Social Life: Engineering a Social + WebXR Metaverse Platform

Building Social Life: Engineering a Social + WebXR Metaverse Platform

The Architecture

Phase A: Build the Social Foundation

Phase B: Make Everything Realtime

Phase C: Enter WebXR

One Metaverse, Multiple Devices

Avatars + Realtime Presence

Physical Events → Virtual Twins

Creator Tools

Creator Economy Comes Later

Turning Architecture Into Linear Issues

The Bigger Engineering Question

What's Next

# MyZubster Overnight Update: Metaverse Safety and a Live Space Station

MyZubster Overnight Update: Metaverse Safety and a Live Space Station

Neon Plaza is becoming a real shared environment

Privacy and abuse-control baseline

MyZubster Space Station is online

Where this is going

OpenSource #Metaverse #Robotics #NodeJS #React #MongoDB #WebDevelopment

We’re Taking Zorgax From GitHub Into the Real World — And N4K48 Is One of the First Experiments