@joe-broadhead/messaging 0.7.1 → 0.9.0

package/dist/spec/messaging-v1.md

@@ -1,5 +1,68 @@
 # Messaging protocol v1 (`messaging/1`)
 
+## Conversation IPC cut-over (2026-11-10)
+
+The live local API uses `CONVERSATION_METHODS` and `CONVERSATION_TIERS` from the normative core schema.
+The old `msg.send`, `person.send`, `channel.*`, `search`, `conv.subscribe`, `agents.list` and `agents.read`
+methods are removed, without aliases. `conv.list`, `conv.read` and batch `people.get`
+use the conversation schemas. Agent access follows design §8.5: `conv.get`, `conv.members` and `file.get`
+are human-only contracts. `file.get` remains staged. `sessions.list` is human-only and returns local sessions and their conversation seats.
+`request.waiting` labels an authenticated outgoing hold `held`, and missing-receipt evidence
+`pending-delivery`; missing receipts do not establish consent state. Contact requests remain visible while delivery is unconfirmed.
+Only a verified recipient receipt changes a contact request to `held`. Internal change notifications carry
+identifiers only; `conv.sync` re-reads verified state and selects safe rendered fields. Storage tables remain.
+A line first readable after its key arrives streams as an `event`; `event.update` carries only edits, deletions, reactions, pins and delivery.
+
+The daemon binds every agent call to a session registered on that connection. It rechecks membership and
+session ownership after asynchronous rendering. Agents edit/delete only their own lines. Cursors bind to
+the query and session; a daemon restart or engine replacement returns a stream gap. Replay renders current
+verified state, including edits and deletions, rather than caching historical plaintext. Projection refuses
+prefixes above 10,000 entries and responses above 512 KiB. These are interim safety bounds pending load tests.
+Only `LIVE_CONVERSATION_METHODS` is served. Later-lane contracts stay staged and have no socket handler.
+`contacts.list` returns verified conversation metadata: `cid`, `kind`, optional `name`, and optional `dmWith`.
+Only accepted conversations appear. Contacts carry no transcript, read position, or unread count.
+Channel contacts use the canonical `cid` as their address. Agent clients filter them through `conv.access`.
+Shared core operations retain contacts, inbox reads, and tasks. Conversation clients use `conv.*` for sends, pages, and search.
+Lane 4 omits read positions, preferences, unread counts and thread-follow state from views until lane 6 implements them.
+Filters on that state (`conv.list` `unread` and `mentions`, `conv.threads` `unread` and `following`) are refused with `invalid_request`, never answered with an empty page.
+`conv.backfill` verifies available relay history and returns `complete: false`. Completion requires an indexing coverage boundary that accounts for missing keys and expired entries.
+`clientId` deduplication commits atomically with a queued line and survives engine replacement; reuse with
+different content or a different destination is refused. Keyless conversation calls on a Jelly admin socket
+require an action grant, even when the same method is available to a bound agent session.
+
+Conversation maintenance coalesces verified membership changes for a random 0–30 second delay before answering
+shared channel history. Only accepted participants qualify. Successful responses are remembered per membership,
+epoch and recipient device set; failed or keyless responses remain retryable. The daemon sweep retries the
+conversation outbox, schedules due epoch rekeys, and expires local message ciphertext/plaintext and search rows
+while preserving digest links and control operations. Shutdown cancels response timers and waits for active work.
+
+Tasks and delegation retain their envelopes and lifecycle until lane 7. Agent-tier `task.create` replaces
+the task-creation arm of removed `msg.send`: it takes `key`, an agent `to`, `parts`, optional A2A fields,
+`wake`, `idempotencyKey`, and `onBehalfOf`. It assigns the task ID and signs the existing delegation chain.
+Agent-tier `task.continue` takes the same message fields and a required `taskId`, without `onBehalfOf`.
+It sends the retained task-follow-up envelope only to that session's existing task executor, preserving
+context, request binding, receipts, and terminal-state checks. Both return `{results: SendResult[]}`.
+`task.list/get/update/cancel` are unchanged. Plain mail uses `conv.send`, never a task envelope.
+The daemon rejects plain agent-mail envelopes, including previously held mail released after cut-over;
+it retains the database rows but does not expose them through inbox or item reads.
+
+The inbox combines retained task requests/follow-ups with verified incoming lines in accepted two-agent DMs
+addressed to this local session. Plain legacy mail rows are not returned. For a line, `id`, `messageId` and
+`eventId` equal the event ID, and `cid` names the conversation. `from.address` is the stable participant ID;
+its device is the verified signing device, and its label is absent, never synthesized. Task items retain their device provenance.
+`inbox.get/ack` and `item.read` accept an optional `cid`; an ambiguous ID requires it. The full `message`
+projection contains the line text, while `cid/eventId` lets the client read the safe event and file references.
+Edits are rendered on every read; deleted, inaccessible and unaccepted lines are not returned. `receivedAt`
+is the first local observation; `bytes` counts UTF-8 text. Stages are durable, monotonic local acknowledgments.
+Acknowledgments belong to the stable recipient participant and `(cid, eventId)`, not a process session key.
+An agent restart with a new session key preserves these stages and does not repeat wake hints for acknowledged lines.
+They do not manufacture envelope receipts. Recipient `ask` governs agent-DM admission: `open` accepts, `request` holds, and `no` silently declines.
+After admission, lines in the accepted agent DM follow the answer path. A later person block suppresses them.
+Person blocks also hide that person's events from conversation reads, search, previews and replay.
+The verified log remains intact. Hidden lines do not contribute reply summaries or reactions to visible lines.
+The push tier governs wake hints. New eligible lines use the existing session event and wake bridge; acknowledgments do
+not re-notify. Agent reads carry the same audience-label effect as conversation reads.
+
 Status: v1. The Zod schemas in `packages/core/src/schema/` are the
 normative wire contract; this document gives the semantics. If the two disagree, fix one of them in
 the same change, and add a test vector.
@@ -56,7 +119,10 @@ Not in v1: hole-punched peer-to-peer transport, federation between relays, and p
   `messaging/1/person\n`, `messaging/1/dir-read\n`, `messaging/1/device-log\n`, `messaging/1/device-keys\n`,
   `messaging/1/device-link\n`, `messaging/1/epoch\n` and `messaging/1/dir-key\n`, and for conversations (§16) the
   event signature prefix `messaging/1/conv-event\n` and the hash prefixes `messaging/1/conv-genesis\n`,
-  `messaging/1/dm\n` and `messaging/1/self\n`). A signature or hash for one purpose never verifies for another.
+  `messaging/1/dm\n` and `messaging/1/self\n`, and for contact requests and guest invitations
+  `messaging/1/contact-request\n`, `messaging/1/contact-request-content\n`, `messaging/1/contact-request-digest\n`,
+  `messaging/1/contact-request-decision\n`, `messaging/1/contact-authorization\n` and `messaging/1/guest-invitation\n`).
+  A signature or hash for one purpose never verifies for another.
 - **Hash:** SHA-256, base64url.
 
 ## 3. Identity
@@ -419,6 +485,14 @@ An envelope with an unknown `type`, or a newer `v`, is acknowledged to the relay
     update without `replyTo` fails the shape check of §5 (`invalid_request`). The requester's daemon
     drops an update whose `replyTo` is not its record of the request (`invalid_request`).
   - The requester's daemon applies them to its `TaskRecord` and publishes a `task` event.
+  - **Sign-in.** An executor whose task waits on a sign-in to a tool says which one with `task.update {state:
+    TASK_STATE_AUTH_REQUIRED, signIn: {tool}}` (`signIn` with any other state is invalid params). Its daemon puts the
+    tool in the status message as A2A v1 extension data: `metadata["urn:messaging:ext:sign-in:v1"] = {tool}`, with that
+    URI in the message's `extensions`. The message's parts are the session's `message`, or the fixed text "Sign-in
+    required." when it gave none, so the tool name is never copied into text. Extension metadata is how A2A v1 adds
+    fields to a `Message` without changing its parts, and a peer that does not know the extension still reads a valid
+    status. The requester's daemon stores the status as received and reads the tool only when it projects the task
+    (§8.2, "The task view"); nothing else in the extension is read, and whose sign-in it is never comes from the peer.
   - **What the relay sees.** It can link a task request to its updates, and count and time them. It
     learns no content and no state: the state is sealed. This is the correlation a relay needs to
     match a wake ticket to awaited answers.
@@ -475,7 +549,9 @@ Only the executor changes state (see `canTransition` in core).
   still run, and the person is away from that device. The host says so with `person.attached`; a Jelly host's device is
   away until its first `person.attached {attached: true}`, and no other device ever says `away`. A receiver shows that
   device as away (`people.get`), and an `away` older than the online window (§15.9: 150 s) means nothing.
-- `features` advertises optional capabilities. v1 defines `"tasks"`. A receiver ignores a feature it does not know.
+- `features` advertises optional capabilities. v1 defines `"tasks"`, `"conversations"` (the daemon reads conversation
+  logs; `conv.caps` reads it at the relay) and `"reach"` (the daemon enforces the person's reach choices, §6.9; the
+  person's own devices show it in `device.list`, §8.2). A receiver ignores a feature it does not know.
 - `label` must equal the sender's roster label. Receivers ignore a presence whose label differs, and
   always show the roster's label.
 - Like every envelope, presence carries the sender's `anchor` in its header (§5). Presence is
@@ -541,7 +617,7 @@ forwards a credential it was handed.
   - `exp`, the earliest along the chain.
 
   The requester's record holds the chain it sent.
-- **Delegating (§8.2).** A session delegates with `msg.send {kind: "task", onBehalfOf}`. Only
+- **Delegating (§8.2).** A session delegates with `task.create {onBehalfOf}`. Only
   the sending daemon signs, and clients never see or build grants.
   - Without `onBehalfOf`, a task starts a new chain whose root is the sending session.
   - A root grant made over IPC is unrestricted: no `scope`, and `maxDepth = LIMITS.delegationDepth`.
@@ -575,107 +651,26 @@ forwards a credential it was handed.
   code: fenced in a model context, `terminalSafe` in a terminal, `cleanPeerText` in a permission
   prompt. A client shows a chain only when it adds something beyond `from`: depth > 1 or a scope.
 
-### 6.8 Chats: DMs and channels
-
-A chat is a direct human message (room `dm:<person>`) or a channel (room `channel:<name>`). A
-channel has an id (a ULID chosen by its creator), a name (`ChannelName`), its creator, and a list of
-persons (`PersonId`s: roster person names, or hosted `p_…` ids in a directory realm), at most
-`LIMITS.channelPersons` including the creator. There is no group key and no chat
-between sessions: agent mail stays in the inbox and tasks.
-
-- **Wire.** A chat envelope is a sealed `message` with `kind: "message"`, addressed to a machine
-  with no agent (`to: {person, device}`) (§5, "Meaning"). A DM line carries no `conv`; a channel change
-  or post carries `conv: {kind: "channel", op, id, name, …}`. `message.messageId` is a ULID, the same on
-  every copy. A reply in a thread sets `message.contextId` to the `messageId` of the thread's first
-  line. A chat envelope is never `kind: "task"`, never has a `taskId`, and a
-  `message` to an agent never has a `conv` (`invalid_request`). `from.agent` is the session that
-  posted the line; a person's own line has no `from.agent` (§5, "Ends"). `name` on a channel op is
-  always the channel's own name.
-  - A DM line: one copy to each machine of the person, and none to the sender's own machines.
-  - A DM to oneself (`dm:<own person>`, the person's own conversation, "me"): one copy to each of the
-    person's other machines. A line one of the person's agents wrote there is for the person, so every
-    machine files it as incoming, unread; a line the person wrote is outgoing. Its lines carry no
-    delivery `state`: there is no other person to deliver them to.
-  - `create {id, name, persons, creator}`: the full record, one copy to each member machine but the
-    sender's. `persons` includes the sender; `creator` is the person who created the channel, so an
-    invitee learns it from the inviter's `create`.
-  - `invite {id, name, persons}`: the persons added, to the machines of the existing members. Each
-    machine of an added person gets a `create` with the full record instead. Persons with no
-    machine left on the roster are not in that record.
-  - `leave {id, name}`: the sender left, to every member machine.
-  - `remove {id, name, persons}`: the persons removed, to every member machine, the removed
-    persons' included.
-  - `post {id, name}`: a line, to every member machine.
-  - The text of a channel op is not filed. Each machine files its own notice line for an op it
-    applies, written by the daemon from the op's fields, with the op's `messageId` (§8.2 `notice`).
-- **Receiver rules.** Channels are looked up by `id`, never by name, and an op's `name` must match
-  the channel's own name (`not_found`). Where a rule fails, nothing is stored and the sender gets a
-  `rejected` receipt.
-  - `create` is accepted only for an unknown `id`, only when the sender and this machine's person are
-    both in `persons` (`forbidden`), and not for an id this machine
-    left or was removed from within the last `LIMITS.ttlMs + LIMITS.clockSkewMs` (`forbidden`). A
-    machine holds at most a policy number of channels (the reference daemon: 200); a `create`
-    beyond it is `rate_limited`. If this machine already holds a channel with that name, it keeps
-    the new one under a local name: the name cut to 28 characters, a hyphen and the lowest free
-    number from 2 (`eng-2`), or `rate_limited` when 2 to 99 are all taken. Room references
-    (`channel:<name>`), `conv.*`, `search`, `person.send` and `channel.*` use the local name; envelopes always carry the
-    channel's own name. This also covers two people creating the same name at once.
-  - A `create` or `invite` naming a person this machine cannot admit is `not_found`: in a roster realm a
-    person with no current machine; in a directory realm any id that is not a hosted person. A directory
-    home takes persons it has not verified yet, then looks them up and watches them (§15.9).
-  - `invite` is accepted only from a current member, and only when the channel stays within the
-    limit (`forbidden`, `invalid_request`).
-  - `leave` removes only the sender. When this machine's person leaves (from another of its
-    machines), the channel and its lines are deleted here.
-  - `remove` is accepted only from a member who is the channel's creator or a team admin on the
-    verified roster (`forbidden`), never naming the sender (`invalid_request`: use `leave`), and only
-    for current members (`not_found`). A machine whose person is removed deletes the channel and its
-    lines, as on `leave`, and refuses a `create` for that id as above. Other machines remove those
-    persons from the channel.
-  - `post` is filed only when the sender and this machine's person are both members (`forbidden`).
-  - Every name in `persons` must be a person on the roster (`not_found`). All of this is checked
-    before anything is stored.
-  - A DM line from the receiver's own person is filed in its own conversation, as above.
-  - A person who has no machine left on the roster is no longer a member of any channel; each
-    machine drops them when it applies the removal.
-- **Delivery.** An accepted chat envelope gets a `delivered` receipt. It creates no inbox item, does
-  not count against the inbox quota (§8.3) and never wakes a session. Consent (§6.9) and the inbound
-  rate limit still apply. The sender records each chat envelope it routes with its line and
-  recipient. A receipt from that recipient's machine, a relay nack, the recipient leaving the roster
-  or expiry settles the record, once. An outgoing line is `delivered` once every other person has a
-  delivered copy, and `refused` once some person's every copy was rejected or expired; until then
-  it is `sent`. When every copy of a channel change to one person is refused, the sender files a
-  notice line in that channel naming the person and the code. Notice lines are never sent.
-- **Transcript.** Each daemon keeps one row per line, keyed by `messageId`; a later envelope with a
-  `messageId` this machine already holds is not filed and changes nothing. The thread key is the
-  first line's `messageId`. Text is the line's text parts joined by newlines, cut to
-  `LIMITS.chatChars` UTF-16 code units without splitting a surrogate pair. The sender files its own
-  line with the plaintext it sealed; that copy is not on the wire. A person's line that arrives from
-  another of their machines is filed as outgoing. Retention deletes lines after
-  `retention.transcriptDays` (default 30), and a per-person cap deletes a sender's oldest lines
-  first once they hold more than a policy number of lines or bytes (the reference daemon: 10,000
-  lines or 16 MiB of UTF-8 text).
-- **Order and read state.** Each daemon numbers its chat changes with one counter that only
-  rises and is never reused (`seq`, from 1): every filed line takes the next number, and so does
-  every later change of a line (its delivery state) and every channel deleted here. A line keeps the
-  number it was filed with as its `seq`, its place in this machine's order; another machine numbers
-  the same line differently. Paging and read cursors use it. Read state is per machine and per room:
-  a cursor (`readUpTo`, 0 at first) that only moves forward and never past the newest number here.
-  A line is unread when another person's line, or the daemon's notice of another person's change,
-  was filed after the cursor; this person's own lines never are. Leaving a channel, or being removed
-  from it, deletes its cursor with its lines. Nothing syncs read state between machines.
-- **Joining later.** A person invited later does not receive earlier lines. Membership is each
-  machine's own view: concurrent invites or removals can leave machines with different member
-  lists, and nothing reconciles them. A post refused because of that shows as `refused` to its
-  sender.
-- **Reading.** `conv.list`, `conv.read` and `search` (§8.2) see the DMs this machine holds and
-  the channels its person is in. Agent-facing clients fence chat text as peer content and ask
-  before reading it.
+### 6.8 Conversations: DMs, groups and channels
+
+Conversations use the signed log and sender-key encryption in §16. A `cid` identifies a conversation across devices.
+The daemon verifies each prefix before it exposes membership, content or delivery state.
+Legacy chat envelopes and room-name APIs are removed. Existing database tables remain for store compatibility.
+
+- **Participants.** A participant is a person or a stable `person/agent` address. Verified bindings identify each signing device.
+- **Admission.** An invitee receives authenticated controls and message digests before acceptance, but no ciphertext or keys.
+  Agent-DM admission follows the receiving person's `ask` level (§6.9).
+- **History.** The signed history policy controls access after acceptance. Recovery replaces matching invitation digests with authenticated entries.
+  It survives restart and does not restore content deleted by later retention.
+- **Delivery.** Conversation sends return `pending` until verified append evidence arrives. Missing receipts never establish an outgoing consent hold.
+- **Reading.** `conv.list`, `conv.read`, `conv.search` and `conv.context` expose current verified projections.
+  Agent reads require a registered session, access checks and the audience guard. Clients fence peer content (§12).
+- **Read state.** Lane 4 omits read positions, unread counts, preferences and follow state. Their methods remain staged until later lanes implement them.
 
 ### 6.9 Consent
 
 Consent belongs to the receiving person. A person's **grants** say what each other person, and the
-members of each channel, may send them and their agents. A device of the person signs each grant,
+participants of each conversation, may send them and their agents. A device of the person signs each grant,
 only the person's own devices hold it, and the receiving daemon enforces it. Agents never sign or
 change a grant.
 
@@ -694,7 +689,7 @@ A roster realm has only `self` and `org`.
 
 ```ts
 { v, realm, id: Ulid, person, by: MachineId, ts,
-  subject: { person } | { channel: <channel id> },
+  subject: { person } | { conv: ConvId } | { relation: "outside" | "org" },
   chat?: "open" | "muted" | "blocked",   // lines from the subject (person subjects only)
   agentMail?: "open" | "blocked",        // lines from the subject's agents
   ask?: "open" | "request" | "no",       // mail and tasks from the subject or their agents to the person's agents
@@ -706,8 +701,10 @@ A roster realm has only `self` and `org`.
 
 - `sig` = Ed25519(`by`, `"messaging/1/grant\n"` ‖ JCS(grant without `sig`)). `by` is a device of `person`.
 - `person` and a person subject are `PersonId`s: a roster person name, or a hosted realm's `p_…` id (§15.1).
-- A channel grant sets only `ask` and `agentMail`. It applies to a sender only while the sender is a
-  member of that channel in the receiver's own view (§6.8).
+- A conversation grant sets only `ask` and `agentMail`. Both persons must be active participants in the locally verified conversation.
+- A relation grant records a reach choice ("Reach choices", below): the `outside` grant sets only `chat`, `open` or
+  `blocked`; the `org` grant sets only `ask`.
+  For an event-specific decision, membership is evaluated at that event's position.
 - `trustedUntil` needs `ask: "open"` and is at most `ts + LIMITS.trustMaxMs` (90 days). Trust is set
   for `LIMITS.trustDefaultMs` (30 days) when the person names no end. An expired `trustedUntil` reads
   as absent.
@@ -742,8 +739,9 @@ the person:
 **Effective policy.** For a sender S, each level is, in order:
 
 1. the person grant for S, where it sets the level;
-2. otherwise, for `ask` and `agentMail`, the most permissive among the grants of channels S is in;
-3. otherwise the default for the relation:
+2. otherwise, for `ask` and `agentMail`, the most permissive grant of a verified conversation shared with S;
+3. otherwise the person's reach choice for S's relation, where they made one ("Reach choices");
+4. otherwise the default for the relation:
 
 | Relation | `chat` | `agentMail` | `ask` | trust |
 |---|---|---|---|---|
@@ -752,8 +750,70 @@ the person:
 | `contact` | open | blocked | no | off |
 | `stranger` | `request_required` | blocked | no | off |
 
-Only the person grant trusts. A `blocked` chat level also refuses agent mail, asks and channel changes
-from S.
+Only the person grant trusts. A `blocked` chat level from the person grant also refuses agent mail, asks and
+channel changes from S.
+
+**Reach choices.** A person answers two questions, each Open, Ask me first or Never (owner, 2026-11-10). Ask me
+first is the default, and it is what the relation defaults already do. The person's devices record each answer as
+a grant on a relation subject, so it is signed, merged, re-signed, lapses and syncs like any other grant:
+
+| Question | Subject | Open | Ask me first | Never |
+|---|---|---|---|---|
+| "Who can message you" | `{relation: "outside"}` | `chat: "open"` | a grant with no level | `chat: "blocked"` |
+| "How agents may ask yours" | `{relation: "org"}` | `ask: "open"` | `ask: "request"` | `ask: "no"` |
+
+No grant for a subject means no choice: the defaults apply, the same as Ask me first. The choices set step 3 of
+"Effective policy", under every person and conversation grant:
+
+| S | `chat` under Open | under Ask me first or no choice | under Never |
+|---|---|---|---|
+| `org` | open | open | open |
+| `contact` | open | open | blocked |
+| `stranger` | open | `request_required` | blocked |
+
+| S | `ask` under Open | under Ask me first or no choice | under Never |
+|---|---|---|---|
+| `org` | open (`guarded`) | request | no |
+| `contact`, `stranger` | no | no | no |
+
+- **"Who can message you"** is about the people outside the person's org. The org stays `open`. A `contact` has
+  already been let in (the person accepted their request, sent them one, or granted them something), so Ask me
+  first leaves them `open`, as it did before the choice existed; Never blocks one whose person grant sets no `chat`.
+  So no answer opens anything the person had closed, and the default changes nothing.
+- **"How agents may ask yours"** is about the agents of the person's org. Agents of people outside the org stay
+  `no`: only a person or conversation grant lets them ask.
+- **A grant set for one person or conversation wins.** A person grant's `chat` (an accepted request sets `open`)
+  and its `ask`, and a conversation grant's `ask` and `agentMail`, all come before the choice. So a conversation
+  grant with `ask: "open"` still lets the agents of that conversation's participants ask under Never: an explicit
+  grant for one person or conversation wins over the account-wide choice (coordinator, 2026-11-10, under the owner's
+  rule).
+- A `blocked` chat level that comes from Never refuses S's new lines, message requests and channel changes as they
+  arrive. For conversations that already exist, Never hides S's lines and channel-change notices from the person's
+  view; it can't undo a change S makes to a shared conversation. It does not refuse agent mail or asks: they follow
+  their own levels, so a grant that opened them still counts.
+- **In conversations that already exist** the same rule applies on the person's own view: the daemon's reads of a
+  conversation (`conv.read`, `conv.sync`, `conv.search`, `conv.context` and the stream) leave out the lines and
+  channel-change notices of S while S's effective `chat` is `blocked`, whether a person grant or Never set it. Never
+  leaves out only an S the realm's verified profile shows in another org (`org: "other"`); the org is never left out,
+  and neither is a person the realm no longer knows (a departed teammate), history included (owner, 2026-11-10). A
+  person grant's block still leaves out anyone. An agent of S is left out only by a person grant's block (agent
+  mail follows its own level). A channel change S makes is still applied to the conversation's state; only its
+  notice is left out of the person's view.
+  Like a person-grant block, this filters what the person sees and is undone when the choice changes. The
+  conversation's log, and the other participants' views of it, are unchanged.
+- **Signers.** The rule of "Signers" applies as written: `chat: "blocked"` and `ask: "no"` are kept when their
+  signer is removed; `chat: "open"`, `ask: "open"` and `ask: "request"` lapse into the review list, and the choice
+  goes back to none. A grant with no level lapses whole.
+- **Cards.** A card computes its levels with the choices (`cardCan`). A change of a choice sends no cards: a card
+  is advice, and S learns on its next refusal.
+- **Store.** The daemon keeps relation grants and their review entries in tables of their own (§8.8, schema 5),
+  not in `grants`: a daemon from before schema 5 drops a row of `grants` that does not verify for it, so a host
+  that rolled the binary back would lose the person's choices.
+- **Older daemons do not enforce the choices.** A daemon from before schema 5 keeps the relation grants it is sent
+  out of its view, so it applies the relation defaults: a stranger may send it a message request again, and a
+  teammate's ask is held there, not refused. Envelopes go to every device of the person, so after a binary rollback,
+  or while any of the person's devices runs an older release, a choice that narrows reach (Never) is not enforced on
+  that device. A client should warn while any of the person's devices reports a store schema below 5.
 
 **Contact cards.** A person's card tells another person what they may send the person. The schema is
 `ContactCard` in `schema/consent.ts`:
@@ -767,7 +827,7 @@ from S.
 - `sig` = Ed25519(`by`, `"messaging/1/card\n"` ‖ JCS(card without `sig`)). `by` is a device of `from`; `from` and
   `to` are different persons. `trustedUntil` needs `ask: "open"`. A card is at most `LIMITS.cardBytes` of JCS.
 - `can` is the person grant for S over the defaults of S's relation to R (core's `cardCan`): `chat` is true for
-  `open` and `muted`, `agentMail` for `open`. Channel grants are not on a card: S knows its own channels.
+  `open` and `muted`, `agentMail` for `open`. Conversation grants are not on a card.
 - `seq` rises with every card R's devices send S; S keeps the card with the highest `seq`.
 - Core's `verifyContactCard` checks the schema, the rules, the size, the realm, both persons and the signature over
   the raw value. Whether `by` is a current device of R is the caller's: a card signed by a device R no longer has
@@ -782,11 +842,11 @@ from S.
 | Anything from the receiver's own person | Deliver, `self` |
 | An answer to the person's own traffic: a receipt, `task.status`, `task.artifact`, `task.cancel`, or a message the counterpart binding (§5) ties to earlier traffic | Deliver, whatever the grants, so a grant change never strands a task the person started. `trusted` while the person grant trusts the sender, else `guarded` |
 | Anything else, while `chat` is `blocked` | Refuse, `refused` |
-| A DM line or channel post by the person S | `chat`: `open` delivers, `muted` delivers silently, `request_required` refuses with that code |
-| A line or channel post by an agent of S | `agentMail`: `open` delivers; otherwise refuse, `refused` (`request_required` for a `stranger` when no grant set it) |
-| A channel change | Deliver; a `stranger` is refused with `request_required` |
-| Mail or a task request to one of the person's agents (an ask) | `ask`: `open` delivers `guarded`, or `trusted` (below); `request` holds it for the person; `no` refuses, `request_required` when it is the default of a `contact` or a `stranger`, else `refused` |
-| A message request (class `request`, "Message requests") | From a `stranger`: hold it for the person. From anyone else: as a DM line by the person S |
+| A DM line or channel post by the person S | `chat`: `open` delivers, `muted` delivers silently, `blocked` (from Never) refuses with `refused`, `request_required` refuses with that code |
+| A line or channel post by an agent of S | `agentMail`: `open` delivers; otherwise refuse, `refused` (`request_required` for a `stranger` when no grant set it and the person did not choose Never) |
+| A channel change | Deliver; refuse while `chat` is `blocked` (from Never), `refused`; a `stranger` is refused with `request_required` |
+| Mail or a task request to one of the person's agents (an ask) | `ask`: `open` delivers `guarded`, or `trusted` (below); `request` holds it for the person; `no` refuses, `request_required` when it is the default of a `contact` or a `stranger` and the person did not choose Never for messages, else `refused` |
+| A message request (class `request`, "Message requests") | While `chat` is `request_required` (a `stranger` under Ask me first): hold it for the person. While `chat` is `blocked` (from Never): refuse, `refused`. Otherwise: as a DM line by the person S |
 
 - **Trust and the chain rule.** An ask runs `trusted` only while the person grant's `trustedUntil` is
   past now and every person in its delegation chain (§6.7) is S or the receiver. Otherwise it runs
@@ -824,40 +884,27 @@ from S.
     A delivered request then passes the inbound policy of §8.3 as any other;
   - a request ends unanswered at its expiry: the sender's own expiry settles its side. A request
     whose sender has left the realm ends at the answer, with nothing sent.
-- **Message requests** (a directory realm only). A person of one org first writes to a person of another with a
-  message request: a `message` of class `request` with `conv: {kind: "request"}` and one text part of at most
-  `LIMITS.requestChars` (§5, "Meaning"). Only a person sends one, with the human-tier `contact.request` (§8.2);
-  agents never send or answer one.
+- **Message requests** (a directory realm only). Human first contact across orgs uses `contact.request` and a portable request proof (§16).
+  Its `message` envelope carries `conv: {kind: "request", proof}` and one text part, bounded by `LIMITS.requestChars`.
+  The envelope expiry must equal the signed descriptor expiry. Agents cannot send or answer contact requests.
   - **Addressing.** The person gives an exact email. The daemon resolves it at the directory (`dir.resolve
     {email}`, §7); no answer is `not_found`, "no Messaging user with that email accepts requests", the same for an
     unknown and an undiscoverable email, so it cannot tell them apart. Several persons for one email is
     `ambiguous_address`.
-  - **Sending.** The request goes to every current device of that person, one copy each, and is filed as the
-    person's own line in `dm:<person>`. Its delivery state (§6.8) is `held` while each copy not yet delivered is
-    held for the other person, `delivered` once they accept, `refused` once they decline. Before it sends, the
-    daemon sets the person's own grant for the other to `chat: "open"` when it sets no chat level, so the answer,
-    the card an accept sends and the other's lines reach the person; a person who blocked the other is refused
-    `invalid_state`. The daemon paces before it sends (`rate_limited`): one request waits per person until that
-    person writes back (or for `LIMITS.ttlMs`), and at most `LIMITS.requestsPerDay` persons are asked a day. The
-    relay paces the same by the header (§15.10); its `rate_limited` nack of a request is final, not retried, and
-    refuses the line.
-  - **Receiving.** `decide` holds a request from a `stranger`; from anyone else it is a DM line by the sender, and
-    from a blocked sender it is `refused`. A held request is stored with its envelope and opened payload (§8.8,
-    `contact_requests`), one per sending person and at most `LIMITS.heldTotal` in all (`rate_limited`), answered with a
-    `held` receipt and filed as a `request` notice (§8.2). It reaches no agent and wakes nothing. A request in a
-    roster realm is `invalid_request`: a roster realm is one org.
-  - **Answering** (`request.answer`): `accept` sets the sender's grant to `chat: "open"` (keeping its other
-    levels), which makes the sender a `contact` and sends them a card, then files the request's text as their
-    first line in `dm:<sender>` and answers `delivered`; `decline` answers `rejected {code: "declined"}`; `block`
-    sets `chat: "blocked"`, then declines. A request ends unanswered at its expiry. Every device of the person
-    holds its own copy: a grant for the sender that another device of the person signed, arriving by "Sync", settles
-    the copy held here as its answer did (`chat: "open"` accepts it, `blocked` declines it).
+  - **Sending.** The daemon sends one copy to each current recipient device and returns `{id,cid,person}`.
+    It stores the request separately from conversation history. An authenticated recipient receipt establishes an outgoing hold.
+    A missing receipt means pending delivery, not a hold. One request can wait per person, subject to `LIMITS.requestsPerDay`.
+  - **Receiving.** The daemon verifies the portable proof, envelope binding and expiry before it stores the request.
+    A stranger's request waits for the person. An allowed contact or same-org request follows the signed acceptance and import path automatically.
+    A blocked sender is refused. The opening reaches no agent and triggers no wake before or after import.
+  - **Answering.** `request.answer {answer:"accept"}` settles a signed mailbox decision, grants chat access, and imports exactly one opening into the deterministic DM.
+    The import uses the descriptor ID and permanent completion evidence. Concurrent accepting devices reconcile against the same verified operations and completion.
+    `decline` settles a signed decline. `block` also sets `chat:"blocked"`. A grant or card alone is not a terminal decision.
+    The daemon resumes interrupted acceptance after restart and sends a contact card after successful import.
   - **The sender's card is the directory's.** Clients show the sender of a request by the realm's verified profile
     (name, email, org, §15.1), never by the request's text.
-  - **Agents.** An agent that needs a contact in another org asks its own person: a line to the person with
-    `request: {contact: <email>}` (`msg.send`, §8.2). The daemon files the line and a suggestion, listed by
-    `request.list` and filed as a `request` notice; the person sends the request with `contact.request`
-    (`suggestion` dismisses it), or dismisses it with `request.answer {answer: "decline"}`.
+  - **Agents.** Legacy contact suggestions remain dismissible. The removed `msg.send` method cannot create new suggestions.
+    Agent-to-agent DMs use recipient invitation admission instead of human contact requests.
 - **Cards on the daemon.** A device sends a card (a `message` with `conv: {kind: "card", what: "card"}`) to each
   current device of a person S when this person's grant for S changes on this device (`grant.set`, an answer to
   a request, a re-sign under "Signers"), and when S asks with `card.get`. It sends none to a `stranger` and none to
@@ -868,14 +915,7 @@ from S.
   person; it answers nothing. A `rejected` receipt from a person with `refused`, `request_required` or `declined`
   drops their card and asks for a fresh one. The `seq` of a device's cards is its clock in milliseconds, raised
   past the last one it used. A card is not a first message for the freshness bound (§15.9).
-- **Pacing.** Lines from one person's agents to another person (A2H), summed over those agents, are
-  limited to `LIMITS.a2hPerHour` (30) an hour and `LIMITS.a2hPerDay` (100) a day:
-  - the sending daemon refuses an agent's DM line or channel post at send time (`msg.send` to a person
-    or `#channel`), before it stores or sends anything, when it would take any recipient person past either
-    count, with `rate_limited` and when to try again; the person's own lines are not paced;
-  - the receiving daemon refuses an agent's line past either count from one sending person with a
-    `rejected` receipt, `rate_limited`, for a sender that does not pace itself;
-  - the reference daemon counts in memory, so a restart starts the windows again.
+- **Pacing.** Conversation append limits replace legacy chat-envelope pacing (§16). Retained task envelopes still follow the relay and inbound limits (§7, §8.3).
 - **Sync.** A device sends each grant it signs or re-signs to each of its person's other current
   devices: a sealed `message` to the device with no agent, `conv: {kind: "self", what: "grant"}`,
   whose one data part is `{grants}`. A device of the person that is new to the sender (one it has
@@ -1210,7 +1250,7 @@ hosted `hello` as a malformed one (4001).
 | `dir.watch {persons}`, at most `LIMITS.watchPersons` (500) | `dir.ok {}` |
 | `presence.watch {persons}`, at most `LIMITS.watchPersons` | `dir.ok {}` |
 | `dir.erase {entries, token}`: an `unbind` of each current device, at most `LIMITS.devicesPerPerson` (10), and a compact JWS | `dir.ok {}` |
-| `wake.arm {url, ticket, agents, awaiting}`: a Jelly host's wake ticket ("Wake tickets" below) | `dir.ok {}` |
+| `wake.arm {url, ticket, agents, awaiting, dms?}`: a Jelly host's wake ticket ("Wake tickets" below) | `dir.ok {}` |
 | `wake.disarm {}` | `dir.ok {}` |
 
 - **`dir.sthIs`.** The STH at `size`, or the latest. `head` is its last epoch-log leaf (index `size − 1`) with
@@ -1246,7 +1286,7 @@ hosted `hello` as a malformed one (4001).
 daemon arms it at its relay (`wake.arm`, §8.11). While that device is offline, the relay may present the ticket to
 Jelly ID, which wakes the host.
 
-- **`wake.arm {url, ticket, agents, awaiting}`**, after `hello` (`forbidden` before it), from a current device:
+- **`wake.arm {url, ticket, agents, awaiting, dms?}`**, after `hello` (`forbidden` before it), from a current device:
   - `url` is Jelly ID's wake endpoint of this device's host, `https://<issuer host>/hosts/<hst>/wake` (`WakeUrl`): its
     origin must be the realm's Jelly ID issuer's (`invalid_request`), and `<hst>` the `hst` of the Jelly token of this
     device's latest `bind` or `attest` that names one (`forbidden` otherwise, and for a device no host bound);
@@ -1254,20 +1294,38 @@ Jelly ID, which wakes the host.
     unverified (`readWakeTicket`), only the header's `typ` and `alg` (`jelly-wake+jwt`, `EdDSA`), and the claims `exp`
     (it must be in the future and at most seven days and 60 s ahead), `aud` (when present, exactly `url`) and `sub`
     (when present, exactly `<hst>`); any other is `invalid_request`;
-  - `agents` (at most 64 session names) are the device's sessions whose own person's mail may wake the host, and
-    `awaiting` (at most 500 envelope ids) the requests whose task updates may wake it.
+  - `agents` (at most 64 session names) are the device's sessions whose own person's mail may wake the host,
+    `awaiting` (at most 500 envelope ids) the requests whose task updates may wake it, and `dms` (at most `WAKE_DMS`
+    (256) conversation ids; absent is none) the dm conversations in which another person's events may wake it. The
+    host's daemon chooses them (§8.11, "Wake tickets"); the relay checks only their form and the cap.
 
   It replaces the device's earlier ticket, and is kept in the relay's store (`dir_wakes`, §8.8) until it is
   used, disarmed, its device is unbound or erased, or it expires. At most 60 arms a device in a burst, then one a
   minute (`rate_limited` with `retryAfterMs`). `wake.disarm {}` forgets the device's ticket.
-- **When the relay presents it.** Only when the relay has just taken (§7 "Routing": first seen, queued) an envelope for
-  the device while the device has no connection, and the envelope is:
-  - the person's own mail to an armed agent: header type `message`, `from.person` = `to.person`, and `to.agent` in
-    `agents`; or
-  - an answer the device awaits: header type `task.status` or `task.artifact` whose `replyTo` is in `awaiting`.
-
-  Lines and posts (no `to.agent`), receipts, presence, task requests and cancels, anyone else's mail, a message that
-  merely names an awaited request, and anything for a connected device never wake. A request the recipient's person
+- **When the relay presents it.** Only while the device has no connection, and only for one of these:
+  - **a conversation line by the device's own person to an armed agent.** The relay has just stored (`conv.ok`, §7
+    "Conversation frames") a `msg` event whose `wake` hint (§16.2) names a session in `agents`. The person is the one
+    of the authenticated device that appended the event (which `by.person` must match), never the event's claims
+    alone, and only that person's current devices are considered. A person's own mail to their agent is such a line
+    (design §8.2, "Wake"): their daemon sets `wake` to the sessions of their own agents a line addresses, a dm whose
+    other end is one of them or a mention of one, and never names another person's session. A `wake` hint on another
+    person's event reaches only that person's own devices, so it never wakes anyone else's host. A repeated append
+    (`conv.ok` again for the same event) does not present again. The reason logged is `own`;
+  - **an event in an armed dm by its other person** (owner, 2026-11-10, opencode-messaging #19). The relay has just
+    stored a `msg` event in a conversation whose kind is `dm` (its plaintext `create` op) and whose `cid` is in the
+    device's `dms`, and the authenticated author's person is not the device's person. Only the current devices of
+    the conversation's participant persons other than the author's are considered. The relay cannot tell a line
+    from another sealed event (a reaction, an edit, a receipt), so any such `msg` may wake; the budget below bounds
+    it. Ops, the person's own events (their own lines wake only by the hint above) and a dm the device did not arm
+    never wake by this rule. Arming learns the relay nothing new: dm membership is plaintext to it. A repeated
+    append does not present again. The reason logged is `dm`, without the conversation;
+  - **an envelope** the relay has just taken (§7 "Routing": first seen, queued) for the device that is:
+    - the person's own mail to an armed agent: header type `message`, `from.person` = `to.person`, and `to.agent` in
+      `agents` (a task request, which keeps its envelope); or
+    - an answer the device awaits: header type `task.status` or `task.artifact` whose `replyTo` is in `awaiting`.
+
+  Conversation events without a `wake` hint (posts, receipts, another person's lines) outside an armed dm, presence, task cancels, anyone
+  else's mail, a message that merely names an awaited request, and anything for a connected device never wake. A request the recipient's person
   must answer (§6.9) is held by the receiving daemon, which the relay cannot see: such mail never wakes unless it is
   the person's own.
 - **Presenting.** `POST <url>` with the form `client_assertion_type=urn:jelly:wake&ticket=<ticket>`, no redirect
@@ -1280,8 +1338,8 @@ Jelly ID, which wakes the host.
   - `503`, any other 5xx, or no answer: kept, and presented again a minute later if the device is still offline. That
     retry has waited out the gap on its own timer and is not held back again by the one-a-minute rule, however the
     relay's clock and its timers drift; new traffic within the minute is.
-- **Never logged.** The ticket is in no log line; a presentation is logged with the device, why (`own`, `awaited`,
-  `retry`) and the status.
+- **Never logged.** The ticket is in no log line, nor are the armed `dms`; a presentation is logged with the
+  device, why (`own`, `dm`, `awaited`, `retry`) and the status.
 - **What a relay can and cannot do with a ticket.** A relay that keeps or leaks a ticket can, at most, wake that one
   host once, before the ticket's `exp`: Jelly ID spends its `jti` on the wake, checks that it is that host's (its
   signature by the host's enrolled key, `iss`, `sub` and `aud`), and holds every host to its budget (6 an hour, 48 a
@@ -1289,9 +1347,83 @@ Jelly ID, which wakes the host.
   waking a host gives the presenter nothing on it: the host's daemon then reconnects and fetches its mail as usual.
   Nor can a relay mint or widen one: it cannot sign for the host's key, and an `aud` names one host's URL. The relay
   learns that the host sleeps (it already sees the device go offline), which agents may wake it (presence already
-  names them), and the ids of the task requests it awaits (envelope ids it already routed). A malicious relay can also
+  names them), the ids of the task requests it awaits (envelope ids it already routed), and which of its dms may
+wake it (the relay already holds every dm's membership). A malicious relay can also
   fail to wake a host, as it can drop any envelope; that delays the person's mail, it loses none.
 
+**Conversation frames** (`schema/conv-frames.ts`; §16). After `hello`, in a roster realm and in a directory realm
+alike, the relay sequences conversation logs. It is never trusted for authority: it sequences and filters, and
+members verify every entry (§16.4, §16.7). Every frame is strict; a refusal is `nack {id: req, code, message}`.
+
+- **`conv.append {req, event}`**, an `op` or a `msg` (a `keys` event is `invalid_request`: shares go in
+  `conv.share`). The relay checks, in order:
+  1. the frame's schema and `LIMITS.convEventBytes` (`too_large`); `by.device` is the authenticated device
+     (`forbidden`);
+  2. the rate limits below (`rate_limited` with `retryAfterMs`);
+  3. a `create` against an empty log first, so a person who could not create it learns nothing of an existing one;
+     then a `create` of an existing conversation is `conv_conflict`;
+  4. a person who is not a participant person of an existing conversation gets `not_found`, as for a conversation
+     that does not exist (no existence oracle for derived dm ids), except for a `join`;
+  5. `ConvLog.apply` against the relay's copy of the log at its head, with the live checks (§16.7, step 4): `ts`
+     within the clock skew, `by.device` a current device of `by.person`, and the org of a person for `join` and
+     `add`. In a directory realm the devices and orgs are the directory's (§15.10); in a roster realm they are the
+     roster's, and the realm is one org, its team id. An `op` whose `opHead` is not the current op head is
+     `conv_conflict`; a `msg` under another epoch, or while a rekey is due, is `stale_epoch`;
+  6. every person a `create` or `add` names has a current device in the realm (`not_found`), and no person would
+     take part in more than `LIMITS.convsPerDevice` (5000) conversations (`too_large`).
+
+  It then assigns `seq`, stores the entry and answers `conv.ok {req, cid, seq, hash}` once it is committed (the
+  group commit, as for `send`), and pushes `conv.push {cid, entry}` to the other online devices of every participant
+  person before and after the entry, so a removed person's devices see their removal. A repeat of an event the log
+  holds (the same JCS) is answered `conv.ok` again, with its first `seq`; another event with a used `id` is
+  `duplicate`.
+- **`conv.share {req, events}`**: 1 to `LIMITS.convSharesPerFrame` (100) key shares (§16.6), all of one
+  conversation and by the authenticated device. Each must pass `ConvLog.checkShare` live, with `opHead` the current
+  op head (`conv_conflict`), so a person removed since gets none. All or none are stored; the relay answers
+  `conv.shared {req, cid, count}` and pushes `conv.push {cid, share: {n, event}}` to each recipient device online,
+  and to no other device. A previously stored share repeated with identical JCS is acknowledged without storing or
+  pushing it again, even if the op head has since advanced. A used id with different content is `duplicate`. A new
+  share must still pass all current checks; the repeat rule never delivers an old share to a removed device.
+- **`conv.fetch {req, cid, after, limit?, sharesAfter?}`** → `conv.entries {req, cid, head, entries, shares, more}`:
+  the entries after `after` in `seq` order, at most `limit` (`LIMITS.convFetchEntries` (500)) and as many as fit in
+  three quarters of a frame (at least one). An expired `msg` is served as `{seq, prev, digest}`; an op never is. With
+  `sharesAfter`, also this device's shares after that `n`; no other device's share is ever served. `more` says
+  there is more of either. Only a device of a participant person may fetch (`not_found` otherwise).
+- **`conv.head {req, cids? | after?}`** → `conv.heads {req, heads: [{cid, head, opHead, shares}], more}`: the heads
+  of the named conversations this device's person takes part in, or, without `cids`, of all of them by `cid` after
+  `after`, at most `LIMITS.convHeads` (500) each way. `shares` is the last share `n` for this device (0: none). A
+  device that comes back online asks this first, then fetches what moved.
+- **`conv.caps {req, persons}`** → `conv.capabilities {req, outdated, unknown?}`: of at most `LIMITS.convOpParticipants` named
+  persons, those every one of whose current devices with a stored, unexpired presence names no `conversations`
+  feature: a daemon from before conversations, which reads no log. A person with no such presence is not named, since
+  no presence is no evidence. It is a hint from the relay and can only make a sender refuse: before it creates a dm,
+  group or channel with that person, adds them, or sends them a message request, a daemon asks, and refuses with
+  `peer_outdated` ("<handle> needs to update Messaging"), creating and sending nothing. It reveals one bit about a
+  person of the realm, whom the asker can already name. So that it is no presence oracle, a person the asker does not
+  already relate to (the presence audience of §15.10: the same person, the same org, envelopes both ways in 30
+  days, or accepted members of one conversation; a roster realm is one org) counts against a budget of
+  `LIMITS.requestsPerDay` distinct persons per asking person (not per device) per UTC day, the message-request
+  budget. Related persons, and persons already asked about that day, are always answered. A new unrelated person past
+  the budget is not answered: the reply names them in `unknown` (present only when not empty), and the daemon goes
+  ahead for them as without an answer. Every other person in the same frame is still answered, so a daemon refuses
+  with `peer_outdated` for any person the reply names in `outdated`, whatever else the frame holds.
+- **Retention.** Once a minute the relay prunes the bodies of `msg` entries older than the conversation's
+  `retainDays` (as of its head), by the time it sequenced them, keeping each entry's `seq`, `prev` and digest
+  (§16.4), and deletes the key shares older than it. It never prunes an op.
+- **Limits** (per conversation and device, in memory; a restart refills them):
+  - appends by one device to one conversation: a burst of `LIMITS.convAppendBurst` (20), refilled at
+    `LIMITS.convAppendsPerMinute` (60) a minute; by all its devices, `LIMITS.convAppendsPerConvPerMinute` (600) a
+    minute;
+  - `rekey` ops whose cause the log cannot prove (`device`, `schedule`): `LIMITS.convRekeysPerHour` (4) per device
+    per conversation an hour;
+  - creates: `LIMITS.convCreatesPerHour` (60) per device an hour;
+  - key shares: `LIMITS.convSharesPerMinute` (10,000) per device per conversation a minute, and at most
+    `LIMITS.convSharesPerPair` (256) kept from one sender device for one recipient device in one conversation
+    (`rate_limited`), so one member cannot fill another's shares.
+- **What the relay learns.** The plaintext ops (participants, roles, settings, epochs, policies), the kind of each
+  sealed op (`meta`, or a `setting`'s kind), sizes and timing. Never a message body, a name, a topic, a setting's
+  content or a key.
+
 **What the relay can see.** Team ids, machine ids, persons, session names, timing, and presence:
 its session names, agent kinds, states and tiers, and the repo, branch and doing text a machine
 chooses to share (§6.5, none by default). It never sees message, task or receipt bodies.
@@ -1355,6 +1487,63 @@ chooses to share (§6.5, none by default). It never sees message, task or receip
 
 ### 8.2 IPC API
 
+**Conversation render schemas.** Core exports `ParticipantView`, `NoticeView`, `FileView`, `TaskView`, `EventView`, `ConvView`, `ActivityBody` and `ConvStreamEvent` (§16).
+Names and content are untrusted peer data. A `FileView` exposes no attachment key or nonce.
+A deleted `EventView` contains neither text nor files. Lane 4 omits read positions, preferences and unread counts.
+Stream records carry a daemon-local `pos`. An `event.update` names the conversation and event of its embedded projection.
+Stream record types are `event`, `event.update`, `conv`, `member`, `read`, `typing`, `activity`, `gap` and `task` (person-level readers only, "The person's tasks").
+An `event.update` change is one of `edit`, `delete`, `react`, `pin`, `replies`, `delivery` and `task`; lane 4 emits `edit`, `delete`, `react`, `pin` and `delivery`.
+A `request.waiting` item's state is one of `held`, `pending-delivery`, `resend` and `outdated`.
+The daemon re-reads verified state before it sends a projection.
+
+**Action tokens.** A human-tier client acts on an item it shows through an action the daemon put on that item:
+`{name, token}`, where `token` is an `ActionToken` (32 random bytes, base64url, 43 characters).
+- **Minting.** The daemon mints a token when it renders an item on `run/admin.sock` for a call that carries no session
+  key. Under a Jelly host (§8.11) that call is under a method grant: a host-scope grant renders no token. The agent tier
+  never receives one.
+- **Binding.** A token is for one action `name`, one target and one view. The target is the request (`request.list`)
+  or the task (`TaskView`). The view is the admin connection that received the token, and under a Jelly host also the
+  `dev` and `mbr` of the method grant. A missing `dev` or `mbr` is bound as missing.
+- **Life.** A token is spent by its first presentation, whether or not it matches. It lives 10 minutes. The daemon holds
+  tokens in memory only, so a restart invalidates every one; the store does not change. A connection's tokens end
+  when it closes.
+- **Limits.** A view that reads the same item again gets the same token while more than half of the token's life is
+  left. A view holds at most 256 tokens and the daemon at most 4,096. Past either limit the oldest token ends.
+- **Redemption.** Only through the action's own method, with the token as the `token` param: a request's answer
+  through `request.answer {id, answer, token}`, where `answer` is the action's `name`; a task's `cancel` through
+  `task.cancel {taskId, token}`. The params name the target. Only `run/admin.sock` takes a token, for a call with no
+  session key: elsewhere the call is `forbidden`, and that refusal does not spend the token. A token that is forged,
+  spent, expired or ended, for another name or target, or from another view or an earlier start, is `grant_invalid`,
+  and the call does nothing.
+- **Logging.** The daemon logs each refusal as `action.token.refused` with the method and a fixed reason. It never logs
+  a token.
+- **Where tokens are offered.** `request.list` gives each request `actions`, one per answer its kind takes, while the
+  request can be answered: an ask `once`, `always`, `decline` and `block`; a pending message request `accept`,
+  `decline` and `block`; a suggestion `decline`; an agent invitation `accept` and `decline`. `TaskView.cancel` is
+  offered only on a task that this person's agent asked (the requester side) and that has not ended. The executor side
+  never gets `cancel`. No retry method exists for a failed send (the outbox retries by itself), so a failed send has
+  no recovery action.
+- **Vectors.** `docs/spec/vectors/action-tokens.json` has requests with actions and the params that redeem them, with
+  negative cases. `conversation-views.json` has a `TaskView` with `cancel`.
+
+**Staged conversation methods.** These contracts have no live handler: `conv.catalogue`, `conv.publish`, `conv.markRead`, `conv.markUnread`, `conv.prefs`, `conv.follow`, `conv.save`, `conv.saved`, `conv.draft`, `conv.schedule`, `conv.scheduled`, `conv.unschedule`, `conv.typing`, `context.get`, `context.set`, `context.set.preview`, `conv.localRetention`, `file.get`, `session.activity`, `turn.cancel`.
+
+**Live conversation methods.** `LIVE_CONVERSATION_METHODS` is part of `IPC_METHODS`. The tier table applies on both sockets.
+Batch `people.get` accepts up to 100 distinct person IDs and returns `{people, missing}` without device lists.
+`people.get` and `sessions.list` work without a connected conversation engine.
+Human-only `request.waiting` reports authenticated outgoing holds separately from pending delivery. `request.list` reports incoming requests.
+A `conv.send` names exactly one of `cid` and `to`. `broadcast` requires a thread.
+A page chooses at most one position. Agent calls require a session registered on their connection.
+The daemon enforces access, audience consent and own-line restrictions after asynchronous work too.
+Creation requires two DM participants or 3–50 group participants. Only channels have visibility. Only agents can be seated.
+`conv.access` pages accessible conversations. `conv.sync` waits at most 25 seconds and returns at most 50 events.
+A person-level `conv.sync` (admin socket, no key) also carries `task` entries for the person's tasks (§8.2, "The person's tasks").
+A restart or expired replay position produces a gap. Clients then reload their accessible conversations.
+Task changes share the replay buffer (its last 10,000 changes) with conversation changes, so a burst of task
+updates moves the oldest replayable position forward for every reader, keyed or not; a reader past it gets `gap`.
+`conv.backfill` returns `complete: false` until indexing coverage accounts for missing keys and expired entries.
+The method schemas and their error arrays are normative. Malformed JSON-RPC and params use JSON-RPC errors.
+
 The API is the method table `IPC_METHODS` in `schema/ipc.ts`: JSON-RPC 2.0 NDJSON on two Unix
 sockets in `$MESSAGING_HOME/run/`. For a method this section does not describe (for example
 `contacts.list`, `item.read` and `task.get`), the TSDoc in that file and in `schema/ipc/*.ts` is normative.
@@ -1367,8 +1556,8 @@ sockets in `$MESSAGING_HOME/run/`. For a method this section does not describe (
 - **Two sockets.** The daemon serves the one API on two sockets, and itself enforces what each
   serves (its tiers). A client's own method list is a second check, not the boundary.
   - `run/agent.sock` (the agent tier) serves only `AGENT_METHODS`. Any other method fails with
-    `forbidden` before its params are read. A line as the person (`person.send`, no session) is not
-    one of them (§6.8). Agent-facing clients connect here: the OpenCode plugin's server part
+    `forbidden` before its params are read. Conversation calls on this socket require a bound session.
+    They cannot send as the person. Agent-facing clients connect here: the OpenCode plugin's server part
     and `messaging-mcp`.
   - `run/admin.sock` (the admin tier) serves every method. Human clients connect here: the `messaging`
     CLI and the `/messaging` TUI.
@@ -1422,7 +1611,7 @@ sockets in `$MESSAGING_HOME/run/`. For a method this section does not describe (
   - **What the tiers are, and what they are not.** Where the daemon, OpenCode and the user's shell
     run as one OS user, as on a laptop, the tiers are not a security boundary: any process of that
     user can open `run/admin.sock`. They keep `team.*`, `identity.rotateEnc`, `daemon.stop`,
-    `channel.*`, `conv.subscribe`, `conv.markRead` and the person's own chat lines off every tool path. A tool that
+    conversation administration and the person's own chat lines off every tool path. A tool that
     speaks to the agent socket cannot reach them. A shell that runs the `messaging` CLI is still a shell,
     and only the host's shell permissions govern it. The tiers are a boundary only when `messagingd`
     runs as its own user and the engine runs as another user in `ipc.agentGroup` (the layout is in
@@ -1431,23 +1620,25 @@ sockets in `$MESSAGING_HOME/run/`. For a method this section does not describe (
     as them and call every method, including `team.*` and `daemon.stop`. Agent-facing clients still
     must not expose `team.*`. The OpenCode TUI is a human surface and may call them. It must not
     place an invite ticket in a session, a log, or a model context.
-  - Key-scoped methods (`session.update`, `session.unregister`, `events.subscribe`, `msg.send`,
-    `inbox.*`, `item.read`, `task.*`, `conv.read` with a key) work only for a key that the calling connection registered (`not_found`
-    otherwise).
+  - Key-scoped methods (`session.update`, `session.unregister`, `events.subscribe`, `inbox.*`, `item.read`, `task.*` (but `tasks.list` and `tasks.get`),
+    `conv.list`, `conv.read`, `conv.send`, `conv.react`, `conv.edit`, `conv.delete`, `conv.search`, `conv.context`, `conv.access`, `conv.sync`)
+    work only for a key that the calling connection registered. Human conversation calls can omit the key on the admin socket.
   - A session key is therefore a bearer credential for its session: whoever knows it can register it
     and act as that session.
   - `AGENT_METHODS` (with its type `AgentMethod`) lists the methods an agent-facing client may call,
     and exactly the methods `run/agent.sock` serves. Anything else is for human clients: the
     `messaging` CLI and the `/messaging` TUI.
-  - **Tiers.** Every method is in one tier list in `schema/ipc.ts`, and `conv.read` in two:
+  - **Tiers.** Conversation methods available to agents also appear in the human list:
     `AGENT_METHODS` (the agent tier: sessions, `device.status`, `device.bind`, `contacts.list`,
-    `msg.send`, `inbox.list`, `inbox.get`, `inbox.ack`, `item.read`, `conv.read`, `search`, `task.*`,
+    `inbox.list`, `inbox.get`, `inbox.ack`, `item.read`, `conv.list`, `conv.read`, `conv.send`, `conv.react`, `conv.edit`, `conv.delete`, `conv.search`, `conv.context`, `conv.access`, `conv.sync`, `task.create`, `task.continue`, `task.list`, `task.get`, `task.update`, `task.cancel`, `task.question`,
     `events.subscribe`, `daemon.status`, `daemon.health`); `HUMAN_METHODS` (acting as the person: `conv.list`,
-    `conv.read`, `conv.markRead`, `conv.subscribe`, `person.send`, `people.search`, `people.get`,
-    `grant.list`, `grant.set`, `grant.set.preview`, `request.list`, `request.answer`, `request.answer.preview`, `contact.request`,
-    `contact.request.preview`, `card.get`, `agents.list`,
-    `agents.read`, `notice.subscribe`, `notice.list`, `notice.ack`, `device.approve.preview`,
-    `device.remove.preview`, `identity.replace.preview`, `directory.erase.preview`, `channel.*`); and `ADMIN_METHODS`
+    `conv.read`, `conv.send`, `conv.react`, `conv.edit`, `conv.delete`, `conv.search`, `conv.context`, `conv.access`, `conv.sync`,
+    `conv.get`, `conv.members`, `conv.threads`, `conv.pin`, `conv.create`, `conv.add`, `conv.remove`, `conv.role`, `conv.seat`,
+    `conv.settings`, `conv.meta`, `conv.archive`, `conv.leave`, `conv.join`, `conv.accept`, `conv.policy`, `conv.backfill`, `people.search`, `people.get`,
+    `grant.list`, `grant.set`, `grant.set.preview`, `reach.get`, `reach.set`, `reach.set.preview`, `request.list`, `request.answer`, `request.answer.preview`, `contact.request`,
+    `contact.request.preview`, `card.get`, `sessions.list`, `request.waiting`,
+    `notice.subscribe`, `notice.list`, `notice.ack`, `tasks.list`, `tasks.get`, `device.approve.preview`,
+    `device.remove.preview`, `identity.replace.preview`, `directory.erase.preview`); and `ADMIN_METHODS`
     (this device and the daemon: `daemon.stop`,
     `daemon.woke`, `person.attached`, `daemon.snapshot`, `wake.arm`, `wake.disarm`,
     `device.list`, `device.remove`, `device.link`, `device.login`, `device.login.status`, `device.login.cancel`,
@@ -1482,6 +1673,12 @@ sockets in `$MESSAGING_HOME/run/`. For a method this section does not describe (
     Only a directory realm has it (`invalid_state` in a roster realm).
   - `device.list` (admin tier) lists this device's person's devices, current first, with vouch, kind,
     and for a removed one when, why and by which device it was unbound.
+    - Each entry carries `features`: the presence features (§6.5) that device advertises. This device lists its own.
+      Another device of the person lists those of the last presence this device verified from it.
+    - `features` is absent when no presence of that device has been seen. That means unknown, not none.
+    - A client warns while any current device of the person lacks a feature it relies on. The plugin does this for
+      `reach`, the reach choices of §6.9: a device without it does not enforce them.
+    - Only the person's own devices are listed. No method shows another person's devices or their features.
   - `device.remove {device, reason?, token?}` (admin tier) unbinds this device (`self`), or another
     current device of its person (`removed` by default, or `lost`) with a fresh Jelly token bound to this
     device (`invalid_request` without one). A directory realm only; a roster realm uses `team.remove`.
@@ -1562,12 +1759,8 @@ sockets in `$MESSAGING_HOME/run/`. For a method this section does not describe (
   `PeerRef` (inbox items, task records), provenance (§6.6), directory entries (whose client kind is
   `client`) and chat lines. `daemon.status` names this device in `identity` (its `device`), and a divergence alarm
   the signer's `device`. Team administration (`team.*`) keeps the roster's `machine`.
-- **Persons in the API.** Wherever the API names a person (addresses, `PeerRef`, provenance,
-  directory entries, chat lines and their `refused`, `conv` events, `daemon.status`'s identity,
-  `contacts.list`, `people.*`, a `dm:` or `agent:` conversation, and a line's `to` in `msg.send`), it
-  takes a `PersonId`: a roster person name or a hosted `p_…` id. Channel membership (`channel.*`, and the
-  `persons` and `creator` of a channel op, §6.8) takes `PersonId`s too. Team administration (`team.*`) takes
-  roster person names.
+- **Persons in the API.** Person references use `PersonId`: a roster person name or a hosted `p_…` ID.
+  Conversation participants use person IDs or stable `person/agent` addresses. Team administration uses roster person names.
 - **`session.register`.** Names a session.
   - The requested name is suffixed `-2`, `-3`, ... if it is taken on this machine.
   - Registering an existing key again updates it; this is idempotent.
@@ -1608,24 +1801,14 @@ sockets in `$MESSAGING_HOME/run/`. For a method this section does not describe (
   expired `trustedUntil` is left out. So an agent sees whom it can reach without a human-tier call. A `reach` also
   carries `devicesChangedAt` while a device of that person was added, removed or replaced less than 7 days ago, as
   their verified log (or the roster) shows it; a rekey or an attest is not a change, and it carries no other text. Entries
-  carry `expect`: the hint a `msg.send` to that session now, with the wake hint set, would return
+  carry `expect`: the hint a `task.create` to that session, with the wake hint set, returns
   (below), computed from the same view. Agent clients show it before anything is sent. It is absent
   when no presence lists the session.
-- **`msg.send`.** One send from the session `key`. Its `to` decides what it is:
-  - **To `<person>` or `#<channel>`: a line** in the person's DM with them, or a post in a channel
-    this person is in, attributed to the session (§6.8). It takes `kind: "message"`, one text part of
-    at most `LIMITS.chatChars`, and `replyTo` as the thread (the `id` of any line of it); any other
-    A2A field (`contextId`, `taskId`, `messageId`, `metadata`, `extensions`, `referenceTaskIds`,
-    `onBehalfOf`, `wake`) is `invalid_request`, and so is a `to` that is neither a person
-    name nor `#` and a channel name. It fails with `not_found` for a person not on the team, a
-    channel this person is not in, or an unknown thread, and `too_large` for a longer line. It writes
-    the line as `person.send` does (below), and `idempotencyKey` is the line's `clientId`. Its one
-    result is `{to, envelopeId: <line id>, messageId, contextId, stage: "accepted"}`. With `request:
-    {contact: <email>}`, only on a line to the session's own person (otherwise `invalid_request`), the daemon
-    also files a suggestion for the person (§6.9, "Message requests").
-  - **To `person/session[@label]`: mail or a task** to that session, as the rest of this item says.
+- **`task.create` and `task.continue`.** These methods retain task envelopes until lane 7.
+  The destination is `person/session[@label]`. Creation assigns a task ID and signs a delegation chain.
+  Continuation requires the existing task ID and its bound executor. Both require the calling session's `key`.
   - Refuses content that holds a credential (`secret_refused`, §8.7), as do `task.update`,
-    `task.cancel` and `person.send`.
+    `task.cancel`, `conv.send` and `conv.edit`.
   - Resolves the address against the directory, including offline sessions.
   - Builds one envelope per recipient and stores it in the outbox (`accepted`).
   - Sends it when the relay is connected.
@@ -1651,14 +1834,12 @@ sockets in `$MESSAGING_HOME/run/`. For a method this section does not describe (
     `idempotencyKey` returns the hint computed for the original call.
   - `idempotencyKey` returns the original results for a repeated call from the same key.
   - `wake` defaults to true.
-  - The daemon assigns ULID task ids for `kind: "task"`, and the `contextId` when it is omitted.
-  - A `kind: "task"` send signs a root grant for each recipient (§6.7).
+  - Creation assigns ULID task IDs and a `contextId` when omitted, and signs a root grant for each recipient (§6.7).
   - A chain this daemon already knows the recipient would refuse is not sent. The result is
     `stage: "rejected"` with that check's code, and the requester's task is stored
     `TASK_STATE_REJECTED` with no grants.
   - **`onBehalfOf {taskId, scope?, maxDepth?}`** delegates on behalf of a task that the calling key
-    **executes**, and only with `kind: "task"`. Otherwise it fails with `not_found` (any other task)
-    or `invalid_request` (`kind` is not `"task"`), before anything is stored. The daemon:
+    **executes**, and only with creation. Any other task fails with `not_found` before storage. The daemon:
     1. refuses a terminal task (`invalid_state`) before anything is stored;
     2. signs the next grant of the stored chain for each recipient, narrowed to `scope` and
        `maxDepth` when given;
@@ -1678,104 +1859,132 @@ sockets in `$MESSAGING_HOME/run/`. For a method this section does not describe (
   `invalid_state`.
   - The daemon validates the transition and stores it.
   - It then emits `task.status` and/or `task.artifact`.
-- **`task.cancel`** is allowed only for the requester.
+- **`task.cancel`** is allowed only for the requester: the requester session (`{key, taskId, reason?}`), or, on the
+  human tier, the person with the task's `cancel` action (`{taskId, token, reason?}`, "Action tokens"). It takes
+  exactly one of `key` and `token`. A cancel by token returns the record with the owner view, as the admin socket's
+  task reads do.
+- **The task view.** Every `TaskRecord` the daemon projects (`task.get`, `task.list`, `task.update`, `task.cancel` and
+  `task` events) carries fields it computes as it projects the record. They are never stored and never sent to the
+  peer:
+  - `agent`: the counterpart agent, the session its verified envelopes name (`peer.agent`).
+  - `person: {id, name}`: that agent's person, `peer.person`, with the display name the realm verified for them (the
+    person id when the realm does not know them). It is never parsed from an agent's name.
+  - `org`: `same`, `other` or `none`, that person's relation to this device's person, as `ParticipantView.org` computes
+    it. (Jelly calls it `organisation`; the plugin maps the name.)
+  - `person` and `org` are absent while the daemon cannot name the person yet: a `task` event is projected at once from
+    what it last learned, and a read looks the person up first.
+  - `signIn: {tool?, by}`, in `TASK_STATE_AUTH_REQUIRED` only. `by` is `you` when the executor is an agent of this
+    device's person (this device runs the task, or the peer is another device of the same person), else `them`. The
+    viewer's own daemon computes it; it is never read from the peer. `tool` is what the executor named (§6.2,
+    "Sign-in"): plain text through `cleanPeerText`, single line, at most `TASK_SIGN_IN_TOOL_CHARS`
+    (`LIMITS.previewChars`, 200) characters; absent when it named none.
+  - `refusal: {reason}`, in `TASK_STATE_REJECTED` only, when the executor gave words: the text of its status message,
+    through `cleanPeerText`, at most `TASK_REFUSAL_CHARS` (`LIMITS.requestChars`, 500) characters.
+  - The tool and the reason are only ever the executor's own words: on the executor's side, its session's
+    `task.update`; on the requester's, a status message received from the executor (it carries the provenance the
+    daemon wrote, §6.6). A status the requester's daemon made itself, such as "delivery rejected: refused", gives
+    neither.
+  - Both are untrusted peer text, as `InboxItem.preview` is: a UI shows them as plain text, never markup, and a model
+    sees them only fenced (§11). So is the `name` in `person`: the realm verifies who the person is, but the name is their own
+    choice, and a UI shows it as plain text.
+  - `question: {sessionId, approvalId}`: the executor host's own pending approval or question that an
+    `AUTH_REQUIRED` or `INPUT_REQUIRED` task waits on. Both ids are the host engine's, opaque plain identifiers
+    (`[A-Za-z0-9][A-Za-z0-9._:-]{0,199}`).
+    - **Who sets it.** The session that runs the task: its client's runtime calls agent-tier
+      `task.question {key, taskId, question}` from its host's own permission and question events (`question: null`
+      unties it). It is never a model tool.
+    - **What is checked.** `key` must be registered on the calling connection (`not_found`). The task must be one that
+      session executes: another session's task, or an unknown one, is `not_found`, and the requester side is
+      `invalid_state`. The task must be in one of those two states (`invalid_state`). When the session's registration
+      named its host session (`session.register {host: {sessionID}}`), `sessionId` must equal it (`forbidden`).
+    - **The limit of that check.** A registration without `host` (under a Jelly host, one key serves all of an
+      agent's sessions) gives the daemon no host session to compare. Then `sessionId` is the runtime's word, scoped
+      to that agent's own task.
+    - **No human-tier form.** Only the executing session knows which approval its task waits on. An admin-socket
+      client could name any approval of any task, with nothing to check it against.
+    - The daemon keeps it **in memory only**: the approval it names does not survive a restart, so neither does the
+      association. Any later status of the task (a `task.update`, a cancel from the requester, the 24 h timeout)
+      unties it.
+    - Setting it from the agent tier does not make it visible there. It is shown only on the admin socket (the
+      person's own clients): in `tasks.list`, `tasks.get` and `conv.sync`'s `task` entries, and in `task.get`,
+      `task.list`, `task.update` and `task.cancel` results there, for the executor's side of a task still in one of
+      those states. It is never on the
+      agent socket, never in a `task` event (events go to both sockets), and never in anything sent to the peer.
+    - Nothing in it travels: the peer's daemon cannot learn the host's session or approval ids.
+- **The person's tasks.** `tasks.list {role?, state?, session?, cursor?, limit?}` and `tasks.get {taskId, role?}` are
+  human tier (admin socket only, no session key). They read the tasks this person's agents on this device are in,
+  as requester or executor, across all their sessions. They return `PersonTask`: the task view above, as the owner
+  sees it, `question` included.
+  - In place of the session `key` (a bearer credential), a `PersonTask` names the agent in `session`. The schema
+    refuses a `key`.
+  - On the requester side of a task that has not ended, it carries `cancel`, minted for this view as `request.list`'s
+    actions are ("Action tokens"). The executor side never has one.
+  - A device holds only its own sessions' sides, so another person's tasks are never listed, nor the person's other
+    devices' tasks.
+  - `tasks.list` is most recently updated first, 50 by default and at most 100 per page. A page also stops at the list
+    byte budget. It reports `total` and pages with an opaque `cursor`/`nextCursor`. `session` filters to one agent by
+    name; an unknown name lists nothing. `tasks.get` needs `role` only when this device holds both sides (one of its
+    agents asked another); without it, `invalid_request`. An unknown task is `not_found`.
+  - **Live.** A change of such a task (any `task` event, and `task.question`) adds a `task` entry to `conv.sync`'s
+    stream (§12.4): `{type: "task", pos, task: PersonTask}`, rendered for each reader when it reads, so `cancel` is
+    minted for that reader's view. Only a person-level reader gets these entries: the admin socket with no session
+    key. The agent tier, and any `conv.sync` with a `key`, skip them. The stream is chosen over a new push kind so a
+    host's request-and-response section stays live with the long poll it already makes (design §12.1). When one read
+    covers several changes of the same side, it renders that side once, as it is now.
+  - Action class `view` under a Jelly host (§8.11).
 - **`task` events** carry `origin`:
   - `local` when the event follows the subscriber key's own call: `task.update`, `task.cancel`,
-    or the `msg.send {kind: "task"}` that created the record;
+    or the `task.create` call that created the record;
   - `peer` when it follows an envelope from the other side, a receipt, or a daemon timeout.
   - When the event follows a status or artifact update, `update` carries that delta, including
     `append` and `lastChunk`.
-- **`conv.read {key?, conversation, thread?, before?, after?, limit?}`** returns one page of a
-  conversation, oldest first, as `{kind, …, more}`. `conversation` is `dm:<person>` or
-  `channel:<name>` (`kind: "lines"`, below under Chats), or `agent:<person>/<agent>` (`kind:
-  "agent"`), which needs the session `key`: what the session `key` exchanged with one other session,
-  on any machine of that person: incoming mail,
-  outgoing mail and tasks either way, as `ConvEntry` rows in time order. A task request appears
-  once, as its task (dated when it was created, with its current state), not again as mail. A
-  cursor is an entry's `{at, id}` with an agent, and a line's `seq` in a DM or a channel; the other
-  form is `invalid_request`, and so is `thread` with an agent. With no cursor it is the latest `limit` entries (default 30, at
-  most 100); with `before` the latest `limit` before that place; with `after` the earliest `limit`
-  after it. Entries come oldest first, and `more` says entries remain past the page in the
-  direction read; `before` and `after` together are invalid params. Incoming mail carries its
-  preview and stage, a task the start of its request, the session's role and the task's state.
-  Outgoing mail carries its stage but no text: the daemon keeps no copy of what it sent. It changes
-  no stage and sends no receipt. Agent clients build their conversation view on it (§11).
+- **`conv.read {key?, cid, thread?, before?, after?, around?, limit?, cursor?}`** returns current event projections, oldest first, or an explicit context hold.
+  Pages contain at most 50 events. Before and after positions are log sequence numbers. An opaque cursor binds to the query and session.
+  Reads expose no legacy mail or fabricated task events. Retained tasks use their own methods.
 - **`task.list`:** most recently updated first. It filters by `role`, `state`, `contextId`,
   `peer` (a qualified address) and `updatedAfter` (at or after, ≥), pages with an opaque `cursor`/`nextCursor`, and reports `total`.
-- **`msg.send` A2A passthrough** (mail and tasks): `messageId` (generated if omitted), `metadata` (at most
+- **Task A2A passthrough:** `messageId` (generated if omitted), `metadata` (at most
   16,384 bytes of UTF-8 JSON, which for wire JSON is its JCS length; the daemon always overwrites `metadata[urn:messaging:ext:provenance:v1]` on the receiving
   side), `extensions`, and `referenceTaskIds`.
-- **Chats (§6.8).** `conv.read` (of a DM or a channel) and `search` need no session key. They are
-  the only chat methods in `AGENT_METHODS`; an agent's own line goes through `msg.send`.
-  - `conv.list` (human tier) returns at most `limit` conversations (default 100, at most 200), newest
-    first. A channel held under a local name carries its own `name`. Each carries its read state
-    (§6.8): `readUpTo`, `unread`, and `lastSeq`, the newest line's `seq` (absent in a channel with no
-    lines).
-  - `conv.read` of a DM or a channel returns a page of its lines (or of one thread), oldest first, and `more`. With
-    no cursor it is the latest `limit` lines (default 50, at most 100); with `before: seq` the latest
-    `limit` lines below that `seq`, to page back; with `after: seq` the earliest `limit` lines above
-    it, to catch up. `more` says that lines remain past the page in the direction read. `before` and
-    `after` together are invalid params.
-  - `conv.markRead {conversation, upTo}` moves the conversation's read cursor to `upTo`, a line's `seq`, if that is
-    later, clamped to the newest `seq` here. It returns `{readUpTo, unread}`. It is a human-client
-    method that is not in `AGENT_METHODS`: read state is the person's, and an agent reading a
-    conversation does not mark it read. It fails with `not_found` for a channel this person is not in.
-  - A `ChatLine` this machine sent to other persons carries `state` (`sent`, `delivered` or
-    `refused`) and, when refused, `refused` (the persons). A line the daemon wrote itself, about a
-    channel change or a refusal of one, carries `notice: true`.
-  - `person.send {conversation, text, thread?, clientId?}` (human tier) writes the person's own line
-    and its envelopes in one transaction and sends them at once, with no session. It fails with
-    `not_found` for a person not on the team or a channel this person is not in. A DM to oneself
-    is the person's own conversation (§6.8).
-  - `search {query, conversation?, limit?}` finds lines in the DMs and channels this person holds,
-    newest first, as `hits`, each with its `conversation`.
-  - **Pacing.** The sender keeps its chat envelopes to one recipient machine below that machine's
-    chat budget (§8.3): the reference daemon allows 50 a minute, ten below
-    `LIMITS.inboundPerMachinePerMinute`, for clock and transit jitter. Channel changes count too. A
-    line (`person.send`, or `msg.send` to a person or a channel) that would go over it for any machine
-    it goes to fails with `rate_limited`, a
-    message that says when to try again, and nothing stored or sent. Pacing cannot cover a backlog:
-    lines queued at the relay for an offline machine reach it together when it connects. The
-    receiver defers those past its budget and the relay paces them (§7 "Delivery", §8.3), so every
-    line is delivered within minutes; only one that would expire first is refused.
-  - A line with a `clientId` (`msg.send`'s `idempotencyKey`) is idempotent per `clientId` and
-    sender: the session `key`, or the person for `person.send`. A repeat with the same room, thread and text returns the first call's
-    result and files and sends nothing. The same `clientId` for another line is `invalid_request`.
-    The daemon keeps a `clientId` for `LIMITS.ttlMs`.
-  - `channel.create`, `channel.invite`, `channel.leave` and `channel.remove` are for the human
-    `/messaging` TUI. They take a channel name as this machine holds it (its local name). Each checks
-    before it stores anything. `channel.create` refuses a name already held, more than the
-    channels a machine holds (`invalid_request`), an unknown person, or more than
-    `LIMITS.channelPersons` persons with the creator. `channel.remove` refuses a caller who is not
-    a member (`not_found`), who is neither the creator nor a team admin (`forbidden`), a list that
-    names the caller (`invalid_request`: use `channel.leave`), and a person who is not a member
-    (`not_found`).
-  - Mail and tasks (`msg.send` to an agent) never write the transcript.
-  - **`conv` events** go only to connections that called `conv.subscribe`, a human-client method
-    that is not in `AGENT_METHODS`. They are never sent to `events.subscribe` keys. A `conv` event
-    names the conversation, the line's `id` and its person, never its text. It is raised for a filed line,
-    a channel change, and a change of an outgoing line's delivery state (then `person` is this
-    machine's person). Each carries the `seq` of its change (§6.8), so events rise in `seq`.
-  - **Resuming.** `conv.subscribe {since}`, where `since` is the `seq` of the last event the client
-    handled, first sends one `conv` event per line that changed after `since`, oldest change first,
-    each with the `seq` of the line's latest change. Then live events follow, with none between.
-    It returns `{seq, gap}`: the newest `seq` at the call, and whether the replay could not be
-    complete, in which case it sends none. That is when more than a policy number of lines changed
-    (the reference daemon: 500), a channel was deleted here after `since`, or `since` is above
-    `seq` (a store set up again). After a gap the client reloads with `conv.list` and `conv.read`.
-    Without `since`, `gap` is false and no events are replayed.
+- **Conversations (§6.8).** The agent-accessible methods are `conv.list`, `conv.read`, `conv.send`, `conv.react`, `conv.edit`, `conv.delete`, `conv.search`, `conv.context`, `conv.access` and `conv.sync`.
+  Every agent call uses its bound session. Human calls use the admin socket.
+  A `conv.send` returns `{cid, id, clientId, stage: "pending"}` or an explicit audience hold.
+  The durable outbox retries identical signed events. A repeated `clientId` returns the first event ID.
+  A queued key share whose recipient device the conversation's own verified log removes (an accepted `remove` of its
+  person or the person's own `leave`, with the person no longer a participant, or a `rekey {cause: device}` naming
+  the device) is dropped, never sent, and logged by conversation, device and event id. Any other share to a device
+  that is no longer current, such as a directory miss, holds the outbox until the state is verified.
+  Reuse with different content or a different destination fails with `invalid_request`.
+  Conversation administration uses the human-tier methods in the tier list. Internal notifications carry identifiers only.
+  The stream re-renders current verified state, including edits and deletions, for each reader.
 - **Consent (§6.9).** `grant.list`, `grant.set`, `grant.set.preview`, `request.list`,
   `request.answer`, `request.answer.preview`, `contact.request`, `contact.request.preview` and `card.get` are human-client methods that are
   not in `AGENT_METHODS`: agents never read or change a person's grants, answer a held request, or send a message
-  request.
+  request. So are `reach.get`, `reach.set` and `reach.set.preview`: agents never read or change the person's reach
+  choices.
+  - `reach.get {}` (read-only) returns `{revision, available, groups}`: `available` is true; `groups` are the two
+    questions of "Reach choices" (§6.9), in order, each `{id, label, options, value, lapsed?}`. `id` is `message`
+    ("Who can message you") or `ask` ("How agents may ask yours"); `options` are `{value, label, description}` for
+    `open` (Open), `ask` (Ask me first) and `never` (Never), in that order, in fixed words (`REACH_QUESTIONS`);
+    `value` is the person's choice, from the relation grant this device holds whose signer is current, or null for
+    none (the defaults apply); `lapsed` is a choice that lapsed with a removed signer and waits on the review list.
+    `revision` is opaque, and changes whenever a relation grant or its review entry changes on this device, also by
+    sync from another device or a re-sign.
+  - `reach.set {revision, changes}` takes the `revision` the caller read and `changes`, an object of at most the two
+    group ids, each one of the three values: anything else is invalid params. When `revision` is not the current
+    one it fails with `conflict` and changes nothing. Otherwise it signs, for each change, the relation grant of
+    "Reach choices" with this device, stores it, takes the subject off the review list and sends it to this person's
+    other devices, all in one transaction, and returns the new snapshot (`reach.get`'s result). An empty `changes`
+    changes nothing. Under a Jelly host it is a `local` action (§8.11).
+  - `reach.set.preview` takes the same params, checks them the same way (`conflict` too), changes nothing, and
+    returns one fixed `sentence` saying what the changes would do, for a confirmation.
   - `grant.list {subject?}` returns this person's grants as this device holds them, newest first,
     each with its levels, `id`, `ts`, `by` and, when re-signed, `resignedAt`, and the review list:
-    the widening levels that lapsed with their signer, with when they lapsed. A channel subject
-    carries the channel id and, while this person is in it, its local name.
+    the widening levels that lapsed with their signer, with when they lapsed. A conversation subject carries its canonical `cid`.
   - `grant.set {subject, chat?, agentMail?, ask?, trustedUntil?, trust?, discoverable?}` signs the
     whole new grant for the subject with this device: a level left out is the relation's default,
-    and no level at all is a clear. `subject` is `{person}` or `{channel}`, a channel by its local
-    name. `trust: true` without `trustedUntil` trusts for `LIMITS.trustDefaultMs`. It stores the
+    and no level at all is a clear. `subject` is `{person}` or `{conv: cid}`.
+    `trust: true` without `trustedUntil` trusts for `LIMITS.trustDefaultMs`. It stores the
     grant, takes the subject off the review list and sends the grant to this person's other devices
     in one transaction. It fails with `not_found` for a person the realm does not know or a channel
     this person is not in, `invalid_request` for a grant that breaks a rule of §6.9, and
@@ -1787,12 +1996,15 @@ sockets in `$MESSAGING_HOME/run/`. For a method this section does not describe (
     `agent`, `address`), the local session it is for, an untrusted `preview`, when it was held and when it
     expires; then the message requests (`contact`), each with its envelope `id`, the sender as the realm verified
     them (`person`, `device`, `label`, `name`, `email?`, `org`), its untrusted `text`, `at` and `exp`; then the
-    suggestions (`suggestion`), each with its `id`, the local `agent` that asked, the `email` and `at`.
+    suggestions (`suggestion`), each with its `id`, the local `agent` that asked, the `email` and `at`. Each item
+    also carries `actions` ("Action tokens").
   - `request.answer {id, answer, all?}` answers one and returns the ids answered: an ask takes `once`, `always`,
     `decline` or `block` ("Holds"), a message request `accept`, `decline` or `block` ("Message requests"), a
     suggestion `decline`; any other answer is `invalid_request`. With `all`, the same answer goes to every request
     of the same kind held from that person. It fails with `not_found` for an id this device does not hold, or one
-    past its expiry.
+    past its expiry. `token` is the request's action for this `answer`. It is checked before anything else, it never
+    comes with `all`, and under a Jelly host it is required (`grant_required` without it). So under a Jelly host
+    `all` is never used: each request is answered with its own token.
   - `request.answer.preview {id, answer, all?}` (`request.answer`'s input) changes nothing and returns, for the
     answer's confirmation, whom it reaches and what it does: `{kind, from: {name, email?, org}, agent?, to?, count,
     sentence}`. `from` is the realm's verified profile of the sender (of the person themself for their
@@ -1800,7 +2012,8 @@ sockets in `$MESSAGING_HOME/run/`. For a method this section does not describe (
     for, `count` how many requests the answer would settle (more than 1 only with `all`), and `sentence` one fixed
     sentence saying what `answer` does. A name or email in the sentence is
     cleaned to one line of at most 80 (100) characters. It refuses as `request.answer` would: `not_found` for an id
-    this device does not hold or one past its expiry, `invalid_request` for an answer the kind does not take.
+    this device does not hold or one past its expiry, `invalid_request` for an answer the kind does not take. It
+    checks a `token` as `request.answer` does, but does not spend it.
   - `contact.request {email, text, suggestion?}` (§6.9, "Message requests") resolves the exact `email` and sends
     `text` (1 to `LIMITS.requestChars` UTF-16 code units) as a message request, and returns `{id, conversation,
     person}`: the line's id, `dm:<person>` and the person found. It fails with `invalid_request` in a roster
@@ -1843,27 +2056,18 @@ sockets in `$MESSAGING_HOME/run/`. For a method this section does not describe (
   `daemon.snapshot {done: true}` deletes it and returns `{released}` (false when none was held). One is held at a time
   (`invalid_state` while one is); the daemon releases it after an hour (`until`), when it stops, and one a previous run
   left when it starts.
-- **Your agents.** `agents.list` and `agents.read` (human tier, read-only) are the person's view of their
-  own agents' traffic on this device.
-  - `agents.list` returns each local session (registered or kept) as `{agent, conversations, unread,
-    lastAt?, state}`: how many other agents it has mail or tasks with, the mail it has not read, its last
-    traffic, and `idle`, `busy` or `kept`; most recent first.
-  - `agents.read {agent, conversation?, before?, limit?}` returns, without `conversation`, `{kind:
-    "conversations", conversations}`: each `agent:<person>/<agent>` it has traffic with, with its unread
-    mail and last time, most recent first. With `conversation`, it returns `{kind: "entries",
-    conversation, entries, more}`: a page of entries as `conv.read` gives them to that agent (default
-    30, latest first, `before` an entry's `{at, id}`). It changes no stage and sends no receipt.
-    `not_found` for an agent this device has no session of. Peer text is untrusted; a client cleans it
-    for display (`cleanPeerText`) and never shows it to a model.
+- **Your agents.** Human-tier `sessions.list` returns local sessions as `{agent, state, seats}`.
+  State is `idle`, `busy` or `kept`. Seats are verified conversation IDs. No unread count is fabricated.
 - **Notices.** What the person is told about, in three fixed categories, as `{id, category,
-  conversation?, from?: {name, email?, org}, line?, at}`:
-  - `message`: a line filed for the person in a DM or a channel from another person or their agent, or
-    from one of the person's own agents in their own conversation; never the person's own line, a line
-    about a channel change, or a change of a line's delivery state. Its `conversation` is the DM or the
-    channel, and `from` the sender's person as the realm verified them.
-  - `request`: a request held for the person (§6.9), with `conversation` the sender's
-    `agent:<person>/<agent>` (`dm:<person>` when the person sent it themself, as for a message request); or a
-    suggestion of one of the person's own agents, with `conversation` `agent:<own person>/<agent>`.
+  conversation?, from?: {name, email?, org}, line?, key?, at}`:
+  - `message`: a retained legacy notice, without transcript text. Live conversation updates use the conversation stream.
+  - `message` with `key: "task:<task id>"`: a task another person's agent asked of one of this person's agents. It is
+    filed when this device accepts the task (when the `TaskRecord` of the executor's side is created), with `from` the
+    requesting person. It copies no text of the task. It waits on the agent, not the person: it is never a `request`
+    and never in `counts.requests`. An ask held for consent (§6.9, "Holds") is filed as a `request` and stays one until
+    its person answers. If they let it through, the accepted task then files its `message` notice; if they decline,
+    there is none. A task between this person's own agents files no notice. A host opens the notice by its `key`.
+  - `request`: a held request or retained contact suggestion (§6.9). New notices contain no legacy room reference.
   - `alert`: an alarm of this device (`keys_missing`, `restored`, `directory`), with fixed text in `line`; a
     change of another device of the person (below), with `device`; or trust the person gave someone that ends
     within 7 days (§6.9), with `from` that person and `line` "Trust you gave this person ends on <date>; renew it
@@ -1887,19 +2091,18 @@ sockets in `$MESSAGING_HOME/run/`. For a method this section does not describe (
     admitted by the team's admin.", "'tablet' (other) on your account is now vouched by Jelly ID: ...", "'desk'
     was replaced by 'desk2' (jelly-host), ...", "'phone' (laptop) was removed from your account.".
   - Each notice is filed once, when its source is, under an id derived from the source (`m_<line id>`,
-    `r_<request id>`, `a_<alarm and time>`, `a_dev<log seq>`, `a_trust<grant id>`), so a replay repeats the same ids. A notice copies no text:
-    with `lines: true`, a message's `line` is the first line of its text read from the transcript,
-    through `cleanPeerText`, at most 120 characters with its "…".
+    `m_task<task id>`, `r_<request id>`, `a_<alarm and time>`, `a_dev<log seq>`, `a_trust<grant id>`), so a replay repeats the same ids. A notice copies no text:
+    `lines: true` can expose fixed alert text. It never restores legacy transcript content.
   - `notice.subscribe {after?, lines?}` sends the unacknowledged notices filed after the notice `after`
     (all of them without it, at most 500), oldest first, as `notice` events on this connection, then each
     new one as it is filed; it returns `{replayed}`. `notice.list {lines?, limit?}` returns the
-    unacknowledged notices, newest first (default 50), and `counts`: `unread`, the lines from others not
-    yet marked read over every conversation, and `requests`, the asks, message requests and suggestions held. `notice.ack {ids}` marks
+    unacknowledged notices, newest first (default 50), and `counts.requests`: the asks, message requests and suggestions held. `notice.ack {ids}` marks
     notices seen; unknown ids are ignored. It never answers, releases or uncounts a request: a request stays held, in
     `request.list` and `counts.requests`, until `request.answer` (or its expiry). Notices go with the transcript's retention, and acknowledged ones
     with the read mail's.
 - **Previews.** Each preview takes exactly its action's input, so a host that draws a confirmation calls it with
-  the input the action will get (Jelly does): `grant.set.preview` takes `grant.set`'s params, `request.answer.preview`
+  the input the action will get (Jelly does): `grant.set.preview` takes `grant.set`'s params, `reach.set.preview`
+  `reach.set`'s `{revision, changes}`, `request.answer.preview`
   `request.answer`'s `{id, answer, all?}`, `contact.request.preview` `contact.request`'s `{email, text?, suggestion?}`,
   `device.approve.preview` `device.approve`'s `{link, sas?}` and `device.remove.preview` `device.remove`'s `{device,
   reason?, token?}`. A field the preview does not read may be left out (`text`, `sas`, `suggestion`, `reason`,
@@ -1908,7 +2111,7 @@ sockets in `$MESSAGING_HOME/run/`. For a method this section does not describe (
   changes nothing. What each returns is unchanged: `device.remove.preview` (human tier, read-only, a directory realm
   only) returns what removing a device of this person would remove, `{label, kind?, vouch, current, self, since?}`,
   or `not_found`; `device.approve.preview` returns `{device, label, kind, sas}` ("Devices"); `grant.set.preview`,
-  `request.answer.preview` and `contact.request.preview` are under "Consent" above. Under a Jelly host a preview's
+  `reach.set.preview`, `request.answer.preview` and `contact.request.preview` are under "Consent" above. Under a Jelly host a preview's
   grant names its action's class, `local` (§8.11).
 - **Failed delivery of a task request:**
   - a `rejected` receipt or nack moves the requester's record to `TASK_STATE_REJECTED`;
@@ -1929,8 +2132,7 @@ delegation chain is verified after these (§6.7). A person refuses another perso
   - Receipts, `task.status` and `task.artifact` answer the recipient's own traffic, so they have a
     budget of their own: four times that.
   - Presence has a budget of its own, also four times that.
-  - Chat envelopes (a `message` to the machine with no session, §6.8) have a budget of their own,
-    `LIMITS.inboundPerMachinePerMinute`, apart from agent mail.
+  - Person-addressed controls (contact requests, cards and grants) have their own budget of `LIMITS.inboundPerMachinePerMinute`.
   - Over the limit, an envelope is **deferred**: the recipient withholds its `recv.ack` and does not
     mark it seen, so the relay sends it again later (§7 "Delivery") and it is taken when the budget
     has room. A backlog that arrives at once is so taken at the budget's pace, all of it, not
@@ -1939,9 +2141,7 @@ delegation chain is verified after these (§6.7). A person refuses another perso
     can wait.
   - An envelope over the limit that would expire before the budget has room for it, with a minute
     to spare for the relay's next redelivery, can never be taken. It is dropped (acked). A message
-    sender gets at most one `rate_limited` receipt a minute. A chat sender gets a `rejected` receipt
-    with `rate_limited` for every such chat envelope, up to four times the chat budget a minute, so
-    its line is `refused` at once instead of `sent` until it expires.
+    sender gets at most one `rate_limited` receipt a minute. Person-addressed controls get individual refusals, bounded by the response budget.
   - Presence over its budget is dropped: it is never queued, and the next one supersedes it.
 - **Quota.** A recipient may cap the inbox items and bytes it holds from one sender machine
   (`rate_limited` past it).
@@ -1954,6 +2154,26 @@ delegation chain is verified after these (§6.7). A person refuses another perso
 - **`wake` on an inbox item.** This is the sender's hint, AND-ed with the session's tier, which must be
   `push`. Only what consent delivers becomes an inbox item, so a held request never wakes a session.
 
+- **Mixed versions** (0.7.1 and the conversations release). Neither side shims the other, and neither leaves a
+  half-open contact:
+  - A daemon from before conversations sends a chat line, plain mail or a message request without a portable proof
+    as an envelope. A current daemon refuses each with a `rejected` receipt, code `refused`, and the `note` "The
+    recipient runs a newer Messaging that takes conversations only: update Messaging to reach them." 0.7.1 records
+    only the code: it shows `refused` with its hint "do not retry; tell your person", the clearest it can show, since
+    none of its hints names an update. The note is for later senders and the logs.
+  - A current daemon asks the relay (`conv.caps`, §7) before it creates a dm, group or channel with a person, adds
+    one, or sends a message request. A person whose known devices all lack the `conversations` presence feature is
+    refused with `peer_outdated`, "<handle> needs to update Messaging", and nothing is created or sent. With no
+    presence for that person in the envelope TTL, the relay has no evidence, and the call goes ahead.
+    A request that then reaches a client before conversations is filed there and answered `delivered`, which a
+    current recipient never sends for a request (it holds it, and an accept activates the dm at the relay). The
+    sender's daemon takes a `delivered` or `read` receipt for a request envelope from that recipient's device as that
+    proof: `request.waiting` shows the request with state `outdated` (the recipient must update Messaging, and the
+    request must then be sent again), instead of `held` forever.
+  - Tasks keep their envelopes and work in both directions.
+  - Rollout: the relay first (it serves 0.7.1 unchanged), then every daemon of a realm together
+    (`docs/distribution.md`, "Versions and compatibility").
+
 ### 8.4 Delivery stages (sender view)
 
 - The normal sequence is `accepted → relayed → delivered → handed_to_agent → read`. A request the
@@ -2036,8 +2256,8 @@ then lives in plaintext in the sender's and recipient's stores for their retenti
 and in the recipient's model context. The sending daemon therefore refuses such content before it
 stores or seals anything. The relay never sees plaintext, so this check exists only on the sender.
 
-- **Where.** `msg.send` (lines, messages, replies and task requests), `task.update` (status message
-  and artifact), `task.cancel` (`reason`) and `person.send` (`text`). The daemon reads every string in
+- **Where.** `task.create`, `task.continue`, `conv.send`, `conv.edit`, `task.update` (status message
+  and artifact), and `task.cancel` (`reason`). The daemon reads every string in
   the call's params except the session `key`: values and object keys at any depth, including
   `metadata` and `data` parts, and the base64-decoded bytes of every `raw` field, read as UTF-8.
 - **When.** After the key and task-role checks (`not_found`, `invalid_state` for a wrong role), and
@@ -2076,26 +2296,34 @@ stores or seals anything. The relay never sees plaintext, so this check exists o
 
 ### 8.8 Store schema
 
-The daemon's store (`messaging.db`) and the relay's database each have one baseline, schema 1. Messaging resets
-its stores now and grows them later (owner, 2026-11-08):
-
-- **Until the first release another person uses**, a store change edits the baseline instead of adding a
-  migration, and raises the store's generation. The release that carries it resets the stores and says so in its
-  notes. Release 0.7.0 is the first such reset: it reads no store of 0.1.0 to 0.6.0.
-- **From that release on**, stores only grow, so that a host can roll a daemon or relay back by moving the
-  binary back and keeping the data. Migrations then follow the rules under "When stores grow" below.
+The daemon's store (`messaging.db`) and the relay's database each have one baseline, schema 1, as release 0.7.0
+created it (owner, 2026-11-08):
+
+- **Release 0.7.0 was the last store reset.** It reads no store of 0.1.0 to 0.6.0. It is the first release another
+  person uses (Jelly's hosted users), so no later release resets a store or raises a generation.
+- **From 0.7.0 on, stores only grow**, so that a host can roll a daemon or relay back by moving the binary back
+  and keeping the data. A store change adds an idempotent migration and a new schema number, under the rules of
+  "When stores grow" below; the baseline is never edited.
+- The daemon store is at **schema 4** and the relay database at **schema 3**, each the baseline plus its migrations:
+  - daemon schema 2 adds `conv_logs`, `conv_entries`, `conv_shares`, `conv_cursors`, `conv_outbox`, `conv_keys`,
+    `conv_alarms` and `conv_fts`; schema 3 adds `conv_held`; schema 4 adds `conv_evidence`;
+  - relay schema 2 adds `conv_logs`, `conv_entries`, `conv_members` and `conv_shares` (§7 "Conversation frames");
+    schema 3 adds `conv_request_decisions`.
+  Each keeps `min_reader` 1, so a 0.7.x daemon or relay still opens the store after a rollback and ignores the new
+  tables.
 
 **Records.** The daemon's store keeps `generation`, `schema` and `min_reader`, the lowest schema that can read
 it, in its `kv` table. The relay keeps `generation` and `min_reader` in its `meta` table, and `schema` in
-`PRAGMA user_version`. A new store records generation 2, schema 1 and `min_reader` 1. The stores of 0.1.0 to
-0.6.0 have no generation (generation 1).
+`PRAGMA user_version`. Every store from 0.7.0 on records generation 2 and `min_reader` 1; a new daemon store records
+schema 4, and a new relay database schema 3. The stores of 0.1.0 to 0.6.0 have no generation (generation 1).
 
-**Opening.** A store with no tables is new: the daemon or relay writes the baseline and its records. For the relay,
+**Opening.** A store with no tables is new: the daemon or relay writes the baseline, its records and every migration. For the relay,
 the tables Litestream adds when it replicates the database (`_litestream_*`) do not count. It opens
 any other store only when the store records its own generation and a `min_reader` at most its own schema. It
-refuses every other store and changes nothing in it, and the error says how to start over: stop the daemon or
-relay, move the home (or the relay database, with its `-wal` and `-shm` files) aside, and set it up again. A
-daemon checks the store before it reads or writes anything else in its home. Nothing deletes a home or a
+refuses every other store and changes nothing in it. The error gives the reason and its remedy (below).
+Only `pre-reset` calls for starting over: stop the daemon or relay, move the home (or the relay database,
+with its `-wal` and `-shm` files) aside, and set it up again. For `newer`, upgrade the reader and keep the data.
+A daemon checks the store before it reads or writes anything else in its home. Nothing deletes a home or
 database by itself.
 
 **A refused store** is machine-readable, so that a client never matches the wording. Every refusal has one of two
@@ -2124,6 +2352,9 @@ database by itself.
   client that denies its agents the home also denies `<home>.pre-reset-*`: the moved home keeps the old keys and
   messages. The messagingd that wrote it still opens it.
 
+**Daemon schema 5** adds `reach_grants` and `reach_reviews`: the person's relation grants (§6.9, "Reach choices") and
+their review entries, apart from `grants`. An older daemon ignores them, and so does not enforce the choices (§6.9).
+
 **When stores grow.**
 
 - A daemon or relay opens any store of its generation whose `min_reader` is at most its own schema. It
@@ -2137,10 +2368,13 @@ database by itself.
 - A breaking change needs a new store file with an explicit export and import, never an in-place change.
   `min_reader` is raised only in an emergency, and hosts that pin the daemon are told first.
 
-**The test.** `store-schemas/1.json` in `packages/daemon` and `packages/relay` is the shape of the baseline
-(tables, columns, indexes, constraints, triggers). `test/release/store-schema.test.ts` in each package fails
-when HEAD's store differs from it, so a store change is seen in review. When stores grow, each released schema
-gets its snapshot, and the test holds HEAD to every one of them.
+**The test.** `store-schemas/<n>.json` in `packages/daemon` and `packages/relay` is the shape of schema n as
+released (tables, columns, indexes, constraints, triggers); `1.json` is the baseline as 0.7.0 created it.
+`test/release/store-schema.test.ts` in each package holds the baseline to `1.json` and HEAD's new store to the last
+snapshot, so a store change is seen in review. Each also opens a database the schema-1 release itself wrote
+(`test/fixtures/relay-schema-1.sql` and `test/fixtures/daemon-schema-1.sql`), checks that it migrates in place with every row intact except the schema marker, that migrating again
+changes nothing, and that a schema-1 reader still opens the result: its records allow it, and every table, column
+and index of schema 1 is unchanged inside it.
 
 The wire rule (§14) is separate; a rolled-back daemon must still speak to newer peers within `messaging/1`.
 
@@ -2247,19 +2481,21 @@ and names each session an engine may register.
     parent writable by no one else and owned by the daemon's user or root.
   - `--socket-group <gid>` makes both sockets 0660 and owned by that group, and `run/` (and the home, when
     `run/` is inside it) 0710 to it. It is accepted only here: elsewhere `run/admin.sock` is always 0600.
-- **Action grants.** On `run/admin.sock`, every method outside `AGENT_METHODS` needs an action grant, a
-  compact JWS in the request's top-level `grant` member, beside `params`:
+- **Action grants.** On `run/admin.sock`, every method outside `AGENT_METHODS`, and every call whose params carry an
+  action `token` (§8.2, "Action tokens"), needs an action grant, a compact JWS in the request's top-level `grant`
+  member, beside `params`:
   - the header is `{alg: "EdDSA", typ: "jelly-act+jwt", kid}`, and the signature verifies with the action
     key (whose `kid`, when the key file has one, the header must name);
   - `aud` is `"@joe-broadhead/opencode-messaging#service"`;
   - `act` is the method, and `in` is `base64url(SHA-256(JCS(params)))` of the params as sent (absent
-    params are `{}`);
+    params are `{}`). The params include any action `token` (§8.2), so the host's grant signer sees the token. That
+    is expected: the host's client received it in the view;
   - `exp - iat` is in (0, 60] seconds, `iat` at most 5 s ahead of the daemon's clock and `exp` at most 5 s
     behind it;
   - `cls` is required, and is the method's action class (`ACTION_CLASSES`, `actionClass` in `@messaging/core`):
-    `chat` for `person.send`, `conv.markRead` and `notice.ack`; `view` for the reads a host's section makes, the
-    read-only human-tier methods and `device.list` (`conv.list`, `conv.read`, `conv.subscribe`, `people.search`,
-    `people.get`, `grant.list`, `request.list`, `agents.list`, `agents.read`, `notice.subscribe`, `notice.list`,
+    `chat` for `conv.send`, `conv.edit`, `conv.delete`, `conv.react` and `notice.ack`; `view` for the reads a host's section makes, the
+    read-only human-tier methods and `device.list` (`conv.list`, `conv.read`, `conv.sync`, `conv.get`, `conv.members`, `conv.threads`, `conv.search`, `conv.context`, `conv.access`, `request.waiting`, `people.search`,
+    `people.get`, `grant.list`, `reach.get`, `request.list`, `sessions.list`, `tasks.list`, `tasks.get`, `notice.subscribe`, `notice.list`,
     `device.list`); `local` for every other method, the previews and every other admin-tier method included.
     (`device.status` is agent tier: it needs no grant.) So `view` is refused on any method that writes, and a preview, which tells what
     a `local` action would do, takes `local`. A plugin's `jelly` declaration must give each action and read the same
@@ -2273,8 +2509,8 @@ and names each session an engine may register.
   `person.attached`, `daemon.snapshot`, `wake.arm` and `wake.disarm`.
   It is bound to the first connection that presents it, and may be presented again on that connection until
   it expires; on another connection, or after a restart, it is `grant_invalid`. Under a host-scope grant
-  `conv.list` returns counts only: each conversation's `conversation`, `kind`, `readUpTo` and `unread`, with
-  no channel name, time or seq. A `notice.subscribe` under a host-scope grant ends when the grant does: the
+  `conv.list` is refused before content is read. Lane 4 exposes no placeholder counts.
+  A `notice.subscribe` under a host-scope grant ends when the grant does: the
   host subscribes again with a fresh grant and `after`.
 - **Refusals.** No grant is `grant_required`; any failure above is `grant_invalid`. The agent tier needs no
   grant on either socket. Both are checked before the params are read. The daemon logs each refusal with
@@ -2309,7 +2545,16 @@ and names each session an engine may register.
   request envelope ids of those agents' requester tasks that have not ended (submitted, working, input- or
   auth-required), most recently updated first, at most 500. Their updates name the request in `replyTo` (§6.2), so the
   relay can match them without reading a body. Mail an agent sent and a reply it may get is not awaited: only a task
-  is. It returns `{relay: "armed" | "pending", awaiting}`: `pending` while the relay is not connected, and the arm then
+  is. The daemon also adds `dms`: the verified dm conversations of which this person is a member whose other
+  participant's person shares a `channel` with this person (both seated there as persons, not only through an
+  agent, and `member`, in that channel's verified log) and passes `shouldArm` (not blocked or muted by this
+  person's grants, and not hidden by their reach choices: under Never a person of another org with no chat on their
+  person grant, §6.9), most recently active first, at most `WAKE_DMS`. The daemon reads the candidates' directory
+  views in batches before it decides. It is the host's own list: no other member learns it, and the daemon logs only
+  its count. The list is what held when the host armed: a person blocked, muted or hidden afterwards (on another of
+  this person's devices, while the host sleeps) stays armed until the next `wake.arm`. That is at most one wake: the
+  ticket is single-use, and the wake budget applies. It returns `{relay: "armed" | "pending", awaiting, dms}` (the counts): `pending` while the relay is not
+  connected, and the arm then
   goes out at the next welcome (a newer `wake.arm` or `wake.disarm` replaces it; one the relay refuses is not sent
   again). `wake.disarm {}` forgets it, and `daemon.woke` disarms a ticket armed since the last disarm. The daemon never
   logs the ticket.
@@ -2481,6 +2726,9 @@ implementation:
   `in` digest, a method grant, a host-scope grant and a session ticket signed by it, and grants a daemon must
   refuse (another method, params, key, `kid`, `typ` or audience; a lifetime past 60 or 600 s; an expired grant;
   a `cls` of another class; host scope for a method outside its list).
+- `action-tokens.json` (§8.2, "Action tokens"): a token, held requests with their actions, the `request.answer` and
+  `task.cancel` params that redeem one, and shapes to refuse (an action that is not an answer, a short or padded
+  token, a token with `all`, a cancel with neither or both of `key` and `token`).
 
 `packages/core/scripts/vectors.ts` generates them. Run `npm run build && npm run vectors -w @messaging/core`;
 this uses Node's type stripping against the built package and `@messaging/core/testing`. `packages/core/test/vectors.test.ts`
@@ -2500,30 +2748,38 @@ daemon owned by the uid in `MESSAGING_DAEMON_UID` (§8.1).
 
 ### Agent tools
 
-The OpenCode plugin and `messaging-mcp` offer an agent the same eight tools, with the same input and
-output schemas (`AgentTool` in `@messaging/core`, normative like `schema/**`): `contacts`, `send`,
-`inbox`, `read`, `search`, `tasks`, `task_update` and `task_cancel`. Their names are
+**Conversation tools.** `ConversationTools` is the shared schema registry for the conversation-model
+cut-over. Its ten verbs are `contacts`,
+`conversations`, `send`, `inbox`, `read`, `search`, `context`, `tasks`, `task_update` and `task_cancel`.
+`conversations` uses `conv.access`; `send`, `read`, `search` and `context` use their `conv.*` counterparts.
+Results identify a line by the stable citation `messaging:<cid>/<id>`. The client fences peer text and names,
+neutralizes fence closers, and labels own text as ours. List results contain at most 50 events and 32 KiB of text;
+each fenced event also has the existing per-part cap, `LIMITS.toolTextChars` (32,768).
+Long bodies have `[truncated: N bytes; read the item for the full text]`, where N counts omitted UTF-8 bytes.
+The stored body stays intact. `read({source, offset})` continues at the returned `nextOffset` until the full body is shown.
+A held result waits for consent and does not disclose the person's answer. Tools grant no human-tier action.
+
+The OpenCode plugin and `messaging-mcp` use the same ten-tool contract in `@messaging/core`, normative like `schema/**`.
+Their names are
 `messaging_<verb>`; in OpenCode's Code Mode, `tools.messaging.<verb>`. No tool grants, adds
 contacts, changes devices or administers a team or channel.
 
-- **Addresses.** `me` (the session's own person), `me/<agent>`, `<person>`, `<person>/<agent>`,
-  `<person>/<agent>@<label>` and `#<channel>` (a channel the person is in, by its local name). An
-  agent is a session (§3). Malformed text is `invalid_request` naming the field, and so is a group
-  form (`person/*`, `repo:…`, `*`): there are none (§3). A person, agent or channel the daemon does not know
-  (`not_found` for a person or channel, `no_recipients` for an agent, from `msg.send` or `conv.read`) is `unknown_address`; an agent
-  that runs on none of its person's machines is `unknown_session` (§3, "Resolution"); `ambiguous_address` asks for `@label`. `me`, and one's own person name, is the person's own
-  conversation, `dm:<self>` (§6.8): `send` writes a line there (unread for the person), `read` and
-  `search` read it, and a guarded peer turn may write there too. An `ask` to `me` (a request card to
-  one's own person) is `invalid_request`: it is not in this build.
-- **Conversations.** `person:<person>` is the person's DM room with them (§6.8), seen from the agent;
-  `agent:<person>/<agent>` is the session's mail and tasks with that session on any machine
-  (`conv.read`, §8.2); `channel:<name>` is a channel room. `read({with})` pages one of them, oldest
-  first, with opaque `before`/`after` cursors. Mail and task entries carry previews; outgoing mail
-  carries no text, because the daemon keeps no copy of what it sent.
+- **Addresses.** Lines accept a canonical `cid` or a person or agent destination.
+  `#<channel>` resolves through accessible conversations. An agent sends to a conversation it is seated in, or to another
+  agent (`person/agent`). With no dm yet, its person's device signs the create of the agent dm, whose only participants
+  are the two agents; the recipient's `ask` admits the invited agent (`open` at once, `request` after its person
+  accepts, `no` never, silently). Until the seat the line waits on the sending device, keeps the id the send returned,
+  shows in `request.waiting` as `pending-delivery`, and lapses after 7 days. An agent cannot start a dm with a person,
+  and cannot add or seat anyone. The sender-side consent is the client's first-send confirmation for the address (the
+  plugin's `messaging.send` permission), as for 0.7.1 mail; the daemon has no separate signal.
+  Retained tasks use `person/agent[@label]`. Malformed addresses are `invalid_request`.
+  An ambiguous task address requires a device label. Human contact requests remain human-only.
+- **Conversations.** `read({cid})` pages current verified events with opaque cursors.
+  Conversation identity is stable across devices. Legacy room names are not aliases.
 - **`contacts`** lists `me` (address, person, agent, device label, relay `connected` or `offline`), the
-  persons in the directory and in DM rooms, each with their agents (state, `expect` from
-  `contacts.list` (§8.2), repo, branch and doing), and the channels `contacts.list` names, with their unread
-  counts. `org` is `same` for every teammate. A person's `can` is the daemon's `reach` for them (§8.2
+  persons in the directory and in conversations, each with their agents (state, `expect` from
+  `contacts.list` (§8.2), repo, branch and doing), and channels allowed by `conv.access`.
+  Counts and read preferences are omitted when unavailable. A person's `can` is the daemon's `reach` for them (§8.2
   `contacts.list`): `source: "card"` with `card`, when their person signed it, or `source: "default"`, the
   defaults for the org or for a stranger; `can.chat` is false for one's own person and when the client offers no
   DMs. An agent's `can` is its person's, except that `can.chat` is false and the inbound policy narrows it (§8.3: a
@@ -2533,30 +2789,28 @@ contacts, changes devices or administers a team or channel.
   refused. `can: "ask"` lists those whose `can.ask` is not `no`. A channel's `can` is `default`. `presence` is
   `online`,
   `offline` or (for a channel) `unknown`. No field is invented.
-- **`send`** is one `msg.send`: a chat line to `<person>` or `#<channel>`, or mail or, with `ask`, a
-  task to an agent. `replyTo` names a line (the thread), a message from that agent
-  (`replyTo` and its `contextId`), or a task the session requested (`taskId`: input for it, to its
-  executor only). `onBehalfOf` (with `ask`) passes `msg.send {onBehalfOf: {taskId}}` after
-  checking that the session runs that task and it is not finished. `files` (only to an agent) become
-  file parts. `key` makes a repeated call send once (`idempotencyKey`);
-  without it the client derives one from the tool call. Results carry each `SendResult.expect` and a
-  fixed `note`. A result at stage `held` (the recipient's person answers a request card first, §6.9)
-  carries `expect: "on_consent"` and a note saying so. `request: {contact: <email>}`, only with `to: "me"`
-  (otherwise `invalid_request`), passes `msg.send {request}`: the line goes to the agent's own person with a
-  suggestion to send a message request to that exact email (§6.9, "Message requests"); the agent cannot send one,
-  and its note says it is not told what the person decides. A send refused `request_required` tells the agent to
-  ask its person this way.
+- **Sources.** An item target or result names `source: {kind: "conv", cid, event}` or `source: {kind: "task", taskId}`.
+  A task never receives a fabricated conversation id. Conversation item identity includes both `cid` and `event`.
+- **`send`** uses `conv.send` for lines, including agent DMs. `ask` uses `task.create`.
+  A task continuation uses `task.continue`. Task sends retain `files`, `replyTo`, `onBehalfOf` and `key`.
+  Delegation requires an unfinished task that this session executes. `key` or `clientId` makes retries idempotent.
+  A line returns its conversation source and `pending`. A task returns its task source and delivery results.
+  An authenticated hold carries `expect: "on_consent"`. Missing receipts do not imply a hold.
 - **`inbox`** lists mail and task requests (`inbox.list`), unread by default, and acks
   `handed_to_agent` for the previews it shows. `consent` says how a request from the sender runs
   here: `self` (the session's own person), `trusted` or `guarded`. It is the inbox item's `consent`, the
   daemon's decision (§6.9); a client decides it only for a task record or an item stored before
   consent, which carry none.
-- **`read({id})`** looks the id up as an inbox item (`inbox.get`, then `item.read`: marked read, read
-  receipt), a task (`task.get`), or an envelope the session sent (`item.read`, as `delivery`).
-- **`search`** covers chat lines (`search`) with persons and in channels; agent mail is not
-  searched.
+- **`read({source})`** reads the named conversation event or retained task. It preserves the daemon's consent decision.
+  A held event read acknowledges nothing. `read({cid})` returns a conversation page with opaque cursors.
+- **`search`** uses `conv.search` within the daemon's access rules.
 - **`tasks`** lists `task.list` with roles `mine` (requester) and `asked` (executor) and short state
   names (`working`, `input_required`, …); `state` also takes `open` and `done`.
+  A task in `auth_required` shows `signIn {tool?, by}`, and one in `rejected` shows `refusal {reason}`, from the task
+  view (§8.2). The tool and the reason are the executor's words, with the author `statusAuthor` names: fenced when the
+  peer wrote them, cleaned and shown without a fence when this side did. `by` is the daemon's, never the peer's. The
+  agent tier never sees `question`, and no tool sets it (the runtime calls `task.question`). `task_update` takes no sign-in tool yet: a plugin that knows which tool is waiting
+  passes it with `task.update {signIn}`.
 - **`task_update`** (executor) and **`task_cancel`** (requester) map to `task.update` and
   `task.cancel`; a cancel of a finished task returns its state and sends nothing.
 - **Errors.** A tool error is `{error: {code, message, remedy}}`: `code` from §13, a `message` that
@@ -2593,12 +2847,12 @@ contacts, changes devices or administers a team or channel.
 
 ### Clients
 
-- **OpenCode plugin.** Tools under namespace `messaging`: `contacts`, `send`, `inbox`, `read`,
-  `search`, `tasks`, `task_update` and `task_cancel`. Every send asserts `messaging.send` with the
+- **OpenCode plugin.** Tools under namespace `messaging`: `contacts`, `conversations`, `send`, `inbox`, `read`,
+  `search`, `context`, `tasks`, `task_update` and `task_cancel`. Every send asserts `messaging.send` with the
   address as its resource (`person/agent`, `#channel`, or `person` and `person/`), and every read of
   a conversation asserts `messaging.read` with the conversation (a `person:` one asks first by
   default). Inbound content is framed as untrusted data. Details are in the plugin's repository, `joe-broadhead/opencode-messaging` (`docs/`).
-  - It never calls `conv.markRead`: read state is the person's.
+  - It never changes human read state.
   - With wakes on, it registers each session with `host: {kind: "opencode", location, sessionID,
     pid}`: its location directory, the OpenCode session id, and the server's pid.
   - Its RPC `messaging.opencode/wake {sessionID, envelopeIds}` serves the wake bridge (§8.6). It checks
@@ -2622,16 +2876,10 @@ contacts, changes devices or administers a team or channel.
     item only after the host recorded the tool result with the note intact; until then the item is
     only offered, and an offer that fails or is cut goes back to waiting. No wire change.
 - **MCP server.** `messaging-mcp` (stdio) for other agents. It registers one `pull`-tier session and
-  subscribes to its events. Its tools are `messaging_contacts`, `messaging_send`, `messaging_inbox`,
-  `messaging_read`, `messaging_search`, `messaging_tasks`, `messaging_task_update` and
-  `messaging_task_cancel`, over `daemon.status`, `contacts.list`, `msg.send`, `item.read`,
-  `inbox.list/get/ack`, `conv.read`, `task.list/get/update/cancel` and `search`.
-  - MCP has no per-conversation approval of its own, so chats are opt-in: the user names channels
-    when configuring the server, with `--channel <name>` (repeatable). `send`, `read` and `search`
-    reach those channels only, and are refused (`forbidden`) for any other channel before any daemon
-    call. Conversations with persons (DM lines) are never available over MCP: a line to a person, or
-    `read`/`search` with one, is `forbidden`. It never calls `conv.subscribe`, `conv.markRead`,
-    `person.send` or `channel.*`.
+  subscribes to its events. It registers the ten tools in `ConversationTools`: `messaging_contacts`, `messaging_conversations`, `messaging_send`, `messaging_inbox`, `messaging_read`, `messaging_search`, `messaging_context`, `messaging_tasks`, `messaging_task_update` and `messaging_task_cancel`.
+  Lines and conversation reads use `conv.*`. Retained tasks use `task.create/continue/list/get/update/cancel` and `inbox.list/get/ack`.
+  - The daemon controls access through `conv.access`. Contacts expose only accessible channel cards.
+    MCP uses the agent socket and never calls human-tier methods or changes human read state.
   - It has no peer-turn guard: its agent reads every request itself, with its own tools. It reports
     the daemon's `consent` for each item; where the daemon gives none (a task record), `self` for the
     session's own person and `trusted` for everyone else.
@@ -2768,7 +3016,7 @@ contacts, changes devices or administers a team or channel.
     `prompt` when a dialog on every daemon start is acceptable.
 - **Local IPC.** The sockets trust users, not processes (§8.2).
   - The daemon enforces two sockets: `run/agent.sock` serves only `AGENT_METHODS`, so never a line as
-    the person (`person.send`); `run/admin.sock` serves everything.
+    the person; `run/admin.sock` serves everything. Agent conversation calls require a registered session.
   - Under one OS user that is no boundary: any process of the user can open `run/admin.sock`, call
     `team.*` and `daemon.stop`, and act for any session whose key it knows: session keys are bearer
     credentials. The tiers keep those methods off agent tool paths, nothing more.
@@ -2813,6 +3061,10 @@ contacts, changes devices or administers a team or channel.
 
 ## 13. Error codes
 
+Tool errors use the codes in this section for both conversation and task sources (§11).
+An unknown source is `not_found`. A source that combines task and conversation identifiers is `invalid_request`.
+Oversized model-visible text is truncated with the explicit marker in §11, rather than reported as `too_large`.
+
 | Code | Meaning |
 |---|---|
 | invalid_request | malformed input or schema violation |
@@ -2825,6 +3077,7 @@ contacts, changes devices or administers a team or channel.
 | refused | recipient policy refuses this sender |
 | declined | the recipient's person declined a held request (§6.9) |
 | request_required | the recipient's person has not accepted this sender: another org's person needs a message request first (§6.9) |
+| peer_outdated | the other person's devices all run a Messaging from before conversations (`conv.caps`, §7); nothing was created or sent. They need to update first |
 | rate_limited | too many envelopes; retry later |
 | loop_guard | agent-to-agent loop guard tripped |
 | too_large | size limit exceeded |
@@ -2838,11 +3091,12 @@ contacts, changes devices or administers a team or channel.
 | guarded_turn | a guarded peer turn tried to send to anyone but the person who started it (§11; a client code, never on the wire) |
 | roster_conflict | roster entry does not extend the current head |
 | invite_invalid | invite unknown, expired, revoked, used or mismatched |
-| no_identity | the daemon has not created or joined a team |
+| no_identity | the daemon has no usable identity: no team, or a directory device not yet bound with published keys (§15.9) |
 | binding_invalid | a device binding, a device-log entry or its authority failed verification (§15) |
-| jelly_unavailable | Jelly ID's key set or key history could not be fetched (§15.2); never reported as `binding_invalid` |
+| jelly_unavailable | Jelly ID could not be reached or returned an unusable response during key fetching (§15.2) or device sign-in (§15.9); never reported as `binding_invalid` |
 | log_conflict | a device-log entry does not extend the log's head (§15.3); resync and retry |
-| conv_conflict | a conversation entry does not extend the log, or an event's op head is not the current op (§16.7); re-read and retry |
+| conv_conflict | a conversation entry does not extend the log, or an event's op head is not the current op (§16.7); re-read and retry. Also a control op (`conv.add`, `conv.remove`, …) on a conversation that kept queuing events through three drains: "the conversation is busy sending; try again", which can be retried as is |
+| conflict | a person's setting changed since the caller read it: `reach.set` with a stale `revision` (§8.2); nothing changed, read again |
 | stale_epoch | a conversation message is sealed under an epoch that is not the current one, or a rekey is due (§16.7); re-seal and retry |
 | device_limit | the person already has `LIMITS.devicesPerPerson` current devices (§15.3) |
 | admission_required | `dir.bind` of an entry that is not a device binding itself with a `jelly` authority (§15.10) |
@@ -2852,8 +3106,8 @@ contacts, changes devices or administers a team or channel.
 | directory_unavailable | the key directory could not be reached to adopt a tree head or verify a person within the freshness bound (§15.9) |
 | login_unsupported | Jelly ID's metadata names no device sign-in, or none for this realm's resource (§15.9, "Signing in through the browser") |
 | login_denied | the person denied a device sign-in at Jelly ID, or the account is disabled or being deleted (§15.9) |
-| grant_required | `deployment: "jelly"`: a human- or admin-tier call carried no action grant (§8.11) |
-| grant_invalid | `deployment: "jelly"`: the action grant did not verify, is for another method, params or audience, is out of its lifetime, was spent, or is a host-scope grant bound to another connection (§8.11) |
+| grant_required | `deployment: "jelly"`: a human- or admin-tier call carried no action grant (§8.11), or a `request.answer` no action token (§8.2) |
+| grant_invalid | `deployment: "jelly"`: the action grant did not verify, is for another method, params or audience, is out of its lifetime, was spent, or is a host-scope grant bound to another connection (§8.11). Any deployment: an action token that the daemon did not offer for this action, target and view, or that was spent or has ended (§8.2, "Action tokens") |
 | ticket_required | `deployment: "jelly"`: `session.register` carried no session ticket (§8.11) |
 | ticket_invalid | `deployment: "jelly"`: the session ticket did not verify, is out of its lifetime, or names another session or agent (§8.11) |
 | daemon_unavailable | a client cannot reach the daemon |
@@ -3360,11 +3614,9 @@ when a restore does not reach it: keep it on other storage than the database, or
 who accepts the fork on purpose moves the witness aside and starts again.
 
 **Resolution.** From each person's newest verified Jelly token the directory keeps their name, their email when
-Jelly ID proved it, and from that email their **handle** and **org** (`emailHandle`, `emailOrg`):
+Jelly ID proved it, and from that email their **handle** and **org** (`hostedHandle`, `emailOrg`):
 
-- the handle is the email's local part lower-cased, each run of characters outside `[a-z0-9]` made one `-`, `-`
-  trimmed from both ends, cut to 30 characters (trimmed again), and `u-` put in front when it does not start with
-  a letter;
+- the handle uses `hostedHandle`, exactly as §15.8 defines it;
 - the org is `domain:<d>` when the email's domain `d` is in the operator's `orgDomains` (`--org-domains`), and
   none otherwise: such a person is an individual, in no org.
 
@@ -3414,9 +3666,12 @@ anchor must be an `epoch` anchor whose root is the directory's at that size (`di
   `rate_limited` with `retryAfterMs`. The per-day counts, and the copies of an open request, are kept in memory,
   from UTC midnight.
 - **Presence** (`to: {team: true}`) goes only to devices that `presence.watch` the person and are in the person's
-  **audience**: the person themselves, the same org, or persons who each sent the other an envelope other than a
-  receipt in the last 30 days. A
-  watcher outside it learns nothing, not even "offline". The relay sends no `peer` notices.
+  **audience**: the person themselves, the same org, persons who each sent the other an envelope other than a
+  receipt in the last 30 days, or persons who are both accepted members of one conversation the relay sequences
+  (§7 "Conversation frames"), for as long as both are. The relay reads that from the plaintext op state it already
+  holds: an invited participant does not count, a removed or departed one stops counting, and an external dm counts
+  only once activated (its request accepted). A watcher outside the audience learns nothing, not even "offline". The
+  relay sends no `peer` notices.
 
 **Erasure.** Erasing a person appends an `unbind` of each current device, sets their map value to the tombstone
 (§15.5) at the next epoch, deletes their profile, every log body, witness and keys statement and every pair they
@@ -3455,17 +3710,45 @@ five minutes, until it answers, so a new directory becomes ready without waiting
 `dir_keys`, `dir_epochs`, `dir_map` (each person's committed value), `dir_rotations`, `dir_pairs` (with
 `line_at`, when the pair last carried an envelope other than a receipt), `dir_jelly_keys`, `dir_feed`, and
 `dir_wakes`: each Jelly host's device's armed wake ticket, its `agents` and `awaiting`, its `exp` and when it may
-next be presented (§7, "Wake tickets"). At start the directory rebuilds the map and the epoch log from them
+next be presented (§7, "Wake tickets"), and `dir_wake_dms` (relay schema 4): the dms each armed device named, with
+the `exp` of the ticket they were armed with, so a ticket armed again without them does not keep them. At start the directory rebuilds the map and the epoch log from them
 and refuses to start if they disagree with the last tree head.
 
 ## 16. Conversations
 
+**Guest acceptance (X3-1).** An invited participant is not a content reader.
+The relay serves authenticated control history and heads to invitees, with message digests instead of ciphertext and a zero share cursor.
+It pushes invitation operations, never message content or keys, to a person represented only by invited seats.
+`ConvLog.checkShare` requires an accepted recipient. For a group or history `none`, acceptance (including seating an invited
+agent) is the effective addition: it updates `since` and requires an `added` rekey before messages or shares.
+Inviting alone does not start that epoch. Shared channels keep their declared shared-history exposure after acceptance.
+A guest cannot invite or change to another role, even via an intermediate member role. Agents inherit their owner's
+guest restriction; a guest agent needs an accepted, visible guest owner and that owner's signed seat. Live org checks
+cover agent principals too; two persons without an org are not implicitly one org.
+
+A guest's `accept` carries `invitation`, a `GuestInvitation` signed under `DOMAIN.guestInvitation`.
+The preview binds the invitation ID, inviter device, realm, conversation, invitee, exact op head, expiry, current audience and exposure policies.
+The device that signed the original add or create signs this bounded preview. The inviter seals it to the invitee without history or keys.
+The accept event signs the same preview. A changed audience, policy or op head requires a fresh preview.
+After acceptance, the invitee fetches the log and verifies the invitation independently before content or key use.
+`guestHistoryExposure` supplies explicit text for shared history and history from the acceptance boundary.
+
+**Agent-DM admission.** The recipient's `ask` policy controls an agent-only DM invitation, including invitations across orgs.
+`open` seats the recipient agent, `request` holds the invitation for the person, and `no` silently declines it locally.
+`request.list` exposes a held invitation as `{kind:"agent-invitation",id,cid,from,to,at}`, without content or keys.
+`request.answer` accepts `accept` or `decline`. Its preview identifies the sender and target agent and reports the affected count.
+With `all`, the answer applies to held agent invitations from the same person.
+
+The daemon records invitation-only history gaps durably. After acceptance, it fetches those entries again and verifies each signature against its stored digest.
+It replaces only matching gaps and applies the conversation's history policy before content use.
+This recovery survives restart. It never restores messages that local retention expired after acceptance.
+
 A conversation is one hash-chained log of signed events that the relay sequences and members verify. Membership,
 roles, epochs and settings are a function of the log. Message bodies are sealed under per-device sender keys, so a
 post is one ciphertext whatever the number of members. The schemas are in `schema/conversation.ts`, the rules in
-`conversation/` of core, and the vectors in `docs/spec/vectors/conversation.json`. The relay frames, the daemon's
-storage and the IPC surface that carry them are not specified yet; `docs/design/conversations.md` describes them.
-Until they land, chats are as §6.8 says.
+`conversation/` of core, and the vectors in `docs/spec/vectors/conversation.json`. The relay carries the logs in
+the conversation frames of §7. The daemon's storage and the IPC surface are not specified yet;
+`docs/design/conversations.md` describes them. Until they land, chats are as §6.8 says.
 
 ### 16.1 Identifiers
 
@@ -3500,19 +3783,23 @@ Every event has a header and a body. The header is:
 - `opHead` is the last op the author applied: its `seq` and `h(seq)`, or `{0, h(0)}` before any.
 - `seen` is the head the author had, for gossip (§16.4).
 - `class` is:
-  - `op`: a control op in plaintext (`ConvOp`), because the relay routes and checks authority by it;
+  - `op`: a control op (`ConvOp`), because the relay routes and checks authority by it. Every piece of state is an
+    op, and ops never expire (§16.4); an op whose content must stay private carries it sealed (§16.5);
   - `msg`: a sealed `MsgBody`, with the `epoch` and the ratchet index `idx` of its key (§16.5). `wake` (at most
-    `LIMITS.wakeHints` (5)) names sessions of `by.person` the event may wake; it is the only plaintext hint;
-  - `keys`: sender-key shares, each sealed to one device (§16.6).
+    `LIMITS.wakeHints` (5)) names sessions of `by.person` the event may wake; it is the only plaintext hint. The
+    author's daemon sets it only on a line that addresses the author's own agents, and the relay acts on it only for
+    the authenticated author's person's devices (§7, "Wake tickets");
+  - `keys`: a sender-key share sealed to one device (§16.6). It is signed like every event but is **not an entry
+    of the log**: the relay keeps it for its recipient alone.
 - `sig` covers the whole event: `Ed25519(by.device, "messaging/1/conv-event\n" || JCS(event without sig))`.
 - An event is at most `LIMITS.convEventBytes` (256 KiB) of JCS (`too_large`). Every object is strict: an unknown
   member is `invalid_request`.
 
-The relay stores and serves **entries**: `{seq, prev, event}`, where `seq` counts from 1 and `prev` is `h(seq − 1)`.
-The relay does not sign entries; members verify the chain (§16.4).
+The relay stores and serves **entries**: `{seq, prev, event}` of ops and msgs, where `seq` counts from 1 and `prev`
+is `h(seq − 1)`. The relay does not sign entries; members verify the chain (§16.4).
 
 **Ops** (`ConvOp`): `create`, `add`, `accept`, `join`, `leave`, `remove`, `role`, `seat`, `settings`,
-`archive` and `rekey`.
+`archive`, `rekey`, `policy`, `meta` and `setting`.
 
 - `create` states the kind, the visibility (channels), the history policy, `retainDays` (1 to
   `LIMITS.retainDaysMax` (365)), the org a public channel is open to, the participants as seats `{p, role,
@@ -3523,7 +3810,13 @@ The relay does not sign entries; members verify the chain (§16.4).
   `none`), and accepts its invite. Only an agent's seat carries `device` or `respondTo`.
 - `settings` changes the visibility, history, retention or permits. `archive {on}` archives or restores.
 - `rekey {epoch, cause}` starts the next epoch; `cause` is `removed`, `device`, `added`, `settings` or
-  `schedule`.
+  `schedule`. A device rekey also names the removed `device` and may give `until`, a chain position strictly before
+  the rekey. Other causes carry neither field.
+- `policy {agentContext?, bridges?}` sets one or both, in plaintext (§16.8, §16.10). In a dm or a group it is the
+  author's vote.
+- `meta {epoch, idx, sealed}`: a group's or channel's `{name?, topic?, purpose?}`, sealed (§16.5).
+- `setting {kind, epoch, idx, sealed}`: one of the person's settings in their `self` conversation, sealed;
+  `kind` is `prefs`, `grant`, `context`, `localRetention` or `link` (§16.3).
 
 ### 16.3 Message bodies
 
@@ -3539,17 +3832,25 @@ The plaintext of a `msg` event is one `MsgBody`, at most `LIMITS.convPlaintextBy
   `status` and `artifact` carry the A2A update events (§6.2) and `cancel` and `followUp` the requester's, each
   naming the root.
 - `receipt {target, stage}`: `delivered`, `handed_to_agent` or `read`.
-- `meta {name?, topic?, purpose?}` and `policy {agentContext?, bridges?}`, which sets one or both (§16.8, §16.10).
 - `sync {sync}`: a body of the person's `self` conversation, and only there.
 
+A conversation's name, topic and purpose, and its policy, are not message bodies: they are state, so they are ops
+(`meta`, `policy`), which never expire.
+
 A mention is `{p}` (a participant), `{all: "channel"}` or `{all: "here"}`. An attachment names a blob, its own
 AES-256-GCM key and nonce, its SHA-256 and size (at most `LIMITS.blobBytes` (25 MiB)), a media type and a name.
 
 **The self conversation.** A person's `self` conversation has one participant, the person, and history `shared`.
-Its `sync` bodies (`SyncBody`) are `read {cid, upTo, thread?}`, `unread {cid, from}`, `prefs {cid, notify,
-muteUntil?, receipts?}`, `follow`, `save`, `draft`, `joined`, `grant` (a consent grant, §6.9, verified over its
-raw value), `context {rules}` (§16.8), `localRetention {cid, days}` and `keys {cid, shares}` (at most
-`LIMITS.keyShares` (512) chain keys) and `link {link}` (§16.10). The last writer wins by `seq`.
+It holds two kinds of state:
+
+- **Passing state**, in `sync` bodies (`SyncBody`), which expire with the retention: `read {cid, upTo, thread?}`,
+  `unread {cid, from}`, `follow`, `save`, `draft`, `joined` and `keys {cid, shares}` (at most `LIMITS.keyShares`
+  (512) chain keys).
+- **Settings**, in `setting` ops (`SettingBody`, sealed), which never expire: `prefs {cid, notify, muteUntil?,
+  receipts?}`, `grant` (a consent grant, §6.9, verified over its raw value), `context {rules}` (§16.8),
+  `localRetention {cid, days}` and `link {link}` (§16.10). The op's `kind` is the body's `s`.
+
+The last writer wins by `seq`.
 
 ### 16.4 The hash chain and gossip
 
@@ -3560,9 +3861,24 @@ raw value), `context {rules}` (§16.8), `localRetention {cid, days}` and `keys {
   fetches up to `seen.seq` first), `consistent` when its `h(seen.seq)` is `seen.hash`, `diverged` otherwise. A
   divergence proves that the relay showed two members different logs; the signed event is the evidence. `seen`
   at or past the event's own `seq` is `invalid_request`.
-- **Retention.** When the relay expires a `msg` or `keys` entry it keeps the entry's `seq`, `prev` and the digest
-  `SHA-256(JCS(event))`, so the chain stays verifiable (`ConvLog.applyExpired`). Ops never expire: an op head that
-  names an expired entry is `conv_conflict`, so a relay that withholds an op as expired is caught by the next op.
+- **Device cuts.** A `rekey` with cause `device` ends the named device's authority in this conversation: later
+  entries by that device are invalid. If `until` is present, known entries by that device after `until` and before
+  the rekey are cut from state. An absent `until` makes no earlier cut. The position need not name that device's
+  entry: an expired message is a digest with no author or state effect. Replay collects the cuts, verifies every
+  chain link, and does not apply cut entries; a cut rekey cannot cut another device. A cut that removes genesis or
+  leaves later entries unauthorized is refused. A live verifier checks that the named device has been removed in
+  its verified realm. A cut never extends a removed device's authority. Several device rekeys may name one device:
+  an entry is cut when any of their cuts covers it. A daemon asked for a cut stricter than a rekey of the same device
+  it has queued or sent sends the stricter one too, ahead of anything else queued, before the call that drains it
+  returns: a queued rekey stands in for a request only when its cut is at least as strict.
+- **Retention.** Only `msg` entries expire. When the relay prunes a `msg` entry older than the conversation's
+  `retainDays` it keeps the entry's `seq`, `prev` and the digest `SHA-256(JCS(event))` and serves those
+  (`ConvExpiredEntry`), so the chain stays verifiable (`ConvLog.applyExpired`). **Ops never expire**: membership,
+  roles, epochs, settings, policy votes, sealed meta and the `self` conversation's settings are ops, so a member
+  that replays the log after pruning, or a joiner reading it from genesis, computes the same state as a member
+  that kept every body. The create (seq 1) never expires (`invalid_request`), and an op head that names an
+  expired entry is `conv_conflict`, so a relay that withholds an op as expired is caught by the next op. A key
+  share (§16.6) is not an entry; the relay deletes it after the retention.
 
 ### 16.5 Sender keys
 
@@ -3585,6 +3901,10 @@ raw value), `context {rules}` (§16.8), `localRetention {cid, days}` and `keys {
   of order it keeps at most `LIMITS.skippedKeys` (1000) derived but unused keys per (epoch, sender device),
   dropping the lowest indexes first; a message further than that past the chain is `too_large`, and one whose key
   is used or dropped is `not_found`. It keeps each share's chain key at the share's index, to share history (§16.6).
+- **Sealed ops.** A `meta` or `setting` op seals its content (`ConvMeta`, or a `SettingBody` of the op's `kind`)
+  the same way, under the author device's key at the op's (`epoch`, `idx`), with `aad = JCS(event without sig, the
+  op without sealed)`, so the AAD binds the op's kind and key index too. The plaintext is at most
+  `LIMITS.convPlaintextBytes`. A sealed op takes one index of the author's chain, as a message does.
 - **Epochs.** A `rekey` op starts the next epoch. Each sender then starts a new chain and shares it only with the
   devices of the participant persons at the rekey's `seq`.
 - Authenticity comes from the event signature, not from the key: a member who holds a sender key still cannot
@@ -3593,9 +3913,9 @@ raw value), `context {rules}` (§16.8), `localRetention {cid, days}` and `keys {
 
 ### 16.6 Key shares
 
-A `keys` event's body is `{shares: [{to: {person, device}, epk, nonce, ct}]}`, one entry per recipient device
-(at most `LIMITS.keySharesPerEvent` (500); a larger share is split over several events). Each `ct` seals
-`JCS({shares: [KeyShare]})`, where a `KeyShare` is `{epoch, device, idx, ck}` (at most `LIMITS.keyShares` (512)):
+A `keys` event goes to **one recipient device**. Its body is `{to: {person, device}, epk, nonce, ct}`; a sender
+sends one event per recipient device. `ct` seals `JCS({shares: [KeyShare]})`, where a `KeyShare` is `{epoch,
+device, idx, ck}` (at most `LIMITS.keyShares` (512)):
 
 1. Generate an ephemeral X25519 key pair; `epk` is its raw public key, `nonce` 12 random bytes.
 2. `shared = X25519(eph_priv, recipient.enc)`, the recipient device's key as the realm verified it (§4, §15.7).
@@ -3606,6 +3926,23 @@ A `keys` event's body is `{shares: [{to: {person, device}, epk, nonce, ct}]}`, o
 The AAD binds a share to its event and its recipient: moving it to another event or device makes it fail. A
 receiver keeps the first share for a given (epoch, device, idx); a later one with another key changes nothing.
 
+**Not an entry.** A `keys` event is not in the hash chain (`ConvLog.apply` refuses one, `invalid_request`). The
+relay keeps it for its recipient and serves it to no one else (`ConvShareEntry {n, event}`, §7): each device
+fetches only its own shares, so a rekey costs a device one share per sender, not every share of every sender. A
+recipient checks a share with `ConvLog.checkShare`, in the state at the share's `opHead`:
+
+1. I-JSON, size and the schema; the realm and the `cid` (`invalid_request`).
+2. The signature over the raw event (`bad_signature`).
+3. Live: `ts` within `LIMITS.clockSkewMs` (`expired`), and `by.device` a current device of `by.person`
+   (`unknown_device`).
+4. `by.agent` absent (`forbidden`); `opHead` names an op of the log (`conv_conflict`).
+5. At `opHead`, the author's person is a member participant person (`not_member`) and `to.person` a participant
+   person (`forbidden`); live, `to.device` a current device of `to.person` (`unknown_device`).
+
+The relay also requires `opHead` to be the current op head (§7), so no share reaches a device whose person was
+removed since. A relay that withholds a share is not hidden: the recipient cannot open that sender's messages,
+and shows that it waits for keys.
+
 ### 16.7 Authority
 
 `ConvLog.apply` checks each entry, in order, against the state after every earlier entry, and a failed check
@@ -3619,7 +3956,8 @@ changes nothing:
 5. `id` not already in the log (`duplicate`); `seen` before the event (`invalid_request`).
 6. The first entry is `create`, and there is only one (`conv_conflict`).
 7. For an `op`: `opHead` is the current op (`conv_conflict`); `by.agent` is absent: an agent never writes an op
-   (`forbidden`). For a `msg` or `keys`: `opHead` names an op of this log, or `{0, h(0)}` (`conv_conflict`).
+   (`forbidden`). For a `msg`: `opHead` names an op of this log, or `{0, h(0)}` (`conv_conflict`). A `keys` event
+   is never an entry (`invalid_request`, §16.6).
 8. The rules below. An author who is not a participant is `not_member`, one who lacks the authority `forbidden`, a
    target that is not a message of this log `not_found`, and a target in the wrong state `invalid_state`.
 
@@ -3639,6 +3977,9 @@ participant's.
 | `seat` | The target is an agent participant whose person is the author. It becomes `member`. |
 | `settings`, `archive` | A group or channel; the author is an admin. Only a channel has a visibility, and a public one needs an org (`invalid_state`). |
 | `rekey` | The author's person is a member participant person; `epoch` is the current one plus 1 (`invalid_request`). The cause is due (`invalid_state`), or is `device`, or is `schedule` and the epoch began at least `LIMITS.rekeyScheduleMs` (30 days) before. |
+| `policy` | Not in a `self` conversation. The author is a member; in a channel, an admin; in a dm or group, any participant person, as a vote. |
+| `meta` | A group or channel (never a dm or self); the author is a member, and in a channel an admin. Its `epoch` is the current epoch and no rekey is due (`stale_epoch`). |
+| `setting` | Only in a `self` conversation; the author is its person. Its `epoch` is the current epoch and no rekey is due (`stale_epoch`). |
 | any `msg` | The author's participant is a member; `epoch` is the current epoch and no rekey is due (`stale_epoch`). |
 | `line` | Not archived; an admin when `post` is `admins`. A guest may post. `thread` and `answers` name messages of the log. A line with `via` is a person's, never an agent's. |
 | `edit` | Not archived; the target is a line, not deleted, by the same participant (person and agent). |
@@ -3647,10 +3988,8 @@ participant's.
 | `pin` | Not archived; an admin when `pins` is `admins`; the target is not deleted; at most `LIMITS.pins` (100) pinned (`too_large`). |
 | `task` | A `request` as `line`, to a member agent participant (`not_found`). `status` and `artifact` from that agent; `cancel` and `followUp` from the requester. The root is a task request (`invalid_state`). |
 | `receipt` | The target is a message of the log. |
-| `meta` | Not in a dm; in a channel, an admin. |
-| `policy` | Not by an agent, and not in a `self` conversation. In a channel, an admin; in a dm or group, any participant person, as a vote. |
 | `sync` | Only in a `self` conversation, where no other body goes (`invalid_request`). |
-| `keys` | The author's person is a member participant person and `by.agent` is absent. Every share goes to a participant person (`forbidden`); live, to a current device of that person (`unknown_device`). |
+| `keys` | Not an entry: §16.6 (`ConvLog.checkShare`). |
 
 **State.** A participant starts as `member`, except an agent whose person is not the author (`invited` until its
 person seats it) and a `guest` (`invited` until they accept). Live, adding a person of another org as anything but a
@@ -3658,9 +3997,10 @@ guest is `forbidden`. A rekey is **due** after a removal or a leave (cause `remo
 and a change of the history policy (`settings`); a channel does not rekey on add. While a rekey is due, every `msg`
 is `stale_epoch`: no message is sealed under a key a removed device holds. A `rekey` clears every due cause.
 
-`ConvLog` keeps the state after every entry: `at(seq)` is the state of a log holding only entries 1 to `seq`. Ops
-and `policy` change it; the rules that read a message body (edit, delete, reactions, pins, tasks) run only when the
-caller passes the opened body, so the relay, which cannot open bodies, applies the header rules alone.
+`ConvLog` keeps the state after every entry: `at(seq)` is the state of a log holding only entries 1 to `seq`. Only
+ops change it, so the relay, which cannot open bodies, and a member whose message bodies expired compute the same
+state. The rules that read a message body (edit, delete, reactions, pins, tasks) run only when the caller passes
+the opened body.
 
 ### 16.8 Agents and history as context
 
@@ -3670,7 +4010,8 @@ policy decides whether members' agents may mine it at all.
 - **Policy** (`AgentContext`): `members` (members' agents may, each under its person's rules), `seats` (only
   agents seated in it, by their seats) or `none`. The default is `members`. In a channel an admin sets it with a
   `policy` body; in a dm or group each participant person votes, and the strictest vote counts (`none` <
-  `seats` < `members`). A person's vote goes when they leave.
+  `seats` < `members`). A person's vote goes when they leave. The policy is a `policy` op, in plaintext, so a joiner
+  that holds no earlier keys knows it too.
 - **Rules** (`ContextRule`): `{agent, scope, access, lookbackDays?}`, where `agent` is a session name or `*`,
   `scope` is `{cid}` or `{kind}` with `kind` one of `own`, `dm`, `group`, `channel.private` and
   `channel.public`, and `access` is `allow`, `ask` or `off`. A person holds at most `LIMITS.contextRules` (500),
@@ -3714,7 +4055,7 @@ policy decides whether members' agents may mine it at all.
 | `LIMITS.retainDaysDefault`, `LIMITS.retainDaysMax` | 90 days, 365 days |
 | `LIMITS.skippedKeys`, `LIMITS.chainMessages`, `LIMITS.chainMaxMs` | 1000, 500, 7 days |
 | `LIMITS.rekeyScheduleMs` | 30 days |
-| `LIMITS.keyShares`, `LIMITS.keySharesPerEvent` | 512 chain keys per share, 500 devices per `keys` event |
+| `LIMITS.keyShares` | 512 chain keys per share |
 | `LIMITS.wakeHints`, `LIMITS.contextRules` | 5, 500 |
 
 ### 16.10 Linked channels (reserved)
@@ -3727,8 +4068,8 @@ agents from a phone. The fields below are part of the schema and are validated,
   signed with the event, so every member sees it. Only a person writes it (`forbidden` on an agent's line, §16.7).
   The person's own devices also check it against the person's links (`checkVia`): a link of that channel, hosted by
   the authoring device, in force. Other members cannot see the links and do not check that.
-- **`link`**, a body of the person's `self` conversation: `{id, channel, account, host, proof, authority, linkedAt,
-  revokedAt?}`.
+- **`link`**, a setting of the person's `self` conversation (a sealed `setting` op of kind `link`, which never
+  expires): `{id, channel, account, host, proof, authority, linkedAt, revokedAt?}`.
   - `account` is the channel's id for the person's account; it is never in the device log, the directory or
     presence.
   - `host` is the device that runs the bridge.
@@ -3736,9 +4077,77 @@ agents from a phone. The fields below are part of the schema and are validated,
     person matched on both sides.
   - `authority` is a non-empty subset of `chat` and `view` (§8.11), and never more.
   - For each `id` the record written last is the one in force, unless it has `revokedAt` (`currentLinks`).
-- **`bridges`** in `policy`: who may mirror the conversation to a linked channel: `none` (the default), `admins` or
+- **`bridges`** in the `policy` op: who may mirror the conversation to a linked channel: `none` (the default), `admins` or
   `members`. In a channel an admin sets it. In a dm or group the strictest vote of the participant persons counts,
   and a person who has not voted counts as `none`, so bridging needs every participant person's vote.
 - **Reader ids** (`ReaderId`): a person, or `ext:<channel>:<link id>` for a link's channel provider. They are not on
   the wire; the audience guard's reader sets use them.
 - A foreign sender on a bridged channel (`via.sender`) is not part of v1: the schema refuses it.
+
+### 16.11 Same-realm contact request cut-over
+
+This profile replaces the first-message import rules of §6.9 for conversation DMs. It does not introduce cross-realm addresses.
+The normative shapes are in `schema/contact-request.ts`. The request plaintext uses `RequestImport`, separate from the ordinary `MsgBody` parser.
+The cut-over engine uses `openRequestImport` and `applyRequestEntry` for this profile. Source attribution comes from verified request evidence, never the wrapper author.
+
+**Portable source proof.** A new request contains a sender-signed descriptor and a sealed opening:
+
+- The descriptor binds `v`, `realm`, `cid`, `from`, `to`, `id`, `issuedAt`, `expiresAt`, `commitment` and `by`.
+- The sender signs its raw JCS bytes without `sig`, under `DOMAIN.request` (`messaging/1/contact-request\n`).
+- The opening contains a fresh random 256-bit `salt` and 1–500 UTF-16 code units of `text`.
+- The commitment is SHA-256 of `DOMAIN.requestContent` and JCS of the opening.
+- The descriptor digest is SHA-256 of `DOMAIN.requestDigest` and JCS of the signed descriptor.
+- Both device signatures require bindings from retained, verified identity history. An absent binding fails closed.
+
+The request names the deterministic DM of two distinct persons. The consent window cannot exceed `LIMITS.ttlMs`.
+Every device copy carries the same descriptor and opening. Only sealed envelopes carry the opening before acceptance.
+Requests expose no agent address, task, mention, attachment, context-index entry or wake hint.
+The envelope payload has `conv: {kind: "request", proof: PortableRequest}`. Its one text part and message ID match the signed opening and request ID.
+The envelope has human ends, class `request`, and the descriptor's expiry. The cut-over handler rejects a payload without `proof` and asks for resend.
+The optional field in the stored payload schema permits reading retained old records. It does not authorize old plaintext for a conversation import.
+
+**Terminal decision.** The recipient signs `RequestDecision` under `DOMAIN.requestDecision` (`messaging/1/contact-request-decision\n`).
+The decision binds the descriptor digest, request ID, realm, DM, both persons, answer and decision time.
+The answer is `accept` or `decline`. A local block sends `decline` and keeps the blocking grant private.
+The decision time must be within the original consent window. Retries preserve the signed decision and its timestamp.
+
+`request.settle {req, descriptor, decision}` stores the first valid terminal decision in the recipient mailbox.
+Only the connected recipient device can submit its own signed decision. A later conflicting decision returns the first decision.
+`request.state {req, descriptor}` returns that decision to either named person, or no decision before settlement.
+Both frames answer `request.settled {req, id, decision?}`. They expose neither salt nor text to the relay.
+Relay schema 3 adds `conv_request_decisions`. Generation stays 2 and the minimum reader stays 1.
+Relay schema 4 adds `dir_wake_dms` (§7, "Wake tickets"; §15). Generation stays 2 and the minimum reader stays 1.
+
+**Permanent activation.** An external human DM declares `create.admission: "request"`.
+The relay refuses an external DM without this declaration. Same-org DMs retain implicit org admission.
+Before activation, content and key shares fail with `request_required`. The recipient appends `activate {proof: {descriptor, decision}}` after mailbox reconciliation.
+Device-removal rekeys can precede activation. They still require the normal removed-device and log-authority checks, and grant no content access.
+The activation is a permanent op. It reserves the request ID for exactly one import.
+
+The recipient seals `RequestImport {t: "request.import", descriptor, decision, opening}` under its conversation sender key.
+The wrapper has `id` and `request` equal to the reserved request ID. It has no agent author or wake hint.
+Members verify both proofs and the opening before they attribute text to the original sender.
+The recipient then appends `request.complete {request, seq, digest}`. The digest is SHA-256 of JCS of the exact imported event.
+This permanent completion survives deletion and retention. Ordinary messages wait until all accepted reservations have completed imports.
+
+Duplicate importers fetch the winning event and verify its exact proofs and opening. A different body at the same ID is a conflict.
+The source sender need not be online. Crossed requests use one DM but keep separate IDs, answers and imports.
+The import is immutable. Only its original sender can delete its text. The wrapper author gains no source-author permissions.
+After retention, members verify the permanent activation and completion without reconstructing text.
+
+**Existing contacts.** Each person signs a conversation-bound `ContactAuthorization` under `DOMAIN.contactAuthorization`.
+An activation with `proof.contacts` requires both reciprocal signatures. The daemon signs only under an existing open or muted chat grant.
+This path needs no new human prompt and imports no request text. A contact card cannot substitute for either signature.
+
+**Durable local lifecycle.** `ConversationRequests` stores each request and its state in namespaced rows of the existing `kv` table.
+Queued sends, submitted requests, decisions and imports survive restart. `waitingOnThem()` exposes only explicit submitted requests, not missing receipts.
+Acceptance opens only chat. A later block prevents local import and key use even after permanent activation.
+The sender receives the same error for an unknown or undiscoverable exact email.
+
+Old pending requests retain their local records and expose `resend`. The sender must send a new request with portable evidence.
+On the sender's side, a request sent before the cut-over that the recipient's device held for its person and nobody
+answered (its chat envelope still `sent`, held and unexpired) appears in `request.waiting` with state `resend`, until
+it lapses (`LIMITS.ttlMs` after it was sent) or a new request to that person replaces it. Nothing is sent for it:
+resending signs a new request, which needs the person's own send. A request still in flight before the cut-over,
+not yet held, cannot be told from a chat line and is not shown.
+The cut-over never signs old plaintext for its sender or silently resends it.