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
Phase A: Build the Social Foundation
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
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.
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?
