Glossary
Every term comes from the term register; its source names the normative place in the specifications.
Accept
The invitee's signed consent to exactly one invite, bound to it by the invite's credential digest. It carries the person's own card, to whose key-agreement key the welcome is sealed, and states whether the person may be shown to the group as a candidacy before admission.
Adapter
A registered binding of one key-agreement procedure to the key port.
Admission evidence
A consent pair, the complete invite and accept documents, optionally with vouches, relayed to a member authorized to admit, so that any such member can complete the admission. It grants nothing and consumes nothing.
Anchor
A person's identifier toward one context (did:key). Every enactment of a ceremony runs under a freshly derived pair anchor, a re-encounter too; a standing anchor never appears on the ceremony wire, and anchors never converge into a person.
Anchor mapping
The designated-verifier artifact (anchor-mapping@3) that links the sender's pair anchor in one relationship to the sender's current community anchor, for exactly one addressee: two MACs under keys agreed with that addressee, so only the addressee can verify it and either of the two could have produced it. It carries the lineage of the community anchor's rotations, so the addressee can follow a rotation.
Attestationproposed
Proposed: a signed, portable statement by one person about another's contribution, role, skill or promise, independently verifiable. Candidate: the DTG Verifiable Endorsement Credential (VEC), i.e. a Statement Credential with predicate endorses/1.
Authority log
The append-only operation DAG rooted in the genesis operation; the sole source of authorization state.
Authority port
The part of the Access Layer that decides membership, policy and authorization: log, materialization, conflict matrix, policy, views. Not replaceable by an adapter.
Authorization view
The chained, quorum-signed object by which a service of class view learns a group’s epoch and authorized device identities.
Bootstrap
An admitted person's first entry into the group: the admitting member.add delivered to its own subject together with the welcome, adopted provisionally and confirmed only once the materialized log holds the admission. Where the admission does not fit one document, the material travels alone in the adapter's recovery kind.
Bundle
The one-scan transmission (sent card plus step credential), specified as the Delivery Contract task encounter-bundle.
Canonical
An operation is canonical when materialization at its causal position accepts it and no outcome rule of 3.6 disposes of it.
Ceremony
A registered, versioned definition of an encounter interaction, including its time parameters.
Challenge
A fresh, single-use, high-entropy value carried in a contact card for one enactment. One concept; displayed and sent cards differ only in lifecycle.
Community anchor
The anchor of a person's personal community at its current generation (Identity §5.4), serving as the person's chosen cross-relationship coordinate; it is a member of no group and appears in no artifact of the Access Layer except inside anchor.rotate. The crossing from a member anchor to a contact is the group pair of the Network Visibility layer.
Contact card
A person's signed self-description carrying the material needed to recognize and reach them and, in an enactment, a fresh challenge; displayed (shown for scanning) or sent (transmitted inside an enactment, naming its recipient). Not a credential.
Continuity probe
The blinded list (continuity-probe@1) that either party, preferably both, sends after an enactment: its own pair anchors of the relationships active before, padded to a multiple of 256 and keyed to the fresh pair. A match identifies a shared prior relationship, to which the fresh pair is chained; no match means a new contact. The default path of continuity, run on every enactment, independent of any disclosure.
Credential digest
The multibase-encoded multihash over JCS of the complete credential including its proof.
Device card
The signed binding of one device's key material to the member anchor of the person it belongs to; recorded in the authority log.
Edge
The relation between two anchors constituted by the encounter credentials between them; incoming, outgoing, or mutual. One edge per anchor pair.
Enactment
One performed run of a ceremony between two people. Never reused; complete when both parties hold records.
Enactment binding
The digest, identical in both step credentials of an enactment, that ties them to one exchange descriptor: the multihash over JCS of the ceremony and both challenges in ascending order.
Enactment record
A party's durable local record of an enactment, created before issuing; the records are also the consumed-challenge history.
Encounter credential
The immutable credential in which one party records that they recognized another. Issued by one party about the other, verifiable offline.
Epoch
A numbered period of the group’s key world; enforcement takes effect as epoch transitions. Term aligned with MLS (RFC 9420).
Epoch-key lineage
The chain of per-transition entries by which the adapter linear/0.1 makes a previous content key readable under the next.
Forked state
The fail-closed materialization outcome of the fork pairings that 3.6 names: a policy change or a dissolution concurrent with an enforcement operation.
Group
A collective actor with members, a policy, an authority log, and documents. Its identity is the digest of its genesis operation; its address is its group DID.
Healing
The key port's correction of its key structure to the materialized membership; the log decides, the keys follow.
Implicit capability
The read/write standing every member holds by membership alone.
Incoming edge
An edge, from a party's local view, when it has received the counterparty's credential and not issued its own.
Introduction
The act by which a mediator who is a contact of both makes a requester known to a target: five messages (request, forward, reply, acknowledgement, voucher) over the existing relationship channels. The mediator transfers messages, never standing anchors; the fresh pair anchors of the new relationship are issued by their owners. The relationship carries the provenance introduction until its first completed enactment upgrades it to encounter, never downward.
Invite
A member's signed offer of membership to exactly one person: a DTG invitation credential naming the group by its genesis digest and the person by the member anchor they derived for that group. It carries the inviter's card, no key material and no operation.
Key port
The interface through which a registered adapter produces epoch secrets satisfying the invariants KV1 to KV6.
Key service duty
The standing obligation of members to (re)deliver verifiable current-epoch key material to a party the materialized state entitles to it.
Materialization
The deterministic derivation of group state from the log; its result is the materialized state.
Materialized state
The group state yielded by materialization, the deterministic derivation of group state from the log.
Member
A fact in the authority log plus key possession, not a certificate. Entered only by explicit, cryptographically bound consent.
Member anchor
The per-group context anchor under which one member acts in one group (DTG scope directed).
Mutual edge
An edge, from a party's local view, when for at least one enactment it has both issued and received.
Operation
A signed, causally anchored envelope.
Outgoing edge
An edge, from a party's local view, when it has issued its own credential and not received the counterparty's.
Pair anchor
An anchor derived for one enactment (DTG scope pairwise). The enacting anchor of a ceremony is a fresh pair anchor at every enactment.
Pending exit
The state of a member whose member.leave has merged but whose discharging transition has not.
Policy
Group-defined data stating, per rule key, which proof satisfies the group’s decision rule.
Policy proof
The material an operation is judged by against its rule: its signer set and its admissible vouch set.
Privileged operation
An operation of the closed catalog, each with its class (additive, enforcement, terminal), epoch effect and closed body profile.
Replica boundary
The set of parties holding, and entitled to hold, the group's replicated log at a given materialized state.
Retained members
The normatively computed set of members an enforcement operation’s new epoch secret reaches.
Service
A party that stores and forwards a group's items without holding its keys; its class (blind, view, log) is the registered statement of what it knows of the group.
Service class
The statement, declared at registration, of what a service knows of a group: blind (ciphertext only), view (also authorization views) or log (also the authority log). The group chooses.
Star
The artifact (star@1) by which a sender lets exactly one recipient relate the sender's contact set to the recipient's own: per deliverable contact only the count or the contact's anchor, blinded under a key for this direction and delivery. It is unsigned and recipient-forgeable, never carries a raw third-party anchor, and carries nothing about the sender's groups; those travel in the group star.
Step
One credential issuance within an enactment.
Visibility mode
The mode in which a group is readable from outside; publication runs through the publication port (open visibility: world-readable).
Vouch
A member's signed statement for exactly one admission of exactly one person (vouch@2, a DTG EndorsementCredential), bound to that person's accept; a group's vouch rule counts it for this one admission and no later one. How the voucher knows the person, met or introduced, is their own word, not verified; an encounter credential is not a vouch.
Welcome
The sealed rltp-welcome/0.1 document that carries the key material of one key state to an admitted person, bound to the group, the person and the accept it answers. The admitting operation commits to its plaintext by digest; it carries no history.
Welcome seal
The encryption a welcome travels in: the Delivery Contract's seal construction under its own HKDF info rltp/v1/welcome, addressed to the key-agreement key of the accept's card (the person's first device binding), never a delivery document.