🧠 Coder Legion Dev Log — Building the MyZubster Metaverse from the infrastructure up
I’ve been working on the MyZubster Metaverse with a very specific engineering approach:
do not start from the 3D layer. Start from identity, authorization, state, lifecycle and failure handling.
The current stack already includes several production-oriented building blocks.
Identity and session model
The Metaverse supports both:
- guest characters
- authenticated, account-linked identities
For authenticated users, canonical character data is resolved server-side so the client cannot freely override trusted identity state.
This matters because virtual-world logic becomes much harder to secure once identity, permissions and session state are mixed together.
Realtime authorization
One of the more important backend changes was introducing a fail-closed authorization path for community realtime channels.
If the membership authority is unavailable, access is denied instead of waiting on buffered database operations or leaving socket authorization in an ambiguous state.
I added coverage for:
- disconnected MongoDB state
- active persisted membership
- membership query failures
- unauthorized access attempts
This is a small change in code, but a meaningful system-design decision.
Room lifecycle
The room layer already supports:
- public / authenticated / private access policies
- invitations
- session creation
- participant join/leave
- host controls
- stage requests
- speaker approval/revocation
- participant moderation
- message reporting
- bounded moderation history
The important point is that the room is treated as a stateful system, not just a visual container.
Frontend state hardening
I’ve also been cleaning up React lifecycle behavior.
Recent fixes include:
- reloading room state when authentication changes
- stabilizing async data loading with
useCallback
- tightening effect dependencies
- keeping UI state aligned with server-side session state
Example recent commits:
0b5e7fa — refresh Metaverse room when auth state changes
fa94a88 — stabilize frontend loading callback
0347827 — make paid analytics explicit instead of automatic
Auth and observability testing
I also aligned tests around:
- authenticated Metaverse flows
- server-backed sessions
- auth expiry
- same-origin authenticated requests
- health endpoint behavior
- storage failure semantics
A previous checkpoint also hardened realtime membership authorization and added test coverage around failure states:
0af298e — fail-closed realtime auth
9ac9f53 — auth session test alignment
5bf365d — auth + observability test alignment
Deployment discipline
Another part of the work was CI/CD hygiene.
I removed automatic activation of paid Vercel Web Analytics from the deployment workflow.
That means deployment stays deterministic and billing-related features remain explicit operational decisions.
Current architecture direction
The development sequence I’m following is:
identity
→ authorization
→ state
→ room lifecycle
→ moderation
→ observability
→ realtime rendering
This is intentional.
A visually impressive world with weak session handling, unclear authorization or fragile failure modes is still a fragile system.
So the current priority is to make the platform behavior coherent before connecting the final immersive realtime rendering layer.
Skills this work is exercising
This project has been a practical exercise in:
- React hooks and state synchronization
- Node.js backend architecture
- REST API design
- realtime authorization
- authentication and session handling
- MongoDB / Mongoose
- fail-closed security patterns
- moderation systems
- automated testing
- observability
- CI/CD
- Vercel deployment workflows
- production debugging
- incremental system hardening
The immersive layer is still the next milestone.
But the system underneath it is becoming much more real.
Build the world after the rules of the world are reliable.