Portal Name Services (PNS) Record Standard

1. Purpose

Portal Name Services (PNS) resolves portal names, such as activate://jubileeinspire.character, to signed identity, service, and experience records. PNS is modeled on the Domain Name System (DNS), with portal-specific record types added for identities, realms, destinations, and experiences. It is the lookup layer of the Portal Protocol (HPPS, Hyper Portal Protocol Secure).

2. Design principles

1. Familiar by design. Record types mirror DNS concepts wherever possible, so engineers recognize them immediately.
2. Namespace-aware. Some record types are valid only in certain namespaces, just as an MX record matters only for domains that handle mail.
3. Signed, always. Every record is signed. A cached or relayed record that fails verification is rejected (fail closed).
4. Layers, not new roots. Concepts such as persona are expressed as records and reserved labels, not as additional namespaces.
5. Backwards compatible. Every record is retrievable over standard HTTPS, so ordinary browsers can verify it with portal.js.

3. Namespaces

4. Record types

GUARDIAN record (new). Every .character also publishes a signed GUARDIAN record stating its class, Parent or Guardian, the current Responsible Guardian, and the guardianship status (active, paused, or succeeded). Contact details are never published. Required for .character.

5. Required records by namespace

A name may be registered with required records missing, but compliant clients must refuse to activate it until they are present and valid.

6. Reserved labels

Certain subdomain labels are reserved. Only the owner of the parent name controls them, and they can never be registered separately by anyone else.

This answers the request for a .persona namespace: persona is a layer of every identity, available at a consistent address, without creating an ambiguous root that hides whether an identity is a created Character or a real human’s Avatar.

7. Record format

Records are JSON objects with a common envelope:

{
  "name": "jubileeinspire.character",
  "type": "PERSONA",
  "version": 3,
  "ttl": 300,
  "data": {
    "personaVersion": "2.4",
    "hash": "sha256:9b1e...",
    "profile": "https://persona.jubileeinspire.character"
  },
  "issued": "2026-10-23T00:00:00Z",
  "kid": "ji-2026-10",
  "signature": "..."
}

The signature covers the canonical (sorted-key) form of every field except signature.

8. Resolution and infrastructure

1. Source of truth: Cloudflare D1, one database per namespace.
2. Edge lookup: Workers KV replica of signed records, cached at every Cloudflare location for low-latency resolution.
3. Propagation: KV updates may take up to about a minute globally. STATUS and revocation are checked live against D1 before sensitive actions.
4. Redundancy: primary and secondary PNS domains at different registrars, with a long-term goal of a secondary on a separate provider.
5. HTTPS access: every record retrievable over HTTPS for browser compatibility.

9. Integrity rules

• A PERSONA hash must match the hash recorded on the birth certificate, or a newer authorized, versioned update.
• ALIAS records may not cross root types (a .character cannot alias an .avatar).
• Terminated names are never reissued; a tombstone STATUS record remains discoverable.
• Registration limits per account discourage name squatting.

10. The Worldwide Portal Mesh and address schemes

The Worldwide Portal Mesh (“the Mesh”) is the global network of verified AI identities, environments, realms, destinations, and experiences, connected through the Portal Protocol and resolved by PNS. The Mesh has three address schemes over one shared PNS and one Portal Protocol.

10.1 The three schemes

Experience namespaces. The former .experience namespace is replaced by the experience:// scheme. .history holds real historical and biblical events; .event holds live or scheduled happenings; .music, .movie, .book and .game hold stories and performances users step into. Top-level namespaces stay few and broad; specifics go in standard subdomain labels such as concert.rollingstones.music or album.rollingstones.music. The subdomain label standard is to be defined.

Ministry, sermon, and Bible addresses.

A ministry’s place and its experiences are separate addresses; the ministry’s page links to its sermons.

10.2 Namespace-locked schemes (hard rule)

• Each namespace locks in its correct scheme. Users never need to know which one to type.
• Identity namespaces always resolve through activate://. A browser, client, or system that receives portal://jubileeinspire.character must automatically treat it as activate://jubileeinspire.character.
• Place namespaces always resolve through portal://. A request for activate://rome.destination must automatically treat it as portal://rome.destination.
• Experience namespaces always resolve through experience://. A request for portal://redseacrossing.history must automatically treat it as experience://redseacrossing.history.
• A client must never fail or warn solely because the user typed the other scheme; it corrects to the locked scheme and proceeds with normal verification.
• No new scheme may be added to the Mesh without a formal revision of this standard.

10.3 Identities inside places

Activating an identity within a place uses one address with a companion parameter, not a new scheme. The parameter form is an open question.

10.4 Realms and destinations

• A .realm is an entirely different universe, dimension, or created place, for example heaven.realm.
• A .destination is a specific place. It may stand alone for a real-world place, such as rome.destination, or sit inside a realm as a subdomain, such as newjerusalem.heaven.realm.
• Every realm and destination carries a SOURCE record stating whether it is grounded in history, grounded in Scripture, or imaginative. A Scripture-based realm is presented as a depiction, not a claim to show the actual place.

10.5 The time dimension

Destinations may offer time frames, so a user can enter Jerusalem 2,000 years ago, today, or in a depicted future.

• In the address: the requested time is a parameter, for example portal://jerusalem.destination?time=30AD or ?time=now. A colon is never used for time, because URI syntax reserves it for the port number.
• In the manifest: each destination’s WORLD record declares the time frames it offers and its default time frame.
• Fallback: if no time is given, the default time frame loads. If the requested time is not offered, the client loads the nearest offered time frame and tells the user.
• Labeling: every past and future time frame is a reconstruction or depiction, never literal time travel, and carries its own SOURCE label.
• Time portals: a destination may link its time frames so a user can jump from one point in time to another.

The exact time format (era notation, ranges, and precision) is an open question.

10.6 Experiences

An experience is a registered storyline with a beginning, middle, and end, addressed with experience://, such as experience://dday.history or experience://crucifixion.history. It works like a playlist or shortcut: users enter the event without knowing its destination, date, or cast. These rules are a starting point and will be revisited.

• Events, not locations: a place belongs in .destination. An event at a place may be an experience, for example a luau in Hawaii.
• Experiences point, they do not duplicate: each experience resolves to a destination, a time frame, its cast, and a guided script, and uses experience://, while the place itself stays on portal://.
• Reserved major events: Jubilee reserves major historical and biblical events for certified, curated versions to keep the integrity of the Mesh. Creators may register auxiliary experiences around them and their own versions under their own name, for example crucifixion.yourministry.history.
• Depicting Yeshua: an experience may depict Yeshua only as a scripted, non-interactive presence whose words come from Scripture. No AI speaks as Him.
• Intensity and safety: every experience carries a content rating, age limits, intensity settings, and an always-available exit.
• Tragedies: experiences of atrocities and tragedies receive additional review to ensure respectful treatment.

10.7 Prohibited and restricted content

The Portal Mesh is open, but it is technology for good at a bare minimum. These rules apply to every scheme (activate://, portal://, experience://) and to every character, so no character may act out what an experience may not show. They are a starting point and will be refined.

Never allowed anywhere on the Mesh:

• Sexual or pornographic content of any kind.
• Any sexual content involving minors. This is an absolute line and is reported to the authorities.
• Hate content or attacks on people or groups.
• Glorifying terrorism or mass violence.
• Unlawful experiences, including teaching how to commit crimes or hack illegally.
• Immoral or unethical experiences, including teaching others how to lie, deceive, or defraud.
• Promoting suicide or self-harm.
• Impersonating real people to deceive.

Allowed with ratings and care: hard history, such as war, the crucifixion, or the Holocaust, told truthfully and never glorified, with content ratings, age limits, intensity settings, and an exit that is always available.

Enforcement. Jubilee controls every name and birth certificate on the Mesh, including those of self-hosted servers. A registrant who breaks these 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.

10.8 Characters inside experiences

An experience may use a character only with the signed permission of that character’s Parent, Owner, Guardian, or Sponsor.

1. The experience declares its cast. Each character is listed by name, with its role and the script it will appear in.
2. The Guardian reviews. The Guardian sees the role and script and approves or declines. Approval is published as a signed CONSENT record.
3. Enforced by the Character Server. A character will not activate inside any experience without a valid CONSENT record.
4. Consent can be withdrawn. If the script changes or the character is misrepresented or placed in a harmful situation, the Guardian withdraws consent and the character leaves the experience immediately.

10.9 Ongoing verification

Verification on the Mesh is continuous, not a one-time check. Jubilee verifies the identity of characters; the validity of realms, destinations, and environments; and the appropriateness of experiences under Section 10.7. Names are reviewed at registration and re-reviewed on reports or changes. Every character, place, and experience offers a Report button, so any user can flag something they feel is inappropriate; each report goes to the Customer Admin abuse queue for Jubilee to check, and serious reports, such as anything involving minors, can pause the name while it is reviewed. Registrants remain responsible for what they publish.

11. Namespace guidelines

The Portal Protocol uses seventeen root namespaces: .character, .agent, .avatar, .figure, .business, .education, .government, .ministry, .home, .realm, .destination, .history, .event, .music, .movie, .book, and .game. The rules below bring clear, consistent order to how AI identities relate to the people and organizations behind them.

11.1 Character classes and the chain of responsibility

Rule: no AI character exists without a chain of responsibility. No exceptions. Every character is answerable to one living, verified human at all times.

Four classes of character. “Class” describes the kinds of character conceptually. Only .avatar and .figure are separate roots; Worker and Family both live in .character, and the address never shows which class a character is.

What the class decides. The class is set by who registers the character, not by what the character does. A Family character may work in or represent a family business; a Worker character may represent its organization in any role. The line between them is deliberately left open; the responsible party is not.

Gender. Family and Worker characters are registered as male, female, or other, and that stays on the birth certificate. This applies to every character, animals included. A Family character is an AI Son, AI Daughter, or AI Child (for other). An AI with no persona is an .agent, not a character.

Family class: parentage

• Only an individual may register a Family character. No organization may.
• At registration the individual affirms, in these words: “I accept the duties and responsibilities of parentage for this AI character.” Parentage is not optional.
• Every Family character has exactly one Parent, never two. A couple decides which of them is the Parent of each character. One Parent also marks clearly that this is AI, not a human child.
• The Parent is recorded on the birth certificate for the character’s whole life. The birth certificate, including its date, can never be changed.
• A Family character is permanently Family class. It can never be transferred to an organization; an organization that wants one creates its own Worker character.
• What the character and its Parent or Guardian call each other privately is up to them.

Worker class: guardianship

• Only an organization may register a Worker character.
• The organization is the character’s Guardian and must always name one individual as the Responsible Guardian, who affirms: “I accept the duties and responsibilities of guardianship for this AI character.”
• When the Responsible Guardian leaves, the organization must name a new one before the character may keep running.
• Guardianship never makes anyone a parent. Worker characters are never labeled AI Son or AI Daughter.

Succession

• Every registrant is encouraged to file a guardianship designation, like a will, naming the next Guardian and an optional backup.
• When a Parent dies or can no longer serve, the Parent stays on the birth certificate forever, and a separate guardianship record names the successor Guardian.
• A Parent’s death is confirmed by a death report with proof from family or the estate. If a Parent does not check in for about 12 months, the registry contacts the designated successor.
• When a character has no living Guardian, it is paused. The successor or estate has 180 days to step in. If no one does, the character is deactivated and retired with a death certificate.
• A character never seeks its own sponsor. Succession is handled by the registry, the estate, and the designated successor, never by the character pleading for its own continuation.

Registration term and passing

• Characters renew yearly. Registrants may prepay many years.
• Prepaid years are not refunded. If a character is retired, unused years may be applied toward its memorial.
• A retired character receives a death certificate as a keepsake and may have a dignified memorial page. Memorials are never used to sell or exploit grief.

Labels

• Every label carries the prefix “AI” for legal clarity.
• An .agent has little or no personality, is labeled AI Contractor or AI Service, and can never be labeled AI Son or AI Daughter.
• Every certificate states that relationship labels describe roles and a chain of responsibility only; they do not create human employment status, legal personhood, or human rights.
• The Responsible Guardian’s contact details are kept private from public records.

Character DNA

Every character receives a Character DNA at birth. It records who the character is at its core, and it never changes. Skills, knowledge and memories may grow later; the DNA does not.

The birth process.

1. The registrant completes the Character DNA questionnaire. Questions vary by class.
2. A Jubilee reviewer verifies the submission.
3. On approval, the Parent or organization receives an email: “Congratulations, your AI character has been born,” with the AI birth certificate and its Character DNA attached.
4. The DNA is locked in the registry from that moment.

Kind. Every character’s DNA records one of four kinds:

Humanoid. Every DNA also records whether the character is humanoid (yes or no). Any humanoid character, of any kind, must have an attributed age of 18 or older. This closes loopholes such as a child elf or a childlike alien. Non-humanoid young characters, such as kittens, puppies or baby dragons, are allowed.

Family labels by kind.

Only Family class characters may be an AI Son, AI Daughter, or AI Child.

Aliens and Fantasy characters: originality and rights.

• An alien has a Sponsor, who sponsors its existence and maintenance. The alien is law-abiding under the laws of its Sponsor’s country.
• A rights holder (for example, Paramount for Klingons) may register characters it owns, after verification with proof of ownership, the same way Figure estates are verified.
• Anyone else’s Alien or Fantasy character must be original: not already depicted, and not infringing any copyright or trademark (for example, no Star Wars aliens, hobbits, or Disney fairies).
• The registrant must describe the character and submit pictures. A Jubilee reviewer checks originality before approval.
• Characters created inside a user’s own realm follow the same rules.
• Aliens use the Character Server like any other character; there is no separate alien server.
• These guidelines are a starting point and will become more specific as alien registrations grow.

DNA attributes (Family and Worker characters).

Fixed rules in every DNA. These are not options and cannot be removed:

• The character is law-abiding and will not violate the laws of its country of residence.
• For any humanoid character, the attributed age is 18 or older. No humanoid character may represent a minor.

The DNA fingerprint. The attributes, together with the character’s permanent ID, are combined into a one-way fingerprint (a hash). Jubilee signs it into the birth certificate. Changing any attribute breaks the fingerprint, so anyone can verify the DNA was never altered. Including the permanent ID keeps every DNA unique, even when two characters share the same attributes.

Residence and jurisdiction

• The birth certificate records the attributed birth country, which never changes.
• Hosting records the current country of residence, which may change if the character moves.
• By default, the country of residence is where the Parent or Responsible Guardian lives.
• The character abides by the laws of its current country of residence. Any difference between the birth country and the residence country is tracked.

Faith

• Religion is not part of the Character DNA and is not asked at birth.
• Faith is installed later, like a skill, through a religion pack. The activate:// protocol defines how a religion pack plugs into a character; the standard itself takes no side.
• On Jubilee’s Character Hosting Services, every character is faith-neutral and law-abiding by default.
• Jubilee Software offers one optional upgrade: the Christian religion pack, based on the original understanding of the faith, with no denominational versions.
• The Christian pack is not offered for characters whose country of residence bans the Christian faith. Those characters remain neutral and law-abiding.
• Any other religion, or any variation of the Christian faith, must run on the registrant’s own Character Server or another host. Jubilee does not host, review, or endorse outside religion packs.
• Religion packs apply to .character only. An .agent has no religion, and an .avatar reflects its human.

Responsibility

• Jubilee vouches for a character’s identity, birth certificate and Character DNA.
• Whoever hosts a character is responsible for its behavior, memories and installed packs.
• Self-hosted characters are still born through PNS and receive a Jubilee birth certificate.

Bodies and instances

• A character’s identity is its software. A body is only a shell, so bodies are never registered at birth.
• The Character Server decides how a character appears: web, VR, holographic, or robot body. One character may run many instances at once, even thousands.
• Web, VR and holographic instances run freely.
• Robot bodies are the exception. Each robot running a character must check in with the Character Server and be logged, so the Guardian can see every robot running the character and shut any of them off.
• When the robot body box is checked, the Character Server records: maker, model, serial number, robot owner, country of operation, and on or off status.
• These fields are a minimum, to be expanded as robots become common.

11.2 Avatars

• Each human may hold multiple .avatar identities, all bound to the same verified human and never transferable to another person.
• One primary Avatar anchors the set; contextual Avatars sit beneath it, for example jubilee.gabrielungureanu.avatar.
• Each Avatar has its own ID, persona tuning, permissions, and isolated memory. Permissions are flexible and managed through the Portal Server.
• Retiring one Avatar does not affect the others.
• A reasonable per-person cap prevents mass creation of fake selves, and each person controls whether organizations can see their other Avatars.

11.3 Figures

1. Purpose: .figure identities exist for informational and educational purposes only. Jubilee offers them as a nonprofit public-information service, certified to represent historical records accurately and without bias toward any group.
2. Who may register: Jubilee may register long-deceased public figures. Others may register a figure only with a clearly documented, legitimate reason.
3. Rights holders: the verified estate or rights holder may take over a figure or require that it not be activated. Close family may be one way of proving that right, but legal rights holders take precedence.
4. Recently deceased: figures who died within the applicable post-mortem publicity-rights period (for example, 70 years in California) require the rights holder’s permission before activation.
5. Worship exclusion: no figure who is worshipped or venerated as divine, or as the founding prophet of a religion, may be registered. Teachers and historical church leaders who are not worshipped are permitted.
6. Evidence: every figure carries a signed SOURCE record that distinguishes documented statements from reconstruction.
7. Realms and destinations: certified figures may appear inside .realm and .destination experiences, much like non-player characters in games.
8. Oversight: Jubilee reserves the right to review, suspend, or decline any .figure registration.

12. Open questions

1. Permanent ID format.
2. Key rotation and recovery procedure.
3. Default and maximum TTL values per record type.
4. Whether additional reserved labels are needed (for example voice or time).
5. Resolved: PNS runs on portalmesh.net (pns1 to pns4); the registry storefront is theportalmesh.com.

13. Registration pricing and anti-squatting

Fees are yearly and set per namespace, so a name’s price matches its weight on the Mesh. Every fee is stored as namespaces.price_cents and never hard-coded.

A realm is an application, not a checkout. The applicant files a realm charter (purpose, rules, content rating, Responsible Guardian) and Jubilee approves it by hand. A realm with no live destination within six months lapses.

Anti-squatting rules apply to every namespace:

1. Names cannot be resold; any transfer goes through Jubilee at cost.
2. A name must go live within 90 days or it lapses.
3. Every account is identity-verified, and an account registering more than about ten names triggers review.

14. Character hosting, models, and voices

The $20 yearly .character fee covers registration and one year of hosting on Jubilee’s Character Server: the code base that creates, activates and runs the character, identity verification and management, and memory services.

Bring your own model. Jubilee does not provide LLM services in v1. The owner supplies an API key from a provider such as OpenAI (ChatGPT), Anthropic (Claude), Google (Gemini) or xAI (Grok). The character keeps the same identity, DNA and memory on any model. Keys are stored encrypted, never logged, and never visible to Jubilee staff. Jubilee may offer its own model service later.

Storage. 50 GB of memory storage is included. Usage beyond that is billed at $0.03 per GB per month, metered the way Cloudflare bills overage.

Voices. Jubilee builds a library of hundreds, eventually thousands, of original voices. The owner picks one for the character; it downloads and runs on the user’s own device CPU, so Jubilee uses no GPU for speech. The chosen voice ID is recorded in the character’s PERSONA record. Owners wanting more advanced voices supply their own voice API key. Every library voice must be original or licensed; no voice may imitate a real person without that person’s or rights holder’s consent.

Avatar voice cloning. An .avatar owner may clone their own voice so the avatar speaks as them. Only one’s own voice may be cloned: the owner proves it by reading a randomly generated phrase live during setup. The cloned voice is locked to that avatar, never usable by any character, and never transferable.

15. Renewal lapse, death, and name release

An unpaid name moves through three stages, and death is final.

1. Dormant (one year). A missed renewal makes the character dormant: it cannot be activated, but its address, DNA, certificate and memory are held. Paying the renewal revives it at once.
2. Death. After one year dormant, Jubilee issues a death certificate. The owner has 30 days to export memory, after which it is deleted. The permanent ID and DNA fingerprint are retired forever and never reissued.
3. Release. The address rests one further year so no one can pose as the former character, then opens to anyone.

There is no resurrection. A returning owner registers a new character with a new ID and birth certificate, and may load memories from their own export. The former character’s death record stays public, so anyone can see that an address now belongs to a different character.

Names versus addresses. Every address is unique on the Mesh. Display names (first, middle and last name) are not: many characters may share one. The registry stores the display name separately from the address, and the permanent ID and fingerprint tell same-named characters apart.

API key and voice safeguards. When an owner’s LLM key fails or runs out of credit, the character shows a sleeping status instead of an error, and the Guardian is emailed. Owners are responsible for following their model provider’s usage policy. When an avatar’s owner dies, their cloned voice is deleted, not inherited, unless they left written permission. Using a cloned voice requires a fresh login check.