Names and addresses

Portal names

A portal name is one or more labels followed by a namespace: jubileeinspire.character, invoices.example.agent, jubilee.gabrielungureanu.avatar. A name has at most 4 labels before the namespace. Reading from the left, the first label is the leaf; everything after it is the parent name, and the last label with the namespace is the top-level name it sits under.

Before anything else, input is normalized: Unicode NFKC, trimmed, lowercased, and trailing dots removed. The namespace must be one of the 17; anything else is refused with “.persona is not a Mesh namespace.” (or the namespace that was typed). The old .experience is refused the same way.

Every address is unique on the Mesh; a display name is not. A name may carry a display name, such as “Oasis”, stored apart from the address and shown beside it, and many names may share one. The permanent ID and the fingerprints tell same-named characters apart.

Label rules

• Lowercase letters a to z, digits 0 to 9, and hyphens.
• 3 to 63 characters for a registered name. A label beneath it, in a subname, may be as short as 1 character, so chapter and verse numbers work (below).
• No leading or trailing hyphen.
• Never two hyphens in the third and fourth positions, the shape of an internationalized-domain prefix such as xn--, so a label can never be read later as something else.
• In version 1, nothing outside ASCII. NFKC runs first, so full-width letters become ordinary ones; letters from another script, such as a Cyrillic “о” that looks like a Latin “o”, are refused.

These are the registry’s answers for sample input. The messages are shown exactly as the registry returns them.

Bible addresses and standard labels

Bible passages read inside out: chapter, book, translation. The translation’s name, jsv.book, is the registered name; the book, chapter and verse are subnames its owner creates beneath it. The registry’s parser reads them this way:

• experience://23.psalms.jsv.book is Psalm 23 in the JSV; 1.23.psalms.jsv.book is its first verse; psalms.jsv.book is the whole book.
• bible.book is reserved by Jubilee as the front door to the Bible, pointing to the JSV. A request for it goes to review.
• A chapter number on its own is not a name: 23.book is refused, because the registered label needs 3 characters.

The same pattern carries the other standard labels: church.gracefellowship.ministry, easter.sermon.gracefellowship.event, concert.rollingstones.music. They are conventions, not reservations; see Namespaces.

Look-alike protection

Refusing non-ASCII removes look-alikes from other scripts. What remains are ASCII imitations, such as “rn” for “m” or a zero for an “o”. The registry compares labels by their skeleton, made in this order:

1. Normalize (NFKC, trim, lowercase).
2. Drop every hyphen.
3. Fold the two-letter imitations: rn becomes m, vv becomes w.
4. Fold single characters: 0 becomes o; 1 and i become l; 5 becomes s.

A new top-level label is compared, in the same namespace, with every registered name (retired and terminated ones included, because they keep their label forever) and every reserved name. If two different labels share a skeleton, the new one is never silently registered: search shows it as requires_review, with the message “This name looks like jubileeinspire.character, so a reviewer will check it first.”, and a registration goes to Jubilee’s review queue. A look-alike of a name refused under the worship exclusion is refused outright, as reserved.

Reserved names

Some labels are held before anyone searches. What happens depends on why the label is held:

The holder of a reservation sees the name as available and registers it directly, but holding a name never skips a review the namespace requires: tragedies are reviewed for everyone, Jubilee included, and every .figure is reviewed. The final launch list of reserved events, figures and names is an open question.

Reserved labels and views

Section 6 of the standard reserves labels that only the owner of the parent name controls. They can never be registered on their own by anyone. As the leaf of an address with a parent, a reserved label is a view of the parent name: the address resolves the parent, and says which layer to present.

Parsing peels the view off before validating the name. In persona.jubileeinspire.character, the view is persona, the name that resolves is jubileeinspire.character, and the canonical address keeps the view: activate://persona.jubileeinspire.character. A reserved label is only a view when the address has at least three parts; persona.character is simply a reserved top-level label.

For the same reason, the owner of a name cannot register a subname whose leaf is a reserved label: it would be a view, and could never be reached. The registry refuses it with reserved_name, “"persona" is a reserved label: jubileeinspire.character already answers persona.jubileeinspire.character itself.”

The PNS resolver and the registry’s lookup both return the bundle or record of the parent name with a view field, so a client knows which layer to show.

The scheme lock

An address is an optional scheme, a name, and optional query parameters. The registry, the resolver and portal.js all parse it the same way:

1. The scheme may be activate://, portal://, experience://, or absent, in any letter case. Any other scheme is not a Mesh address and is refused with invalid_address.
2. The address is given the scheme its namespace locks in: activate:// for identities, experience:// for history, events, games, movies, music and books, portal:// for everything else. If another Mesh scheme was typed, it is corrected and the result says corrected: true. A wrong scheme is never an error.
3. A fragment (#...) and trailing slashes are dropped. A path or a port is refused.
4. The name is validated as above, with any view peeled off first.

These results come from the registry’s own parser:

Query parameters: time and dir

Two parameters have meaning today:

• time: the time frame to open, for destinations, for example ?time=30AD or ?time=now. Never a colon, which URI syntax reserves for the port. How a frame is chosen is on Resolution.
• dir: go or bring, to ask for the other direction. It is honored only if the portal’s ENDPOINT allows it. Any other value is ignored.

Parameters are split on &; a + means a space; keys and values are percent-decoded and trimmed; keys are lowercased. If a key repeats, the last value wins. Unknown parameters are kept and passed through untouched. The canonical address lists its parameters sorted by key and percent-encoded:

PORTAL://Jerusalem.Destination?time=30AD&dir=bring
  becomes
portal://jerusalem.destination?dir=bring&time=30AD

Permanent IDs

Every registration gets a permanent ID: pid: followed by a ULID, 26 characters of Crockford base32 that sort by creation time, for example pid:01JBX3Q8Z9M4T7K2V5N6R8W0YC. The pattern is ^pid:[0-9A-HJKMNP-TV-Z]{26}$.

• A PID is never reused. A name that dies, is retired or is terminated keeps its PID forever, and its tombstone stays discoverable.
• If an unpaid hold expires, or an address is released and registered again, the new registration gets a new PID; the old one stays public. See The life of a name.
• The name’s key ids (<pid>#k<n>), its certificates, and the second key each bundle is stored under at the edge (pid:<pid>) all hang off the PID.