Building the MyZubster Metaverse: Where We Are, What We Are Fixing, and What Comes Next

title: "Building the MyZubster Metaverse: Where We Are, What We Are Fixing, and What Comes Next"
published: false
description: "A detailed development update on MyZubster’s Metaverse, account security, Verified Knowledge, GitHub integration, reliability, and the roadmap toward a testable public platform."
tags: opensource, webdev, security, metaverse
Building the MyZubster Metaverse: Where We Are, What We Are Fixing, and What Comes Next
MyZubster is evolving from a collection of community tools into a connected digital ecosystem.
Our long-term goal is not simply to build another virtual world. We want to create an environment where people, developers, universities, contributors, organizations, knowledge, and digital services can interact through verifiable identities and transparent workflows.
The project currently connects several major areas:

• The MyZubster Metaverse
• Verified Knowledge
• Zorgax development tools
• GitHub contribution workflows
• Development Requests
• Community and university pilots
• Optional rewards and bounty systems This post is an honest technical update about what we are building, what is already working, what remains incomplete, and what we need to prioritize next. The vision The MyZubster Metaverse is intended to become a digital environment where users can:
• Create a persistent identity
• Enter shared virtual spaces
• Communicate in real time
• Access verified public knowledge
• Request software or community development
• Connect requests to GitHub issues and pull requests
• Track technical work through verifiable evidence
• Participate in university and community pilots
• Use optional rewards when the settlement process is operational and independently verifiable The important principle is that the Metaverse should not be an isolated 3D interface. It should be the visual and social layer of a larger, verifiable system. A possible future workflow looks like this: User or organization ↓ Verified Knowledge ↓ Development Request ↓ GitHub issue ↓ Developer contribution ↓ Pull request and review ↓ Community testing ↓ Evidence ↓ Independent verification ↓ New verified knowledge This is the foundation we are building toward. Where the public Metaverse currently stands The public Metaverse route is online: https://www.myzubster.com/metaverse The backend health endpoint has also been responding correctly, with the application connected to MongoDB. The current platform already contains work related to:
• User accounts
• Social authentication
• Metaverse characters
• Persistent character identities
• Real-time communication
• Privacy-safe analytics
• Location and activity data
• Marketplace features
• Knowledge exploration
• Zorgax development services However, “online” does not mean “finished.” Before expanding WebXR, 3D spaces, economic features, or additional public experiences, we must complete the underlying security and reliability work. That is now the priority. Current focus: secure and revocable sessions The most important active security task is tracked as: MYZ-71 — Authentication, sessions and account security Previously, MyZubster could issue signed JWT access tokens, but those tokens were not connected to a persistent server-side session record. This creates an important limitation: a valid token generally remains usable until it expires, even if a user wants to log out remotely or revoke access from another device. We are now changing that model. What has been implemented locally We have implemented the first major slice of the new session architecture. Every new login can now create a persistent session record containing:
• A unique session identifier
• The associated user ID
• The device or browser user-agent
• A privacy-preserving hash of the IP address
• Creation time
• Last activity time
• Expiration time
• Revocation time
• Revocation reason The signed JWT contains a sid claim that identifies the server-side session. Authentication therefore becomes a two-step verification:
• Verify the JWT signature and expiration
• Verify that its server-side session is still active A token is rejected when its session:
• Does not exist
• Has expired
• Has been revoked
• Does not belong to the expected user This gives MyZubster the foundation for real logout and device management. New account-session endpoints The current implementation introduces the following API operations: POST /api/auth/logout GET /api/auth/me GET /api/auth/me/sessions DELETE /api/auth/me/sessions/:sessionId These endpoints allow the application to:
• Return the authenticated account
• List active devices and sessions
• Identify the current session
• Revoke another session
• Revoke the current session during logout
• Clear the authentication cookie Registration, password login, and verified social login are also being updated so that they create a persistent session rather than issuing only a disconnected token. Safer browser authentication The new implementation supports an HTTP-only session cookie. The cookie uses:
• HttpOnly
• SameSite=Lax
• Secure in production
• A controlled expiration time
• A root path scope This makes the token inaccessible to ordinary client-side JavaScript and reduces exposure during common browser attacks. Bearer tokens remain temporarily supported for compatibility with existing clients and API consumers. Safe migration from legacy tokens Existing MyZubster clients may still hold JWTs that do not contain a session identifier. Immediately invalidating every legacy token could break active users without warning. For this reason, the implementation includes a migration mode. During the transition: Legacy token without sid ↓ Temporarily accepted After the migration window: REQUIRE_SERVER_SESSION=true ↓ Tokens without a valid server session are rejected This allows us to move toward strict server-side revocation without causing an uncontrolled production outage. Standardized authentication errors Authentication failures now return a structured public error: { "success": false, "request_id": "example-request-id", "error": { "code": "AUTH_SESSION_REVOKED", "message": "Session expired or revoked" } } The request_id helps us connect user-visible failures to server logs without returning internal exception details. The system distinguishes between cases such as:
• AUTH_TOKEN_MISSING
• AUTH_TOKEN_INVALID
• AUTH_TOKEN_EXPIRED
• AUTH_SESSION_REVOKED
• SESSION_NOT_FOUND
• SESSION_LIST_FAILED
• SESSION_REVOKE_FAILED
• LOGOUT_FAILED This should make authentication problems easier to diagnose and safer to expose publicly. Testing progress The new session work currently has automated coverage for:
• Creating a persistent session
• Adding the session ID to the JWT
• Recording device metadata
• Hashing IP information
• Accepting active sessions
• Rejecting revoked or missing sessions
• Supporting bearer tokens
• Supporting secure session cookies
• Identifying the current device
• Migrating legacy tokens
• Returning stable authentication errors
• Preserving the social OAuth callback flow The current focused result is: Test suites: 3 passed Tests: 17 passed Snapshots: 0 We also started the MongoDB-backed integration test for social identities. That suite needs a large MongoDB test binary on its first execution. The first run exceeded the old five-second Jest initialization timeout while downloading the binary. We have adjusted the test so first-time setup has a realistic timeout and safe cleanup. The integration test still needs to be rerun to completion before the change is considered ready for review. This session work is not yet being described as fully deployed. It remains a development branch until integration testing and review are complete. Authentication work still remaining The current implementation is an important foundation, but it does not complete MYZ-71. We still need to deliver:
• Complete integration testing The MongoDB-backed test must verify that:
• A social login creates a user
• A persistent Metaverse character is connected to that user
• A server-side authentication session is created
• Repeated login does not duplicate the user
• Repeated login does not duplicate the character
• Separate logins create independently revocable sessions
• Refresh-token rotation The current session model supports revocation, but we still need a complete access-token and refresh-token lifecycle. The final design should include:
• Short-lived access tokens
• Rotating refresh tokens
• Replay detection
• Token-family invalidation
• Session revocation after suspicious reuse
• Passkey-first authentication Passkeys remain part of the target architecture. The planned flow is: POST /auth/start ↓ Passkey or magic-link challenge ↓ POST /auth/verify ↓ Persistent server-side session OAuth can remain available, but the long-term account security model should not depend entirely on third-party social providers.
• Step-up authentication Sensitive actions should require recent or stronger authentication. Examples include:
• Changing the primary email
• Changing security settings
• Deleting an account
• Managing payment information
• Revoking all other sessions
• Publishing or transferring valuable assets The session model now gives us a place to implement that policy.
• Account-security interface Users need a clear interface showing:
• Current device
• Other active devices
• Approximate last activity
• Session creation date
• Session expiration
• A revoke button
• A “log out everywhere else” action The backend endpoints are the first step. The user interface still needs to be built. Verified Knowledge status Verified Knowledge is another important part of the project. Its purpose is to provide public information with:
• Provenance
• Evidence
• Review status
• Versioning
• Lineage
• Links to development activity A public Knowledge Explorer interface has already been created. It includes:
• English and Italian routes
• Search
• Public and verified filters
• Links to the canonical repository
• Integration points for Zorgax However, the public deployment has recently shown: Verified Knowledge is temporarily unavailable The interface is online, but the data service is not fully configured in the relevant deployment environment. The known deployment work includes:
• Configuring the correct MongoDB connection
• Confirming production environment variables
• Verifying the canonical data source
• Testing the public API
• Connecting Knowledge entries to Development Requests
• Connecting completed work back to evidence and verified knowledge The interface should not pretend that data is available when the backend is unavailable. The current message is intentionally explicit. Development Request roadmap The Development Request system is the bridge between knowledge, users, and software contributors. Its purpose is to transform a structured need into something that can be implemented and verified. The current planned sequence is: MYZ-191 — DevelopmentRequest core ↓ MYZ-192 — GitHub issue materialization ↓ MYZ-193 — Canonical GitHub authentication ↓ MYZ-194 — Optional bounty bridge ↓ MYZ-195 — Zorgax to DevelopmentRequest preview ↓ MYZ-196 — Development user interface ↓ MYZ-197 — Public Knowledge integration The broader milestone status currently looks like this: M1 — Verified Knowledge Foundation Complete M2 — DevelopmentRequest Core In progress M3 — GitHub and Contribution Graph Bridge Not started M4 — Zorgax Development Product Not started M5 — Public Knowledge and Marketplace Not started The immediate goal is not to open more disconnected features. It is to complete the chain between a request, GitHub work, evidence, and public knowledge. Metaverse engineering roadmap The most important active Metaverse areas are: Authentication and sessions MYZ-71 This remains urgent because every other user-facing feature depends on a trustworthy identity and session layer. Privacy-safe analytics MYZ-55 We need useful product information without creating unnecessary surveillance. Analytics should answer questions such as:
• Are users able to enter the Metaverse?
• Where do flows fail?
• Are sessions stable?
• Which public experiences are being used?
• Are errors increasing? It should avoid collecting precise personal information that is not required. Rate limiting and abuse prevention MYZ-57 Public Metaverse services need protection from:
• Request floods
• Automated account creation
• Chat spam
• Repeated failed authentication
• Resource exhaustion
• Abuse of public endpoints Rate limits should be adaptive and should return understandable errors. Real-time communication MYZ-66 The real-time layer needs stable support for:
• Presence
• Room membership
• Movement updates
• Messages
• Reconnection
• Server restart recovery
• Duplicate-event protection Reliability and load testing MYZ-83 We need evidence that the platform behaves correctly under load. Testing should include:
• Concurrent connections
• Reconnection storms
• Slow clients
• Database latency
• Invalid tokens
• Revoked sessions
• Repeated events
• Graceful degradation End-to-end acceptance MYZ-84 After the security and reliability layers are stable, an end-to-end test should verify the complete public journey: Create or access an account ↓ Authenticate securely ↓ Enter the Metaverse ↓ Create or load a character ↓ Join a shared environment ↓ Interact in real time ↓ Open verified knowledge ↓ Create a development request ↓ Follow its evidence and delivery WebXR WebXR remains part of the roadmap, but it comes after authentication, abuse prevention, real-time reliability, and acceptance testing. A visually impressive immersive experience is not useful if account security or synchronization is unreliable. Marketplace blocker A separate urgent issue concerns enforcement of the free seller-listing limit. The server must prevent users from bypassing the listing limit, including during concurrent requests. The required work includes:
• Reproducing the problem server-side
• Enforcing the limit transactionally
• Testing concurrent listing creation
• Verifying authentication and ownership
• Removing test data from production
• Repeating the end-to-end seller test This blocks additional Marketplace work and must be resolved before expanding paid functionality. University and community pilots MyZubster also has an experimental university workflow. The intended pilot is: University ↓ Verified Knowledge ↓ Development Request ↓ GitHub ↓ Developer ↓ Community testing ↓ Evidence ↓ Independent verification ↓ New knowledge This is valuable because it connects education, software development, and public evidence. However, the pilot depends on completing the same core infrastructure:
• Development Requests
• GitHub issue creation
• Identity
• Contribution tracking
• Evidence
• Public Knowledge The pilot should not become a separate disconnected system. What we need to do next Our recommended order is: Phase 1 — Finish the current session-security slice
• Complete the MongoDB integration test
• Run the full affected authentication suite
• Review cookie and CORS behavior in production
• Verify the legacy-token migration
• Open a focused pull request
• Run CI
• Perform security review
• Deploy only after the review is green Phase 2 — Complete MYZ-71
• Implement refresh-token rotation
• Add token-reuse detection
• Add passkey or magic-link flows
• Add step-up authentication
• Build the session-management interface
• Add “log out all other devices”
• Document security behavior
• Run account-security acceptance tests Phase 3 — Fix production blockers
• Resolve the seller limit bypass
• Verify rate limits
• Verify public authentication providers
• Complete real-time reliability tests
• Confirm privacy-safe analytics Phase 4 — Complete DevelopmentRequest core
• Finish the data model
• Complete Jest and Node tests
• Run diff --check
• Integrate the work through an isolated branch
• Connect Development Requests to canonical GitHub issues
• Store delivery and verification evidence Phase 5 — Restore the complete Knowledge experience
• Configure the production database
• Verify the public Knowledge API
• Connect Knowledge to Development Requests
• Connect completed contributions to evidence
• Publish canonical documentation
• Add visible service health information Phase 6 — Expand the immersive Metaverse Only after the foundation is stable should we accelerate:
• WebXR
• Immersive rooms
• Spatial collaboration
• Interactive knowledge spaces
• University environments
• Community events
• Optional marketplace experiences What “done” should mean For MyZubster, a feature should not be considered complete because a page renders or an endpoint exists. “Done” should mean:
• The implementation is reviewed
• Tests are green
• Security behavior is documented
• Production configuration is correct
• Failures are visible
• Evidence is available
• The feature can be independently verified
• Users are not misled about its operational status That standard is especially important for identity, payments, rewards, public knowledge, and contributor commitments. Final thoughts MyZubster has a broad vision, but our immediate job is focused: strengthen the foundation. We are currently moving from bearer-only authentication toward persistent, revocable server-side sessions. The first focused test suite is green, the API structure is in place, and social login is being connected to the same session model. The work is not finished and is not being presented as finished. The next meaningful milestone is a reviewed and tested authentication pull request, followed by refresh-token rotation, passkeys, device management, rate limiting, real-time reliability, and end-to-end acceptance. After that foundation is stable, the Metaverse can grow into what we intend it to be: a shared environment connecting identity, knowledge, development, community participation, and verifiable outcomes. We welcome technical review, constructive criticism, testing, and contributions. The objective is not to move quickly at the cost of trust. The objective is to build something that can be inspected, tested, improved, and trusted.

5:09