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

Coder Legion - Recent posts tagged buildiinpublic

Building the Realtime Foundation of the MyZubster Metaverse