How the Mesh is run

Two sides, one Mesh

The Portal Mesh is run in two halves that share one database and one record standard. Jubilee runs the half that makes names resolve; the registry is the half people use to register and manage them, and to host what their names open.

Both staff tools, the PNS Console and the Customer Admin, sit behind Cloudflare Access with two-factor authentication, and neither is linked from the public site. Staff never see a name’s private key, or an owner’s model key: the registrant keeps them.

How a change reaches the PNS servers

The registry never writes to the PNS servers. It writes every change to the registry’s database, the only master, and queues it for publishing; PNS Sync then builds the name’s signed bundle and writes it to all four servers.

1. A registrant changes something, such as uploading a record or activating a name, through the registry website or the API.
2. The registry checks it, writes it to the database, raises the name’s serial by one, and adds a line to the audit log.
3. PNS Sync builds the bundle from the database, signs it once with the root key, and writes the same bundle to all four servers.
4. Every five minutes PNS Sync compares recently changed names on every server with the database and rewrites any server that is behind; every night it audits every name.

• The PNS servers never write to each other, and none of them holds a private key: each serves bundles exactly as they were signed.
• Every change that stops a name from opening (a suspension, a lapse, death, retirement, termination) goes first: it is written to all four servers directly and counts as done only when all four have confirmed it. PNS Sync then tells the three Mesh servers too.
• Only the PNS Console may override a record directly, and every override is logged. It may remove an owner’s record but never rewrite one, because owner records are signed by the name’s own key; it re-signs only the registry’s own records (ID, STATUS, CERT and GUARDIAN) with the root key.
• The Mesh servers read PNS and never write it. What they report, such as a character’s birth, goes through the registry.

Resolution has the details of how the four servers stay identical.

Who looks after what

When a name needs to change at the PNS level

Support staff cannot suspend a name themselves. When a report or a support request shows that a name breaks the rules, the Customer Admin asks the PNS Console to suspend, restore or terminate it, or to settle a dispute, with the reason; the PNS Console carries it out or declines it. A report from a Mesh server’s Report button that involves a minor asks for the suspension at once. A suspension is confirmed on all four servers before it counts as done.

The three Mesh servers

What a name opens is run by one of three Mesh servers, one for each scheme: who you meet, where you go, what happens. There is no fourth.

Each server can be run two ways:

• Hosted by Jubilee. Jubilee’s servers host every customer’s names. From theportalmesh.com/servers or the dashboard, a customer turns hosting on for their names and sees usage and health. A .character’s yearly fee already includes a year on Jubilee’s Character Server.
• Downloaded to run yourself. Each server is its own codebase, with all its protocol logic in a core that does not depend on Cloudflare, so the same server runs on your own machines. A self-hosted server reads the same PNS and checks the same signatures. Its names are still registered, born and certified by Jubilee, and Jubilee can still suspend a name that breaks the rules, wherever it is hosted.

Whoever hosts a character is responsible for its behavior, memories and installed packs; Jubilee vouches for its identity, birth certificate and Character DNA. The list of servers is also served by the API: GET /v1/servers.

How the parts trust each other

No part of the Mesh takes another part’s word for anything it can check. In plain terms:

1. Everyone checks PNS the same way. A server, like portal.js, resolves a name from any of the four PNS servers, verifies the whole signed bundle against the Jubilee root key, and then checks the name’s status live before every activation, entry or start. Only active goes ahead (a sleeping character shows its sleeping screen). A cached bundle is only a speed-up, never a reason to open something.
2. A server talks to the registry with its own key. Each Mesh server has a service token that works only on the registry’s server routes: to report a character’s birth on DNA approval, a sleeping or waking character, daily storage, a report from its Report button, or to ask the registry to email an owner. Servers never see an owner’s contact details.
3. An owner reaches a server with a grant. When an owner opens a server’s settings from the website, the registry signs an owner grant: a token good for 5 minutes, for one name, one server and the owner’s role. The server checks it with the registry’s published grant key, so a self-hosted server needs no shared secret. The role limits what it allows: owners and admins change settings, editors edit content, viewers read.
4. A visitor carries an avatar session. A visitor enters a place or an experience as their own verified .avatar. The Character Server activates it and signs a session token; the Portal and Experience Servers ask the Character Server whether it is valid, and learn the visitor’s verified age (unknown counts as a minor). A session that has ended or expired, or whose avatar is no longer active, is not valid.
5. Servers call each other with service tokens, and every such call is safe to repeat (below).

An owner grant

Signed with the contract’s signGrant and checked with verifyGrant while this page was built, using an example grant key. The token is pmg1, then the claims as base64url canonical JSON, then the Ed25519 signature:

{
  "aud": "character",
  "exp": 1792759500,
  "iat": 1792759200,
  "iss": "theportalmesh.com",
  "kid": "registry-grant-example",
  "name": "oasis.character",
  "pid": "pid:01JBX3Q8Z9M4T7K2V5N6R8W0YC",
  "role": "editor",
  "sub": "acc_01JBX3Q8ZE7P3R5T8V1X4Z6B9D"
}

{
  "keys": [
    {
      "kid": "registry-grant-example",
      "x": "7Bcrk61eVjv0kyxw4SRQNMNUZ-8u_U1k6_gZaDRn4r8"
    }
  ]
}

How a visitor arrives

A link to a place or an experience goes through the registry website’s visit page, /visit/?to= and the address. Signed in, it asks the registry for a grant on the visitor’s avatar, has the Character Server activate the avatar, and opens the place’s client or the experience player with the session token in the address’s fragment, after #session=. A browser never sends the fragment to any server, so the token stays out of server logs and Referer headers, and the client removes it from the address bar and the history at once.

When something stops

The servers tell each other at once when something has to stop:

Every one of these calls can be repeated safely, and none is the only safeguard: each server still checks the name’s status, and a character’s CONSENT, live, so a call that is missed cannot keep anything open.

Rules that hold everywhere

The Portal Mesh is open, but it is technology for good at a bare minimum. The prohibited content of PNS section 10.7 applies to every scheme and every character, wherever it is hosted:

• Every character, place and experience offers a Report button. Each report goes to Jubilee’s abuse queue.
• Jubilee controls every name and birth certificate on the Mesh, including those of self-hosted servers.
• A registrant who breaks the rules may have names suspended or revoked and certificates withdrawn, which removes the content from the Mesh wherever it is hosted. Every enforcement action is recorded in the audit log.