Project
Status and changelog
What is built, what has been proved, where the registry filled gaps in the standard, and what is still open. As of October 24, 2026.
On this page
What is built
As of October 24, 2026. A part is called accepted only when its acceptance test has run and passed. Every test so far runs against a complete local copy of the system, both sides and all four PNS servers included; nothing is deployed yet.
| Part | State |
|---|---|
| PNS Record Standard | Version 2.0. PNS Record Standard, Version 2.0, proposed, not an adopted standard. |
| The customer side: the shared rules, the Registry API and portal.js | Built and accepted on the v2.0 standard (phases 18 to 23 and 39). At the last recorded full run, 174 of 174 end-to-end checks passed, with the Jubilee side loaded too, and 88 of 88 unit tests for the shared rules, 3 of 3 for portal.js and 59 of 59 for the Registry API. Typechecks clean. |
| The Jubilee side: the four PNS servers, PNS Sync and the PNS Console's API | Built and accepted on the v2.0 standard (phase 19): 17 of 17 of its own end-to-end checks passed. |
| The Mesh servers: Character, Portal and Experience | Built, each in a workspace of its own, all five phases each, with their own suites passing; each also runs on Node to host it yourself. See below. |
| The whole Mesh together | Accepted (phase 39): the cross-server acceptance run drives the registry, the four PNS servers, the PNS Console and the three Mesh servers as they run together on one machine, over HTTP and WebSockets. Every step passed: Silo the Squirrel born on his Character DNA review, talking, asleep on a spent key and awake again; a visit to a destination at 30 AD with Silo as its greeter; a .history experience with Silo cast on his Guardian's consent, which he leaves at once when it is withdrawn while the story plays on; and suspensions in the PNS Console closing everything. |
| The registry website and the Customer Admin | Built for v2.0 (phase 23): prices, the realm application, the character registration and DNA steps, every status with what to do, guardianship and succession, transfers through Jubilee, visiting with an avatar, the character's memory, voices and robots, hosting and downloads; and in the Customer Admin, charters, account reviews, transfer approvals and death reports. Their builds pass; they are not yet tried in a browser. |
| These docs | Updated for v2.0. 234 example checks passed when this copy of the site was built. |
| Deployment | Nothing is deployed. Domains, cloud resources, live payment keys, the mail service and the Jubilee ID client registration come first. |
The build phases
| Phase | Scope | Done when | What the test proved |
|---|---|---|---|
| 1 | Accounts, search, registration, test payments, birth certificates for .character | jubileeinspire.character is registered and its certificate verifies | 12 of 12: registered by Jubilee Software, Inc. as AI Employee, test payment, certificate verified, keepsake PDF, persona fingerprint. |
| 2 | Publishing, PNS resolver, activation, portal.js, public lookup | activate://jubileeinspire.character resolves from all four PNS hosts and activates on two devices | 14 of 14: all four PNS hosts, two devices through portal.js, failing closed, rebuild on a cache miss, reconciliation, key rotation, the retirement tombstone. |
| 3 | .agent, .avatar, the environments, identity and organization verification, teams | A verified avatar and a verified business are live | 9 of 9: a verified avatar and a verified business live, an agent's permitted actions, team roles, evidence deleted on decision. |
| 4 | .realm, .destination, .experience (since replaced by experience://), time frames | portal://jerusalem.destination?time=now resolves with a default and fallback | 6 of 6: the default and nearest-frame fallback, SOURCE review, an experience. |
| 5 | .figure review, movies, music and books, rights checks, live payments | A reviewed figure and a book are live; payments are live | 7 of 7: a reviewed figure and a book live, refunds, and the switch to live payments refusing to run without live keys. Live keys are the owner's to provide. |
“Live” in these tests means active and resolving in the local system. These five phases were built on Draft 0.1 of the standard; every one of their suites still passes on v2.0.
Added since the five phases
| Addition | What the test proved |
|---|---|
| Email (O-16, D-33) | 5 of 5: a team invitation, a transfer offer with the owner's notice and completion, and renewal reminders 30, 7 and 1 days ahead, each delivered once; a failing mail service retried with backoff, the message text cleared once delivered, and a refused message marked failed. |
| Automatic renewal (O-14, D-34) | 7 of 7: the card saved at checkout by default; the reminder names the card; the name renews itself a day before expiry, once, with a receipt; a declined card retried after 3 days, the owner told each time, stopping after 3; removing the card turns renewal off everywhere; refused when registrations do not expire. |
| Domain proof (O-13, D-35) | 6 of 6: proof by TXT record, subdomains refused; priority over an unfinished registration, with a notice and a refund of a late payment; nothing for a look-alike domain, a second matching domain, or against a paid name; a reservation held for a domain registered by its owner; lapse after three misses a day apart, a lookup outage not counted, restored by checking again. |
| Key rotation and recovery (O-15, D-36) | 4 of 4: a standard name recovered after email confirmation and the 72-hour wait, then activated with its new key; a recovery canceled by the email link and by a rotation with the current key, and lapsing when never confirmed; an avatar recovered only after a reviewer approved fresh evidence, which was then deleted; an account recovery moved the name only on a reviewer's decision, and its holder was told. The phase 2 suite proves a rotation without the current key's signature is refused. |
| The Customer Admin’s API (D-39 to D-45) | 13 of 13: a customer's profile and full timeline; a read-only view of an account that its owner then sees; support requests answered by email, with notes the customer never sees; reports about names; credit that pays a registration without Stripe; stuck payments finished and refunds with a reason; a two-factor reset only with a record of the identity check; merging and closing accounts; hosted server requests; and each staff role reaching only its own work. |
| The two sides (D-37 to D-47) | 5 of 5, the owner's acceptance tests for the split: all four PNS servers return identical bundles; a record changed in the PNS Console is on all four within 5 minutes; a suspension asked for in the Customer Admin is carried out by the PNS Console and confirmed on all four; the Customer Admin cannot change a PNS record; a registration charges the price of the day ($3, before v2.0) in Stripe test mode. |
Version 2.0
The registry and PNS were brought to the v2.0 documents in five phases, each accepted on its own test:
| Phase | Scope | What the test proved |
|---|---|---|
| 18 | The contract: seventeen namespaces, the experience:// scheme, the four families, the v2.0 prices and statuses, GUARDIAN and experience CONSENT, the Character DNA and its fingerprint, classes and labels, short subname labels, display names | The shared rules' unit tests, 86 of 86, cover the scheme lock, the statuses, GUARDIAN, the DNA fingerprint and the labels, and apply every database migration; every earlier suite passed on seventeen namespaces (124 of 124). |
| 19 | The Jubilee side on v2.0: seventeen namespace databases, tombstones and STATUS for dead, resting and released | 17 of 17 of the PNS side's end-to-end checks, and the cross-side split suite. |
| 20 | Money and the rules against squatting: yearly prices with a free path, the realm application, verified accounts, the account review, transfers through Jubilee, the live deadlines | 10 of 10: a .character registration charges $20; a .realm application holds $1,000 until approved and is captured on approval, or released on rejection; the rules against squatting hold. |
| 21 | The lapse path: dormant, dead, resting, released; no resurrection; sleeping | 4 of 4: dormant after the grace period and revived by renewal; a year dormant it dies, with a death certificate and a tombstone on all four servers, rests, and is released; a released address registered again gets a new PID, and the lookup lists the former names. |
| 22 | Characters and the servers' side of the registry: classes, gender, affirmations, labels, the Responsible Guardian, GUARDIAN, succession, the server routes, owner grants, birth on DNA approval | 13 of 13: a Family pet and a Worker character are born with the right labels, GUARDIAN and DNA fingerprint on the certificate, and the birth email carries the certificate and the DNA; then the full run, 151 of 151. |
| 23 | The website, the Customer Admin and these docs at v2.0, with the follow-ups they found: a character transfer on the registration's terms, a Worker's Responsible Guardian replaced, the Character DNA rules of the standard, hosting and downloads | The full run, 174 of 174, with the website's and the servers page's own checks; the three site builds pass, these docs with every example check. |
| 39 | The whole Mesh: the registry, PNS and the three Mesh servers running together on one machine | The cross-server acceptance run, every step: Silo the Squirrel from sign-up to birth, talking, sleeping and waking, consent withdrawn; a destination at 30 AD with a reviewed scene and Silo as greeter; a .history experience with Silo cast and leaving when his consent is withdrawn; suspensions closing everything. It found and fixed two defects only the live system could show: the local runners' outbound calls, and a runner missing three namespaces. |
The Mesh servers
The Character, Portal and Experience Servers are built, each in five phases, each phase on its own suites. Together with the registry and PNS they are accepted by the cross-server acceptance run (phase 39). Each talks to the registry and the others through the calls of the servers interface, and each was tested on Cloudflare's local runtime and on Node.
| Server | Built | Its own tests at the last run |
|---|---|---|
| Character Server | All five phases: birth on DNA review (a 17-year-old humanoid refused); activation with its nine checks, conversations, sleeping and waking; memory, voices, avatar voice cloning and VR; robots, the daily job, consent and the servers' calls; the Node version to host it yourself. | Core 26 of 26, the Node version 17 of 17, end-to-end 63 of 63. |
| Portal Server | All five phases: entry with a verified avatar, age gates, failover across the four PNS servers; rooms with presence, chat and voice; destinations with time frames, source labels and reviewed scenes; realms with charters, nesting and time portals; characters inside places; the Node version. | Core 62 of 62, the portal client 22 of 22, the Node version 22 of 22, end-to-end 43 of 43. |
| Experience Server | All five phases: the script format, Psalm 23 played start to finish, the start flow, cast consent bound to the script's hash; sessions in step for many visitors; publishing with review, reserved events, rights and films; the Node version. | Core 40 of 40, the Node version 6 of 6, end-to-end 71 of 71, and the same suites on the Node version 60 of 60. |
Each server can be downloaded from the servers page to host it yourself, as its Node version. None of the servers is deployed.
Changelog
| Date | Change |
|---|---|
| October 24, 2026 | The docs now present the PNS Record Standard, Version 2.0: seventeen namespaces in four families, three schemes with experience://, yearly prices and the realm application, the rules against squatting, the GUARDIAN record and experience CONSENT, the v2.0 statuses and tombstones, and Bible addresses. New pages: Characters (classes, labels, the Character DNA and its fingerprint, birth, succession) and The life of a name. How the Mesh is run now covers the three Mesh servers and how every part trusts the others, and the Registry API page covers charters, births on DNA review, transfers through Jubilee, owner grants and succession. |
| October 24, 2026 | The registry added email, automatic renewal, domain proof, signed key rotation and recovery, support requests, reports about names and requests for hosted servers, and the Mesh was split into the Jubilee side on portalmesh.net and the customer side on theportalmesh.com. These docs gained How the Mesh is run, and the Registry API page now covers every new route, the pm.key-rotation/1 proof, domain proof and the email the registry sends. |
| October 23, 2026 | First publication of these docs: the PNS Record Standard, Draft 0.1 (revision 16), rendered in full, and developer documentation for the registry as built on this date. Every example on these pages is generated and verified by the registry’s own code when the site is built. |
Where the registry filled gaps
Where the standard or the Registry Website Specification is silent, or the two disagree, the build made a decision. Each is current registry practice, not part of the standard, and can be reversed when the owner rules or the standard is revised.
| What the registry does | Why | |
|---|---|---|
| D-5 | Two-factor authentication through the registry's own TOTP step-up, until Jubilee ID issues a second factor itself. | Two-factor is required for every registrant, and Jubilee ID does not yet provide one. |
| D-6 | Each name carries a serial, its current version, which every bundle carries. | Bundles need a version to compare; the guide's schema had none. |
| D-11 | Replaced in v2.0 by D-50: STATUS now publishes every state of the standard, and born for a name not yet active. | PNS section 4 defines the states. |
| D-12 | Rights statements, content ratings and media packages for movies, music and books are TXT records with a kind. | The standard has no record types for them. |
| D-13 | An agent’s permitted actions are permittedActions in its ENDPOINT record, required. | The specification requires the list; the standard has no record for it. |
| D-14 | The persona fingerprint is SHA-256 over a persona package that holds a public profile and hashes of the sealed sources. | The standard does not say what the PERSONA hash covers. |
| D-15 | Key ids: a configured id for the root key, <pid>#k<n> for a name’s keys. | Rotation needs old and new keys told apart. |
| D-18 | Registration caps are settings: 10 new names per namespace per 30 days, 100 for a verified organization, one primary avatar plus four contextual ones. | The exact caps are open. |
| D-19 | Identity and organization verification are reviewed by Jubilee in-house, and the evidence is deleted on decision. | The build guide supersedes the specification's third-party service for version 1. |
| D-20 | Look-alikes: NFKC, no non-ASCII in version 1, and an ASCII skeleton compared within each namespace; a collision goes to review. | The specification asks for look-alike protection without defining it. |
| D-21 | Time frames use a provisional grammar and the nearest offered frame, ties to the earlier. | The standard leaves the time format open. |
| D-22 | Sessions are cookies on .theportalmesh.com, and browser writes must come from the registry’s own sites. | The website and the API are sibling hosts. |
| D-23 | Public files are served by the registry from files.theportalmesh.com, a fixed list of public prefixes; the storage bucket itself is never public. | The bucket also holds verification evidence, which must never be fetchable. |
| D-24 | An experience’s cast list, guided script and content rating are TXT records of kind cast, script and rating. | The specification requires them; the standard has no record for them. |
| D-25 | Holding a reserved name never skips a review the namespace requires: tragedies are reviewed for everyone, and every figure is reviewed. | PNS sections 10.6 and 11.3. |
| D-26 | The session handshake is pm.session/1: a signed answer to a fresh challenge, checked against the certificate. | The specification requires signed sessions; the Portal Protocol itself is not yet specified. |
| D-28 | The private key file is pm.name-key/1: the seed sealed with AES-256-GCM under PBKDF2-SHA-256. | The key must be downloadable, passphrase-protected, and unrecoverable by Jubilee. |
| D-30 | The verification level an administrator sets for a namespace is the one the registry enforces, everywhere. | Administrators may change a namespace's level; the code's level is only the default. |
| D-33 | Email is an outbox: each message is written together with the change it reports, sent once, and retried when the mail service fails. A delivered message’s text is cleared, because it carries one-time links. See Email. | Mail is then exactly as reliable as the change it reports, and any mail service can be plugged in at launch. |
| D-34 | Automatic renewal is on by default: the card saved at checkout is charged a day before expiry, a decline is retried three days later up to three times, and the owner is told each time. One card per account; a name that changes hands starts with it off. See Automatic renewal. | The specification asks for automatic renewal by default. |
| D-35 | Matching-rights priority by domain proof: a TXT record at _portalmesh.<domain>, rechecked every 30 days and lapsing after three misses. A verified matching domain comes before an unfinished registration, never a paid one. See Domain proof. | It automates what a DNS record can prove and leaves to people what it cannot: trademarks, and disputes over a paid name. |
| D-36 | A key rotation is signed by the key it replaces (pm.key-rotation/1). A lost key is recovered at the namespace’s registration level: an email confirmation and a 72-hour wait, or a reviewer on fresh evidence. A lost account is always a reviewer’s decision. See Recovery. | The specification requires lost-key recovery at the same verification level as registration; before this, taking over an account was enough to replace a name's key. |
Two smaller additions are marked on the pages where they apply: the reserved label time, and the labels AI Avatar and AI Historical Figure.
The two sides
The owner’s update to the build guide split the Mesh into a Jubilee side and a customer side. These decisions carry it out; see How the Mesh is run.
| What the registry does | Why | |
|---|---|---|
| D-37 | Two sides. The Jubilee side, on portalmesh.net, runs the four PNS servers, PNS Sync and the PNS Console. The customer side, on theportalmesh.com, runs the registry, the dashboard, the Customer Admin and hosted servers, and publishes these docs. | The owner's update: the Jubilee side keeps the Mesh resolving; the customer side serves the people who register names. |
| D-38 | The record standard's code, the operations both sides share and the database schema have one home, with the registry. The Jubilee side works from a checked copy and refuses one that has drifted. | Both sides use the same databases and formats, so each must have exactly one source, and drift must be caught, not hoped against. |
| D-39 | The PNS Console looks after records, reserved names, namespaces, name reviews, rights disputes, status actions, sync and the root key. The Customer Admin looks after customers, registrations, billing, verification, recovery reviews, support, reports, domain proofs and hosted servers, and cannot change a PNS record. | The owner's update. A recovery is the customer's own request checked by a person, so it stays beside identity verification. |
| D-40 | An escalation is the only way the customer side asks for a PNS change: suspend, restore, terminate or a dispute, with a reason. The PNS Console carries it out or declines it, and a suspension is confirmed on all four servers. | Only the PNS Console may change records directly, and every change it makes is logged. |
| D-41 | The two staff tools keep separate staff lists and separate sign-in protection, each with its own roles. | Customer support never reaches the PNS. |
| D-42 | Each staff tool's API is served from the tool's own address, so one sign-in protects the tool and its API together. | Simpler, and safer, than carrying a staff sign-in across addresses. |
| D-43 | Hosted servers are recorded requests until the server guide: customers ask for one, and staff see them. | Building the servers is a separate guide; nothing pretends a server is running. |
| D-44 | Account credit, granted by billing staff with a reason, is spent first at the next checkout or renewal; when it covers the price, nothing is charged. | The owner's update asks for credits. |
| D-45 | Customers open support requests from the website, and anyone can report a name. When support views an account as its owner sees it, the view is read only, logged, and shown to the owner. | The owner's update asks for support and abuse handling, and a view-as-customer that the customer can see. |
| D-46 | Local development and the acceptance tests run both sides together as one Mesh. | The Mesh is one system; its acceptance tests need both halves. |
| D-47 | The registry's earlier admin console became the Customer Admin, without any PNS actions. | The owner's update moves every PNS action to the PNS Console. |
Version 2.0
The owner’s v2.0 documents are the authority from October 24, 2026. Where they leave a gap, the build decided as follows; each is marked on the page where it applies.
| What the registry does | Why | |
|---|---|---|
| D-48 | The three Mesh servers are three codebases of their own, each with its own database, staff console and a core that does not depend on Cloudflare, tested together with the registry and PNS. | Each server must be downloadable to run yourself. |
| D-49 | The rules against squatting: every account verified before its first paid registration (identity_required); an account review past about ten names (account_review); transfers started by the holder, accepted by the recipient and approved by Jubilee at cost, with both affirming no money changed hands; names live within 90 days, a realm’s destination within six months. See Namespaces. | PNS section 13 states the rules; the details are the registry's. |
| D-50 | The status model: born, active, sleeping, suspended, dormant, dead, resting, released, retired and terminated, published as STATUS; born for a name not yet active. A character with no living Guardian is GUARDIAN paused, not a status. Retired and terminated addresses are held forever. See The life of a name. | PNS sections 4, 9 and 15. |
| D-51 | Identity verification keeps the person's birth year and nothing else from the document; a visitor's age is counted so that an age limit is never met early. | Places and experiences gate on a visitor's verified age; the registry keeps only results. |
| D-52 | A realm files a charter, and its $1,000 is held on the card, not charged, until Jubilee decides by hand. See the realm application. | PNS section 13: a realm is an application, not a checkout. |
| D-53 | Prices are the namespace table's, as the standard sets them; a free name completes without payment. Character storage past 50 GB is billed monthly. | PNS sections 13 and 14. |
| D-54 | The lapse path: 30 days' grace, a year dormant, dead with a death certificate and 30 days to export memory, a year resting, then released. A name that never went live is released at once. No resurrection. | PNS section 15. |
| D-55 | A label beneath a registered name may be one character, so 23.psalms.jsv.book works; bible.book is reserved by Jubilee; the standard subdomain labels are published as conventions; a display name is stored apart from the address. | PNS sections 10.1 and 15. |
| D-56 | A person's character is Family, an organization's is Worker. Family labels follow the DNA; a Worker's label is AI and the organization's title. The affirmations are kept, word for word. | PNS section 11.1. |
| D-57 | Replaced by D-77. A character's birth: the owner answers its DNA questionnaire and sends its key; a Jubilee reviewer approves on the Character Server, which reports the DNA fingerprint; the registry births the name and emails the certificate and the DNA. | PNS section 11.1, the birth process. |
| D-58 | GUARDIAN is a registry-signed record of display names only; an experience CONSENT is an owner-signed record per experience, slot CONSENT:<experience>, bound to the script’s hash. See Records. | PNS sections 4 and 10.8 name the records without their fields. |
| D-59 | Servers reach the registry with service tokens; owners reach servers with five-minute owner grants checked against a published key; visitors carry an avatar session. See How the Mesh is run. | A self-hosted server must be able to check an owner without a shared secret. |
| D-60 | Owner model and voice keys are encrypted per account and never shown, logged or kept in plain form; local stand-ins replace real providers in development. | PNS section 14. |
| D-61 | Local ports for the three servers and their consoles. | Development only. |
| D-62 | Jubilee's hosted servers serve every customer's names; a customer turns hosting on from the registry, or downloads the server. | The owner's update: hosted or self-hosted. |
| D-63 | The registry website takes the look of the owner's design. These docs keep the house gold. | The owner's design. |
| D-64 | A Worker character's Responsible Guardian is named, with the affirmation, when the organization registers it. | Organization members have no identities of their own yet (O-26). |
| D-65 | Replaced by D-77. A character is never born by its owner's request: its key waits for the DNA review, and the label and role come from the DNA. A humanoid under 18, or a gender that differs from the registration, is refused. | PNS section 11.1. |
| D-66 | Succession: a designation like a will, a death report confirmed by Jubilee, the successor's own affirmation, and retirement after 180 days with nobody stepping in. | PNS section 11.1: a character never seeks its own sponsor. |
| D-67 | A report that involves a minor asks for the name's suspension at once, while it is reviewed. | PNS section 10.9. |
| D-68 | Storage overage is billed per account, monthly, credit first, then the card on file. | PNS section 14. |
| D-69 | The servers’ calls to each other: suspend from PNS Sync on every status that is neither active nor born, consent withdrawn, deactivate, close and cast left. Each is safe to repeat, and each server still checks live. See When something stops. | The guides name the outcomes but not the calls. |
| D-70 | Account-wide resource names carry the server's kind, so the three servers can share one Cloudflare account. | Two servers' queues had the same name. |
| D-71 | A visitor arrives through the website’s visit page, and the avatar session travels in the address’s fragment, which no server receives. See How a visitor arrives. | It keeps the session token out of logs and Referer headers. |
| D-72 | One vocabulary for the words the Mesh shares: a place’s or realm’s content rating is all, teen, mature or adult; the Report button’s categories are in the contract too. See the realm application. | A server read "All ages" in a charter as adult; each server had its own list. |
| D-77 | A character is designed in the Register a Character questionnaire, reviewed before payment when flagged, and born by the birth engine when its payment completes: a sealed single-use seed, the Random and Inferred layers, twins or triplets for a Family, a signed DNA hash and a Character Fingerprint. It replaces D-57 and D-65. See The birth engine. | The October 24, 2026 update to the PNS Record Standard. |
The standard's open questions
Section 12 of the standard lists four open questions and one it has resolved. The registry’s current answers, which are practice and not part of the standard:
| Question | The registry today |
|---|---|
| 1. Permanent ID format | pid: and a ULID. See Permanent IDs. |
| 2. Key rotation and recovery procedure | A rotation is signed by the current key (pm.key-rotation/1) and gives a new key id, a new ID record and a re-issued certificate, with every owner record re-signed in the same step for an active name. A lost key is recovered at the namespace’s registration level, by email confirmation and a 72-hour wait or by a reviewer, and a lost account by a reviewer. See Recovery. |
| 3. Default and maximum TTL values | From 30 to 86,400 seconds, with a default per type. See TTL. |
| 4. Additional reserved labels | time is reserved alongside persona, cert and status. |
| 5. Resolved: PNS runs on portalmesh.net (pns1 to pns4); the registry storefront is theportalmesh.com | As built. |
Open questions
These are the owner’s to decide. Until then the registry runs on the stated default.
| Question | Default until decided | |
|---|---|---|
| O-1 | Was the first, flat registration fee one-time or yearly? | Yearly, a 12-month term, set by a setting. PNS v2.0 now sets yearly fees per namespace. |
| O-2 | Identity verification beyond in-house review. | In-house review by Jubilee, the identity verification provider for now. |
| O-3 | The final namespace family colors. | Identity azure, environment gold, place purple, experience green: the house theme accents. |
| O-4 | The website framework. | Next.js, as a static export. |
| O-5 | PNS hostnames. | Resolved by PNS v2.0 section 12: all four on portalmesh.net. |
| O-6 | The exact per-account and per-person caps. | The settings in D-18. |
| O-8 | The launch list of reserved events, figures and brands. | A starter list, plus Jubilee's personas. Third-party brands go through matching-rights priority instead. |
| O-9 | The time notation: eras, ranges, precision. | The provisional grammar in D-21. |
| O-10 | The parameter form for an identity inside a place. | Not implemented; unknown parameters are ignored. |
| O-11 | Launch: registering portalmesh.net, portalmesh.org and worldwideportalmesh.com, creating the cloud resources, live payment keys, the Jubilee ID client. | Nothing is created or deployed. |
| O-12 | A revision of the standard: record types for rights, ratings and media packages, and for an agent's permitted actions. | TXT kinds and permittedActions (D-12, D-13, D-24). |
| O-13 | Matching-rights priority: the verified owner of a matching web domain or trademark gets the Mesh name first. | Domain proof is built (D-35). Still the owner's to rule on: trademark claims, and disputes over a name someone has already paid for, stay with staff; there is no automated trademark check and no forced transfer of a paid name. |
| O-14 | Automatic renewal. | Built (D-34), on the yearly default of O-1. The retry schedule (3 attempts, 3 days apart, starting a day before expiry) is a setting. |
| O-15 | Lost-key recovery at the same verification level as registration. | Built (D-36). For the owner: the 72-hour waiting period, and whether standard namespaces should also need a reviewer. |
| O-16 | Email delivery: renewal reminders, transfer and team invitations. | Built (D-33). For the owner: which mail service and sending address to use at launch; until it is set, mail waits in the outbox. |
| O-18 | Where the shared contract (the shared rules, the shared Mesh operations and the database migrations) should live long-term: with the registry (D-38), with the Jubilee side, or in a third repository both sides copy from. | With the registry, copied into the Jubilee side with a hash check. |
| O-19 | Should approving a recovery that moves a name to another account (D-36) need the PNS Console to carry it out, like a suspension? | No: the Customer Admin's verification reviewer decides it and the registry carries it out (D-39). |
| O-20 | The PNS Console's roles beyond administrator, operator and reviewer, and whether certificate re-issue needs two people. | Three roles; one person. |
| O-21 | Verify every account before its first paid registration (D-49), or keep only each namespace's own checks? | Every account is verified, by a setting that is on. |
| O-22 | The transfer fee "at cost" (D-49): the amount. | 0 until set. |
| O-23 | A STATUS of born for names not yet activated (D-50): the v2.0 list omits it. | Published as born. |
| O-24 | Should retired and terminated addresses ever be released, as lapsed ones now are (D-50)? | Held forever. |
| O-25 | The embedding model for memory recall, the persona package format, and the voice library's real voices and cloning provider (D-60). | Local stand-ins until chosen. |
| O-26 | Should a Worker character's named Responsible Guardian confirm from their own verified Jubilee ID before the character is born (D-64)? | Recorded with the organization's registration until organization members have identities of their own. |
| O-27 | The Jubilee Standard Version text of the Bible books the Experience Server plays, 23.psalms.jsv.book first. | Test fixtures only, labeled JSV. |
The Registry Website Specification also leaves open:
- when to add name servers on a second hosting provider, beyond Cloudflare;
- the dispute process for rights claims on movies, music and books (today anyone can report a name over rights, and staff settle disputes).