Building the MyZubster Metaverse: From Public Characters to Secure World Actions
MyZubster is building an open-source metaverse that connects public characters, verified knowledge, contributor identities, realtime interactions, and GitHub-based development.
The project is not limited to a graphical virtual world. Its technical foundation is based on authenticated actions, explicit user consent, verifiable evidence, secure automation, and independently inspectable deployments.
This is a technical update on what we have implemented, what we recently stabilized, and what remains before the platform can be considered production-ready.
The Architecture
The current architecture follows this general flow:
MyZubster account
↓
Authenticated session
↓
Time-limited session lease
↓
Zorgax or metaverse character
↓
Authorized world action
↓
Realtime event distribution
↓
Persistent and verifiable evidence
Each state-changing request should answer four questions:
- Which account initiated the request?
- Is its session still valid?
- Which character is associated with that session?
- Is the requested action permitted?
This is important because a client-provided character ID cannot be considered proof of ownership.
The Public Metaverse
The public interface is available at:
https://www.myzubster.com/metaverse
Our latest production verification confirmed that the page loads correctly and exposes:
- 25 public characters
- 7 verified explorers
- A deployed Vercel production build
- No blocking browser-console errors
This public page represents the visible part of a larger system. Most of our recent work has focused on the security and infrastructure beneath it.
Session-Bound World Actions
World actions are being migrated to a session-bound authorization model.
The server must derive the acting identity from an authenticated session instead of trusting identifiers supplied by the client.
const session = await resolveAuthenticatedSession(request);
if (!session) {
throw new UnauthorizedError();
}
const lease = await resolveActiveLease(session.id);
if (!lease || lease.expiresAt <= new Date()) {
throw new SessionExpiredError();
}
const character = await resolveCharacterForAccount(session.accountId);
await authorizeWorldAction({
session,
lease,
character,
action: request.body.action,
});
This approach reduces the risk of:
- Character impersonation
- Cross-account actions
- Replayed requests
- Actions performed after logout
- Use of expired sessions
- Client-side manipulation of ownership fields
Authentication identifies the account. The session lease determines whether its authorization is still active. The policy layer determines which world actions are allowed.
Session Lease Lifecycle
An authenticated session should not provide unlimited access.
We introduced a lease lifecycle that can represent the following states:
CREATED
↓
ACTIVE
↓
RENEWED
↓
EXPIRED
ACTIVE
↓
REVOKED
A lease can be invalidated when: