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