Building the MyZubster Metaverse: Sessions, Verified Identities, CI Hardening, and the Road Ahead

Building the MyZubster Metaverse: Sessions, Verified Identities, CI Hardening, and the Road Ahead
MyZubster is evolving from a traditional community platform into an experimental open-source metaverse where people, contributors, knowledge, and software services can interact through verifiable identities and authenticated actions.
This article summarizes what we have implemented, what is currently operational, and what still needs to be completed before the system can be considered production-ready.
What We Are Building
The MyZubster Metaverse is designed as a connected environment composed of several layers:
User identity
↓
Authenticated session
↓
Metaverse character
↓
World actions
↓
Realtime services
↓
Verified Knowledge and Zorgax
↓
GitHub contributions and Development Requests
The goal is not simply to render a virtual world. We want every relevant action to have a verifiable context:

• Who initiated the action?
• Which session authorized it?
• Which character represents the user?
• When does the authorization expire?
• Which backend service accepted the action?
• Can another participant independently verify the result? Public Metaverse Interface The public Metaverse page is available at: https://www.myzubster.com/metaverse The interface currently exposes the public layer of the ecosystem, including registered characters and verified explorers. During our latest production verification, the page loaded correctly with:
• 25 public characters
• 7 verified explorers
• No blocking browser-console errors
• Successful Vercel production deployment This public interface is only one part of the system. The most important work has been happening underneath it: authentication, session isolation, action authorization, workflow reliability, and contributor identity integration. Binding World Actions to Session Credentials One of the most important architectural changes is the transition from anonymous or loosely identified requests to session-bound world actions. A metaverse action should not be accepted only because the client sends a character identifier. The backend must derive authority from a trusted session. The intended request flow is: Client → authenticated request → session credential validation → active lease verification → character ownership resolution → action policy validation → world-state mutation This prevents a client from impersonating another character merely by changing an identifier in the request payload. The server-side authority model follows a rule similar to: const session = await resolveAuthenticatedSession(request);

if (!session) {
throw new UnauthorizedError();
}

const lease = await getActiveSessionLease(session.id);

if (!lease || lease.expiresAt <= new Date()) {
throw new SessionExpiredError();
}

const character = await resolveCharacterForSession(session);

await authorizeWorldAction({
session,
lease,
character,
action: request.body.action,
});
The important principle is that identity must be derived from the authenticated context—not trusted directly from client-controlled fields.
Session Lease Lifecycle
Persistent sessions are useful, but unlimited sessions are dangerous. We therefore introduced a session-lease model.
A lease represents the limited period during which a session may perform metaverse actions.
Conceptually, the lifecycle is:
CREATED
↓
ACTIVE
↓
RENEWED ─────┐
↓ │
EXPIRED │
↓ │
REVOKED ←────┘
A lease can become invalid because:

• Its expiration time has passed.
• The user logged out.
• The account was disabled.
• The credential was rotated.
• The session was explicitly revoked.
• A security policy invalidated older sessions. World-action endpoints must reject expired or revoked leases even when the original session cookie or token is still present. This creates a clear separation between:
• Authentication: proving which account initiated a request.
• Authorization: deciding which action that account may perform.
• Lease validity: determining whether the authorization is still active. Zorgax and Contributor Identities Zorgax is the identity and knowledge layer connecting public contributor profiles, GitHub activity, Knowledge Cards, and metaverse characters. The current model distinguishes carefully between:
• A public GitHub alias
• A MyZubster account
• A professional profile
• A metaverse character
• A verified external identity These concepts must not be treated as interchangeable. A GitHub-connected contributor can be represented as a proposed character, but this does not automatically imply:
• Legal identity verification
• Employment
• Ownership
• Partnership
• Payment eligibility
• Institutional endorsement Character onboarding therefore uses an explicit opt-in process. A proposed character remains in a draft state until the contributor accepts it. GitHub contribution ↓ Optional character proposal ↓ Explicit contributor acceptance ↓ Registered public character This protects contributors from being automatically represented in the metaverse without consent. Distributed Rate Limiting Authentication alone is not enough. Authenticated clients can still generate excessive traffic, spam actions, or create concurrency problems. The Metaverse roadmap includes distributed rate limiting for:
• Authentication attempts
• Session creation and renewal
• Character movement
• World interactions
• Realtime messages
• Profile updates
• Public API searches A local in-memory rate limiter is insufficient when several application instances are running. Each instance would maintain a different counter. Production enforcement must therefore use shared state: Client requests ↓ Vercel or application instances ↓ Shared rate-limit backend ↓ Atomic counter and expiration The rate-limit key should combine the smallest amount of information required by the policy: const key = [ "metaverse", actionType, sessionId, accountId, ].join(":"); IP addresses should be used carefully. They can be useful for abuse prevention, but they are personal data and may group unrelated users behind the same network. Realtime Architecture The next major layer is realtime communication. The Metaverse will eventually require:
• Presence updates
• Character movement
• Interaction events
• Session revocation propagation
• World-state synchronization
• Reconnection and missed-event recovery A robust realtime system cannot assume that messages arrive exactly once or in order. Each event should include enough information to detect duplicates and stale updates: { "eventId": "evt_01...", "worldId": "myzubster-main", "characterId": "character_...", "sessionId": "session_...", "sequence": 1842, "type": "character.position.updated", "occurredAt": "2026-10-19T04:50:00.000Z", "payload": { "x": 12.4, "y": 0, "z": -8.1 } } The client should be able to reconnect with its last accepted sequence number and request any missing state. GitHub Actions and Node.js 24 We also completed an important CI modernization. GitHub reported that older JavaScript actions were still using the deprecated Node.js 20 runtime. We updated the affected workflows:
• uses: actions/checkout@v4
• uses: actions/setup-node@v4 to:
• uses: actions/checkout@v5
• uses: actions/setup-node@v5 The update covered:
• 12 workflow files
• 26 action references
• CI and lint
• Security auditing
• SBOM generation
• Vercel deployment
• Continuous evidence validation
• Seller policy regression tests
• MYZ ledger verification
• Pilot API tests
• Decentraland SDK7 proofs Before publishing the change, we verified that:
• All 16 workflow YAML files parsed successfully.
• No affected v4 references remained.
• Only files under .github/workflows were modified.
• Workflow triggers, permissions, jobs, and commands remained unchanged. The change was published through Pull Request #38 and squash-merged into main. Final production commit: 69ef67716df50482e8fbf9960ccab7dfc37d3000 Post-Merge Verification The merge triggered a complete verification cycle on main. All seven post-merge workflows completed successfully:
• CI — Test and Lint
• Security Audit
• SBOM and Vulnerability Scan
• Continuous Evidence Gate
• MYZ Canonical Ledger Contract
• MYZ-164 Seller Free Policy
• Deploy to Vercel The Vercel deployment also completed successfully. This matters because updating a GitHub Action runtime can affect checkout behavior, dependency caching, authentication, build paths, and artifact handling. The post-merge results confirmed that the new runtime did not introduce an observable regression. What Is Already Working The current verified baseline includes:
• A deployed public Metaverse interface
• Public characters and verified explorers
• GitHub-connected contributor identities
• Optional Zorgax character proposals
• Session-based authorization work
• Session lease lifecycle enforcement
• Knowledge and profile integration
• Security and SBOM automation
• Continuous evidence checks
• Automated Vercel deployment
• Node.js 24-compatible GitHub Actions What Still Needs to Be Completed
• Complete Authentication and Session Enforcement Every state-changing metaverse endpoint must use the same canonical authentication path. We still need to verify:
• Logout revocation
• Credential rotation
• Concurrent sessions
• Expired leases
• Disabled accounts
• Cross-account character access
• Replay attempts
• Finish Distributed Rate Limiting The policy must be enforced through a shared backend and tested across multiple application instances. Required tests include:
• Boundary requests
• Concurrent requests
• Retry behavior
• Counter expiration
• Fail-open versus fail-closed behavior
• Recovery when the shared backend is unavailable
• Complete Realtime Synchronization Realtime work must include:
• Presence
• Movement
• Interaction events
• Reconnection
• Missed-event recovery
• Duplicate suppression
• Ordering guarantees
• Backpressure handling
• Add Privacy-Safe Analytics We need operational visibility without unnecessarily collecting personal information. Useful metrics include:
• Active sessions
• Lease-renewal failures
• Realtime disconnections
• Rejected actions
• Rate-limit activations
• World-state latency
• API error rates Sensitive identifiers should be minimized, truncated, aggregated, or pseudonymized.
• Reliability and Load Testing Before expanding the public experience, we need repeatable tests for:
• Concurrent users
• Character movement bursts
• Realtime fan-out
• Session-store latency
• Rate-limit contention
• Backend restarts
• Partial infrastructure failure
• Deployment rollback
• End-to-End Acceptance Testing The complete user journey must be tested: Sign in → create or select a character → establish a session lease → enter the metaverse → perform an authorized action → receive a realtime update → reconnect → recover state → log out → confirm the session can no longer act
• WebXR WebXR remains a later milestone. It should be introduced only after authentication, realtime communication, abuse prevention, and reliability are stable. Adding an immersive client before stabilizing these layers would only make the system harder to secure and debug. The Current Priority Order Our recommended implementation sequence is:
• Authentication and session enforcement
• Distributed rate limiting
• Realtime synchronization
• Privacy-safe analytics
• Reliability and load testing
• End-to-end acceptance
• WebXR client Conclusion The MyZubster Metaverse is no longer only a visual concept. It now has an increasingly concrete technical foundation built around authenticated sessions, explicit contributor consent, verifiable identities, automated security checks, and reproducible deployments. There is still substantial work ahead. Realtime synchronization, distributed abuse protection, complete session enforcement, load testing, and WebXR are not finished. Our objective is to publish progress without presenting experimental components as completed production systems. Each milestone should be supported by source code, automated tests, deployment evidence, and independently inspectable results. That is how we want to build the MyZubster Metaverse: incrementally, transparently, and with verifiable evidence.

6:56