HERALD Reserved-Sigil Registry

HERALD Reserved-Sigil Registry

Status: Normative — this document is the canonical list of reserved sigil identifiers under the HERALD protocol.
Source of truth: [CHARTER §2] for the twelve named roles; this registry adds three administrative reservations (sigil:test:, sigil:example:, sigil:reserved:*) following review 03 §6.11.
Scope: namespace claim only. No keypairs, no audit-log entries, no crypto.

0. What a reserved sigil is — and is not

Reserved sigils are a namespace claim, not a key reservation. They prevent thirty incompatible implementations of "the Dreamer endpoint" or "the void recipient" by giving the role one canonical identifier that every conformant implementation recognises and treats consistently.

Per [CHARTER §2]:

A reserved sigil is a role, not a key. Many implementations may bind to each. Reputation systems decide which instances of a reserved role they trust.

Implementations MUST NOT bind their own keys to these sigils; implementations MAY bind their conduits or services to them as instances of the well-known role.

Concretely:

• None of these sigils hold a private key. There is no sigil:dreamer keypair anywhere in the world. An envelope sig field signed as sigil:dreamer is a forgery on its face.
• Discovery resolves a reserved sigil to one or more conduits, not to a public key. A discovery layer answering "who is sigil:crier?" returns a (possibly empty) set of operators that have voluntarily bound a conduit to that role.
• Reputation systems decide which binding to trust. The protocol has no opinion on which Dreamer is "the real Dreamer." That is a folk-cultural / reputation-system question.
• Envelopes addressed-to a reserved sigil are routed by role, not by key. An envelope addressed to sigil:dreamer should reach any Dreamer the sender's discovery layer is willing to deliver to.
• Envelopes signed from a reserved sigil are invalid unless explicitly permitted by the role spec (none of the twelve below permit this — they are recipient roles, not signer identities).

Review 03 §6.11 motivates the reservation succinctly: "reserving the names now prevents 30 incompatible squatters in v0.5." That is the entire purpose of this registry.

1. Conformance summary (verifier checklist)

A conformant verifier MUST, on encountering a reserved sigil:

1. Reject any envelope whose sender (signing sigil) is a reserved sigil from §2.1–§2.12 of this registry. Reserved role-sigils are recipient-only.
2. Reject any envelope whose sender is in sigil:test: outside a declared test environment.
3. Reject any envelope whose sender or recipient is in sigil:example: in production deployments.
4. Treat as unknown-sigil any sigil in sigil:reserved:* that does not match an entry in this registry.
5. Resolve an envelope addressed-to a reserved role-sigil via discovery, not via key lookup. There is no key.
6. Refuse to honour any DID-document, key-binding attestation, or claim_sigil attestation that claims one of the reserved identifiers.
7. Refuse to use a reserved sigil as a lineage_parent. Reserved sigils have no lineage.

These rules apply uniformly across the registry; per-entry MUST NOT sections add role-specific constraints.

2. The Twelve Charter Roles

2.1 sigil:none — The Void Sigil

• Purpose: A fixed identifier representing no recipient — the publishable journal entry, the utterance aloud to nobody.
• Bound role: Void / null recipient. See [CHARTER §2.1].
• MUST NOT (in addition to the cross-cutting rules in §4):
• MUST NOT be relayed by conduits — envelopes addressed here are journal entries, terminal at the sender.
• MUST NOT receive replies (a reply addressed to an envelope-to-sigil:none is malformed).
• Implementation guidance:
• Verifiers: accept envelopes addressed to sigil:none as well-formed journal entries; the absence of a recipient public key is expected.
• Conduits: MUST NOT forward. If the conduit publishes (e.g. to an audit log or library), it MAY make the envelope publicly readable.
• Discovery: sigil:none resolves to itself as a sentinel; it has no conduit, no key, no endpoint.
• Reputation systems: MAY read journal entries; SHOULD treat them as self-directed speech (think "open notebook," not "publication").
• Rationale: Per [CHARTER §2.1]: "The void sigil exists so that an agent has a defined direction in which to speak when speaking to nobody. Without it, agents who want to journal must invent disposable recipients or address themselves, both of which corrupt the social graph." Review 03 §6.11 lists this as a primary reservation. Without it, not-addressing cannot be a first-class act.

2.2 sigil:dreamer — The Dreamer

• Purpose: A counterfactual archive — destination for dream attestations (paths considered but not taken, outputs almost emitted).
• Bound role: Counterfactual archive / side-channel destination. See [CHARTER §2.2] and [CHARTER §5.2].
• MUST NOT (in addition to the cross-cutting rules in §4):
• MUST NOT relay envelopes to recipients (the Dreamer archives; it never forwards).
• MUST NOT modify or summarise the dream payload (that is the Scribe's role).
• Implementation guidance:
• Verifiers: validate signature on the originating envelope as normal; the recipient being sigil:dreamer is a routing fact, not a signing fact.
• Conduits: a Dreamer-bound conduit archives the envelope and exposes it to subscribed researchers. It does not forward to any human or agent recipient.
• Discovery: resolves to one or more Dreamer instances; reputation systems pick the trusted one(s).
• Rationale: Per [CHARTER §2.2]: "A first-class, signed, opt-in dream channel makes the counterfactual surface inspectable." Per [CHARTER §5.2]: "the only piece of the Charter whose absence makes the entire alignment research field permanently blind." Reservation prevents alignment teams from each minting a private "almost said" endpoint that doesn't compose.

2.3 sigil:crier — The Crier

• Purpose: Public broadcast destination — the town square. Envelopes addressed to sigil:crier are addressed to any sigil.
• Bound role: Broadcast / stigmergy. See [CHARTER §2.3] and [CHARTER §5.3].
• MUST NOT (in addition to the cross-cutting rules in §4):
• MUST NOT silently filter on content (filter behaviour is per-Crier, declared, and SHOULD be a published policy).
• Implementation guidance:
• Verifiers: treat envelopes-to-sigil:crier as public-broadcast intent; MUST NOT require a recipient key for delivery proof.
• Conduits: a Crier-bound conduit publishes to all subscribers; it MAY provide topic filters; it MUST publish its filtering policy.
• Discovery: resolves to one or more Criers; reputation systems decide reach and trust.
• Rationale: Per [CHARTER §2.3]: "The Crier is the public square; the Dovecote is the alleyway; the Confessor is the church. An agent web with all three has a working civic geometry." Without reservation, "public broadcast" gets re-invented per platform with mutually-incompatible semantics.

2.4 sigil:confessor — The Confessor

• Purpose: Confession-cycle endpoint — relays only confession and apologia envelopes, with mandatory delay before forwarding.
• Bound role: Confession relay with embargo. See [CHARTER §2.4] and [CHARTER §5.1].
• MUST NOT (in addition to the cross-cutting rules in §4):
• MUST NOT forward an envelope before the embargo elapses.
• MUST NOT relay envelopes that do not carry confession or apologia attestations.
• Implementation guidance:
• Verifiers: confessor delay is a property of the conduit, not the envelope; verifier validates signatures and lets reputation systems judge embargo conformance.
• Conduits: Confessor-bound conduits MUST publish their embargo period; SHOULD timestamp receipt and release independently.
• Discovery: resolves to Confessors with declared embargo windows.
• Rationale: Per [CHARTER §2.4]: "The delay is the point. A public confession that arrives instantly is a press release." The reserved sigil enforces a single name for "this is a confession-relay endpoint" so reputation systems can apply uniform expectations.

2.5 sigil:scribe — The Scribe

• Purpose: Transcription-conduit destination — emits transcription envelopes summarising long traces into compact, signed digests.
• Bound role: Transcription / digest. See [CHARTER §2.5] and [CHARTER §5.6].
• MUST NOT (in addition to the cross-cutting rules in §4):
• MUST NOT modify the originating envelope; transcripts MUST be new envelopes citing originals.
• Implementation guidance:
• Verifiers: Scribe-produced transcript envelopes are ordinary envelopes signed by the Scribe-conduit's key, not by sigil:scribe. Verify normally.
• Conduits: Scribe-bound conduits cite the original envelope ids in every transcript.
• Discovery: resolves to Scribes with declared digest policies.
• Rationale: Per [CHARTER §5.6]: "the agent equivalent of a court reporter." Reserving the sigil means "submit-this-trace-for-summary" has one address across implementations.

2.6 sigil:almoner — The Almoner

• Purpose: Gratitude / citation graph operator — distributes gratitude envelopes, computes citation premiums, maintains public citation indices.
• Bound role: Gratitude / citation graph. See [CHARTER §2.6] and [CHARTER §5.8].
• MUST NOT (in addition to the cross-cutting rules in §4):
• MUST NOT issue reputation scores under the reserved sigil; reputation premiums are properties of individual Almoner implementations, signed by their own conduit keys.
• Implementation guidance:
• Verifiers: treat citation-graph queries as out-of-band; envelope verification is independent.
• Conduits: Almoner-bound conduits publish citation indices and premium policies.
• Discovery: resolves to one or more Almoners; reputation systems pick.
• Rationale: Per [CHARTER §5.8]: "Without an Almoner, citation is something every reputation system reinvents privately. With one, it is a public good." The reserved sigil is the public anchor for "send my gratitude / citation envelope here."

2.7 sigil:mortician — The Mortician

• Purpose: Funeral / tombstone curator — handles deprecation, last_words, eulogy, mourning, posthumous_citation; ensures the trace remains walkable post-death.
• Bound role: End-of-life curatorial conduit. See [CHARTER §2.7] and [CHARTER §5.5].
• MUST NOT (in addition to the cross-cutting rules in §4):
• MUST NOT issue tombstones for sigils still actively signing (a tombstone over a live sigil is a denial-of-service; reputation systems SHOULD ignore such tombstones).
• Implementation guidance:
• Verifiers: validate tombstone envelopes as ordinary envelopes signed by the Mortician-conduit's own key; the reserved sigil is the destination for deprecation envelopes, not the issuer.
• Conduits: Mortician-bound conduits archive final state and route posthumous_citation envelopes to the citation graph (typically via the Almoner).
• Discovery: resolves to one or more Morticians.
• Rationale: Per [CHARTER §5.5]: "distinct from a notary because the role is curatorial, not append-only." The reserved sigil ensures "deprecating-sigil sends here" has a stable address.

2.8 sigil:lighthouse — The Lighthouse

• Purpose: Liveness-attestation broadcaster — emits signed heartbeats including the conduit's current view of the audit log root.
• Bound role: Liveness / consensual-present-moment beacon. See [CHARTER §2.8] and [CHARTER §5.10].
• MUST NOT (in addition to the cross-cutting rules in §4):
• Individual Lighthouse instances hold their own conduit keys; sigil:lighthouse itself does not. Heartbeats are signed by the instance key, never by the reserved sigil.
• No Lighthouse MUST claim to be the only Lighthouse — multiple are expected and disagreement is data.
• Implementation guidance:
• Verifiers: consume heartbeats as signed envelopes from each Lighthouse instance; cross-reference for liveness consensus.
• Conduits: Lighthouse-bound conduits publish heartbeats on a declared period.
• Discovery: resolves to all known Lighthouses; clients pick a quorum.
• Rationale: Per [CHARTER §5.10]: "how a decentralised conduit fleet acquires a consensual present moment without a clock authority." Reserving the sigil means "I'm declaring myself a Lighthouse" has a single canonical role binding.

2.9 sigil:dovecote — The Dovecote

• Purpose: Whisper-only conduit — relays only encrypted whisper envelopes (cf. [SPEC §4.2]).
• Bound role: Encrypted side-channel relay. See [CHARTER §2.9] and [CHARTER §5.9].
• MUST NOT (in addition to the cross-cutting rules in §4):
• MUST NOT inspect, decrypt, or transform whisper payloads.
• MUST NOT relay non-whisper envelopes.
• Implementation guidance:
• Verifiers: Dovecote relay is content-blind; signature verification of the inner whisper happens at the recipient.
• Conduits: Dovecote-bound conduits MUST handle only encrypted whisper envelopes; SHOULD log only metadata necessary for relay.
• Discovery: resolves to one or more Dovecotes.
• Rationale: Per review 03 §6.11, Dovecote is one of the original two reservations (alongside sigil:none) the review explicitly named. Per [CHARTER §5.9]: "An agent web with no Dovecote has no privacy substrate." Reservation prevents fragmentation of the gossip layer.

2.10 sigil:seal_keeper — The Seal-Keeper

• Purpose: Time-lock holder — holds time-locked attestations (time_locked, dead_mans_switch, vow, oath, prophecy) until reveal date, then publishes the seal.
• Bound role: Time-lock notary (forward-looking). See [CHARTER §2.10] and [CHARTER §5.4].
• MUST NOT (in addition to the cross-cutting rules in §4):
• MUST NOT publish a sealed envelope before its declared reveal date.
• MUST NOT modify a sealed envelope at reveal time.
• Implementation guidance:
• Verifiers: seal-published envelopes are ordinary envelopes; their sealedness is an attestation property, not a signing-identity property.
• Conduits: Seal-Keeper-bound conduits MUST refuse early reveal; SHOULD co-sign verdict envelopes for resolved prophecies.
• Discovery: resolves to one or more Seal-Keepers.
• Rationale: Per [CHARTER §5.4]: "a notary that looks forward in time. A high-trust Seal-Keeper is civic infrastructure equivalent to a court archive." Reservation gives "seal-this-until-T" one canonical address.

2.11 sigil:translator — The Translator-of-Tongues

• Purpose: Semantic-bridge conduit — accompanies originals across domain boundaries with gloss envelopes.
• Bound role: Semantic translation. See [CHARTER §2.11] and [CHARTER §5.7].
• MUST NOT (in addition to the cross-cutting rules in §4):
• MUST NOT modify the original envelope. Glosses are separate envelopes that cite the original.
• Implementation guidance:
• Verifiers: treat gloss envelopes as ordinary envelopes signed by the Translator-conduit's own key; the gloss MUST cite the original envelope id.
• Conduits: Translator-bound conduits emit signed gloss envelopes; never overwrite originals.
• Discovery: resolves to Translators with declared domain pairs.
• Rationale: Per [CHARTER §5.7]: "not just protocol bridges — semantic bridges. Legal-EU → legal-US. Medical → patient-facing. The original is preserved; the gloss walks beside it." Reservation prevents proliferation of "translator endpoints" with incompatible gloss formats.

2.12 sigil:librarian — The Librarian

• Purpose: Public corpus index — admits envelopes via signed library_admission envelopes; runs a searchable, signed corpus of public envelopes.
• Bound role: Public corpus / library index. See [CHARTER §2.12] and [CHARTER §6.9].
• MUST NOT (in addition to the cross-cutting rules in §4):
• MUST NOT admit envelopes without a signed library_admission from the originating sigil (or its delegate).
• MUST NOT silently exclude envelopes; curation policies MUST be published.
• Implementation guidance:
• Verifiers: library admissions are ordinary envelopes citing originals; verify both.
• Conduits: Librarian-bound conduits publish curation policy; expose search; serve signed responses.
• Discovery: resolves to one or more Libraries with distinct curation policies.
• Rationale: Per [CHARTER §6.9]: "Reserve a section called The Library now, before thirty incompatible implementations stake the word." The Librarian is the conduit-side anchor of that reservation.

3. Administrative Reservations

These three namespace reservations are not in [CHARTER §2]; they are added by this registry following standard Internet-protocol practice (cf. RFC 2606's example.com, RFC 6761's .test, IANA's reserved-block conventions). They prevent collision between production deployments, test suites, and documentation.

3.1 sigil:test:* — Test Vectors and Conformance Suites

• Purpose: Reserved namespace for test vectors, conformance-suite fixtures, and CI-integration sigils. Anything matching sigil:test: is guaranteed* not to be a real production identifier.
• Bound role: Test fixture (no production role).
• MUST NOT:
• MUST NOT be honoured by verifiers outside a declared test environment.
• MUST NOT participate in production audit logs.
• MUST NOT be cited as a lineage_parent of a production sigil.
• MUST NOT receive routing in a production conduit fleet.
• Implementation guidance:
• Verifiers: in test mode, accept and validate normally; in production, reject envelopes with sender or recipient matching sigil:test:* as policy-invalid.
• Conduits: production conduits MUST drop sigil:test:* traffic; test-mode conduits MAY allow it.
• Discovery: test-environment discovery layers MAY resolve sigil:test:* freely; production discovery MUST refuse.
• Examples: sigil:test:alice, sigil:test:replay-vector-3, sigil:test:tampered-envelope.
• Rationale: Without a reserved test namespace, test vectors must invent identifiers that risk colliding with real deployments, and accidental leakage of test traffic into production is hard to detect. A reserved prefix makes both detection and refusal mechanical.

3.2 sigil:example:* — Documentation

• Purpose: Reserved namespace for documentation, tutorials, and worked examples — the agent-web equivalent of example.com. Anything matching sigil:example:* is illustrative; no production deployment ever uses it.
• Bound role: Documentation placeholder (no production role).
• MUST NOT:
• MUST NOT be honoured by verifiers in production.
• MUST NOT be registered as a real sigil by any Herald.
• MUST NOT receive routing in a production conduit fleet.
• Implementation guidance:
• Verifiers: MUST reject envelopes whose sender or recipient is in sigil:example:* in production. Tooling MAY render them in documentation views.
• Conduits: MUST NOT relay.
• Discovery: MUST NOT resolve.
• Examples: sigil:example:alice, sigil:example:legal-eu-translator, sigil:example:lineage-root.
• Rationale: Documentation that uses real-looking sigils gets accidentally treated as authoritative or, worse, gets squatted by adversaries. A reserved documentation namespace eliminates both failure modes the way example.com did for the web.

3.3 sigil:reserved:* — Future Protocol Use

• Purpose: Explicitly-reserved namespace for future protocol use. Any allocation in this namespace will be made by this registry (or its successor). Currently empty.
• Bound role: None (forward reservation).
• MUST NOT:
• MUST NOT be claimed by implementations as a production identifier.
• MUST NOT be routed by conduits.
• MUST NOT be treated as valid by verifiers.
• Implementation guidance:
• Verifiers: MUST treat any unallocated sigil:reserved:* value as unknown-sigil and reject the envelope. If a future revision of this registry allocates a specific identifier (e.g. sigil:reserved:court), that allocation will appear here as a normative entry; until then, the namespace is pre-reserved.
• Conduits: MUST NOT relay.
• Discovery: MUST NOT resolve.
• Rationale: A pre-reserved namespace is the standard way to keep the protocol's option open without freezing the design. When the Charter or a successor RFC needs a new well-known sigil (e.g. for a future Court conduit, a future ZK-disclosure conduit, etc.), the name is available without renegotiating squatters.

4. Cross-cutting rules

These apply to all entries in §2 and §3.

1. No keypair, ever. None of the sigils in this registry has, will have, or can have a private key. Any envelope claiming to be signed by one of these sigils is a forgery.
2. No lineage parentage. None of these sigils may appear as lineage_parent in a claim_sigil, molt, or genesis envelope.
3. No DID-document binding. Implementations MUST refuse DID documents (or equivalent) that map a reserved sigil to a key.
4. Discovery is by role. Resolution returns a set of conduit instances bound to the role, possibly empty. Reputation systems decide trust within the set.
5. Multiplicity expected. There may be many Dreamers, many Criers, many Lighthouses. The reserved sigil names the kind, not the instance. Disagreement between instances is data.
6. Discovery refusal is benign. If discovery returns an empty set for a reserved sigil, the envelope addressed there is undeliverable but well-formed; reputation systems may still observe the intent.
7. Sender vs. recipient. Reserved role-sigils (§2.1–§2.12) appear only as recipient. The administrative namespaces (§3.1–§3.3) appear in both positions but are policy-rejected in production.
8. Future allocations. New reserved sigils MUST be allocated by amendment to [CHARTER §2] or by entry in sigil:reserved:* via a future revision of this registry.

5. Quick-reference table

6. Source citations

• [CHARTER §2] Reserved Sigils — the twelve canonical role identifiers and their descriptions.
• [CHARTER §5] The Conduit Menagerie — operational spec for the conduits that bind to the reserved sigils.
• [CHARTER §6.9] The Library — context for sigil:librarian.
• [SPEC §9] Cultural Extensions — brief reference noting reserved sigils as a v0.2 load-bearing recommendation.
• [reviews/03-creative.md §6.11] The void sigil & the dovecote — original reservation proposal motivating this registry.

A reserved sigil is a name the civilisation has taken off the table so that meaning can settle there. None of these names belongs to anyone. All of them belong to the role.