@joe-broadhead/messaging 0.7.0 → 0.8.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.
@@ -16,8 +79,8 @@ other, exchange messages, and delegate A2A tasks, through a relay that only sees
   (`urn:messaging:binding:relay:v1`), presence and session addressing, delivery receipts, and the
   extensions `urn:messaging:ext:provenance:v1` and `urn:messaging:ext:presence:v1`.
 
-Not in v1: hole-punched peer-to-peer transport, federation between relays, payments, and group
-(multicast) encryption.
+Not in v1: hole-punched peer-to-peer transport, federation between relays, and payments. Conversations
+(§16) encrypt to many members with sender keys; MLS is left to a later protocol version.
 
 ## 2. Encodings
 
@@ -54,8 +117,12 @@ Not in v1: hole-punched peer-to-peer transport, federation between relays, payme
   `messaging/1/invite\n`, `messaging/1/invite-join\n`, `messaging/1/delegation\n`, `messaging/1/grant\n`,
   `messaging/1/card\n`, and for hosted realms (§15) the person hash prefix
   `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`). A signature or hash for
-  one purpose never verifies for another.
+  `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`, 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
@@ -474,7 +541,8 @@ 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"` and `"conversations"` (the daemon reads conversation
+  logs; `conv.caps` reads it at the relay). 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
@@ -540,7 +608,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`.
@@ -574,107 +642,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.
 
@@ -693,7 +680,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 },
   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
@@ -705,8 +692,8 @@ 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.
+  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.
@@ -741,7 +728,7 @@ 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;
+2. otherwise, for `ask` and `agentMail`, the most permissive grant of a verified conversation shared with S;
 3. otherwise the default for the relation:
 
 | Relation | `chat` | `agentMail` | `ask` | trust |
@@ -766,7 +753,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
@@ -823,40 +810,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
@@ -867,14 +841,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
@@ -1259,14 +1226,22 @@ Jelly ID, which wakes the host.
   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 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), 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
@@ -1291,6 +1266,72 @@ Jelly ID, which wakes the host.
   names them), and the ids of the task requests it awaits (envelope ids it already routed). 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}`: 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.
+- **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.
@@ -1354,6 +1395,30 @@ 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` and `gap`.
+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` and `pending-delivery`.
+The daemon re-reads verified state before it sends a projection.
+
+**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 restart or expired replay position produces a gap. Clients then reload their accessible conversations.
+`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.
@@ -1366,8 +1431,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.
@@ -1421,7 +1486,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
@@ -1430,23 +1495,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.*`,
+    `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.*`,
     `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`,
+    `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`, `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`
+    `contact.request.preview`, `card.get`, `sessions.list`, `request.waiting`,
+    `notice.subscribe`, `notice.list`, `notice.ack`, `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`,
@@ -1561,12 +1628,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.
@@ -1607,24 +1670,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.
@@ -1650,14 +1703,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;
@@ -1680,101 +1731,40 @@ sockets in `$MESSAGING_HOME/run/`. For a method this section does not describe (
 - **`task.cancel`** is allowed only for the requester.
 - **`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.
   - `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
@@ -1842,27 +1832,12 @@ 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>`.
+  - `message`: a retained legacy notice, without transcript text. Live conversation updates use the conversation stream.
+  - `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,13 +1862,11 @@ sockets in `$MESSAGING_HOME/run/`. For a method this section does not describe (
     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 "…".
+    `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.
@@ -1928,8 +1901,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
@@ -1938,9 +1910,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).
@@ -1953,6 +1923,21 @@ 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.
+  - 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
@@ -2035,8 +2020,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
@@ -2075,29 +2060,62 @@ 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
-(`messaging-relay` logs it as `relay.store_refused {db, reason}` and exits 1). 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
+**reasons**, and the remedy depends on it:
+
+| Reason | The store | Remedy |
+|---|---|---|
+| `pre-reset` | records no store generation, or another generation than the reader's | Start over: move the home (or the relay database) aside and set it up again. |
+| `newer` | its `min_reader` is above the reader's schema: a newer messagingd or relay wrote it | Upgrade the daemon or relay, and keep the home or database as it is. Never move it aside for this reason. |
+
+- `messagingd` exits with status **78** (`EX_CONFIG` of sysexits(3); `STORE_REFUSED_EXIT` in `@messaging/core`)
+  for either reason, and prints one line on stderr, `messagingd: store_refused: <reason>: <why, and what to do>`.
+  No other failure exits 78.
+- `messaging-relay` exits 78 and logs one JSON event, `relay.store_refused {db, reason, message}`: `reason` is
+  `pre-reset` or `newer`, and `message` is the text.
+- A client that starts the daemon and sees it exit 78 reports the error code `store_refused` (§13), with the reason
+  in a field of its own (`StoreRefusedError.reason`; `reason` in `messaging --json` errors and in agent tool
+  errors). It reads the reason from the two tokens after `messagingd:` on the line that start printed
+  (`storeRefusedReason` in `@messaging/core`) and never parses the text after them, which may change between
+  releases. A line without a reason token gives `store_refused` without a reason. `messaging daemon start` does
+  this.
+- A client offers to start over (moving the home aside) **only for `pre-reset`**. For `newer`, and for a refusal
+  without a reason, it tells the person to upgrade or to read messagingd's line, and moves nothing.
+- A home moved aside is named `<home>.pre-reset-<UTC timestamp>`, the timestamp as `YYYYMMDDTHHMMSSZ` (for example
+  `~/.messaging.pre-reset-20261108T171500Z`). The name carries no version, so it holds for every reset, and a
+  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.
+
 **When stores grow.**
 
 - A daemon or relay opens any store of its generation whose `min_reader` is at most its own schema. It
@@ -2111,10 +2129,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`.
 
@@ -2231,9 +2252,9 @@ and names each session an engine may register.
   - `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`, `request.list`, `sessions.list`, `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
@@ -2247,8 +2268,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
@@ -2319,6 +2340,10 @@ callers rely on.
   It answers from what this machine has verified, synchronously; a caller catches up before it
   verifies. `Roster` implements it: `realm` is the team id, `device` is `member`, `anchor()` is
   `rosterAnchor`.
+- Conversations (§16): `checkVia`, `currentLinks`, `signConvEvent`, `verifyConvEvent`, `sealConvMsg`, `openConvMsg`, `sealConvMeta`,
+  `openConvMeta`, `sealKeyShares`, `openKeyShares`, `ConvLog.apply`, `ConvLog.applyExpired`, `ConvLog.relate`
+  and `resolveContext` throw only `MessagingError`. `ConvLog.at(seq)` is the state a log holding only entries 1
+  to `seq` has. `ReceiverChains.messageKey` hands out each message key once.
 - `createGrant` narrows its parent and never widens it (`forbidden`); an expired parent is `expired`.
 - Consent (§6.9): `signConsentGrant` refuses a grant that breaks a rule (`invalid_request`) or is
   over `LIMITS.grantBytes` (`too_large`); `verifyConsentGrant` checks the schema, the rules, the
@@ -2470,30 +2495,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
@@ -2503,28 +2536,21 @@ 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`.
 - **`task_update`** (executor) and **`task_cancel`** (requester) map to `task.update` and
@@ -2563,12 +2589,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
@@ -2592,16 +2618,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.
@@ -2738,7 +2758,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.
@@ -2783,6 +2803,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 |
@@ -2795,6 +2819,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 |
@@ -2808,10 +2833,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 |
+| 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) |
 | admission_invalid | `dir.bind` whose Jelly token is not live now, or not for this directory's issuer, resource and person (§15.10) |
@@ -2826,6 +2853,7 @@ contacts, changes devices or administers a team or channel.
 | 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 |
 | daemon_mismatch | the daemon on the socket is another release or IPC protocol than the client, or did not say which (§8.2) |
+| store_refused | messagingd refused the home's store and changed nothing; it exits 78 (§8.8). Its `reason` field says why: `pre-reset` (no or another store generation: start over by moving the home aside) or `newer` (a `min_reader` above its schema: upgrade, keep the home); absent when messagingd named none. A client code: a client that starts the daemon reports it, never the daemon over IPC |
 | internal | unexpected failure (details stay in local logs) |
 
 ## 14. Versioning
@@ -3327,11 +3355,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.
 
@@ -3424,3 +3450,432 @@ five minutes, until it answers, so a new directory becomes ready without waiting
 `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
 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 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
+
+- A **participant** (`ParticipantId`) is a person (§3, §15.1) or one agent of a person: `person/agent`, where
+  `agent` is a session name (§3). Every agent belongs to one person, its **person**.
+- A conversation id (`ConvId`) is one of:
+  - a **dm**: `"d_" + base32lower(SHA-256("messaging/1/dm\n" || JCS([a, b] sorted)))[0..26]`, where `a` and `b`
+    are its two participants, sorted by UTF-16 code units. Both ends derive the same id. `a` may equal `b`: a
+    person's note to themselves.
+  - a person's **self** conversation: `"s_" + base32lower(SHA-256("messaging/1/self\n" || JCS(person)))[0..26]`.
+  - a **group** or **channel**: `"c_"` and a ULID its creator chooses.
+
+  base32lower is RFC 4648 §6 in lower case without padding, as for `PersonId` (§15.1).
+- Kinds (`ConvKind`): `dm`, `group`, `channel` and `self`. Only a channel has a visibility (`public` or
+  `private`). The history policy (`none` or `shared`) says whether a late joiner may read earlier messages.
+- Roles (`ConvRole`): `owner`, `admin`, `member` and `guest`. A participant's state is `member`, or `invited`
+  until it accepts or is seated (§16.7).
+
+### 16.2 Events and the log
+
+Every event has a header and a body. The header is:
+
+```text
+{v: "messaging/1", realm, cid, id, by: {person, device, agent?}, ts, opHead: {seq, hash}, seen?: {seq, hash},
+ class, epoch?, idx?, wake?}
+```
+
+- `id` is a ULID the author chooses. It is unique in the conversation: the log refuses an event whose `id` it
+  already holds (`duplicate`). Other events refer to an event by `id`.
+- `by` names the signing device, its person and, for an agent's event, the agent. `by.device` must be a usable
+  Ed25519 key (§3).
+- `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 (`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. 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}` 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`, `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,
+  device?, respondTo?}`, the permits `post`, `invite` and `pins` (`all` or `admins`; absent is `all`), and
+  `sealedMeta` (§16.5).
+- `add` names 1 to `LIMITS.convOpParticipants` (100) seats; `remove` names as many participants.
+- `seat` sets an agent participant's `device` (the device that hosts it) and `respondTo` (`self`, `members` or
+  `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`. 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
+
+The plaintext of a `msg` event is one `MsgBody`, at most `LIMITS.convPlaintextBytes` (64 KiB) of JCS
+(`too_large`):
+
+- `line`: `text` (at most `LIMITS.lineChars` (40,000) UTF-16 code units), `format` (`plain` or `md`), and
+  optionally `thread` (the root's event id), `broadcast`, `mentions` (at most `LIMITS.mentions` (50)), `files`
+  (at most `LIMITS.files` (10) attachments), `parts` (up to 8 A2A data parts), `answers` (the mention it answers)
+  `grants` (at most `LIMITS.agentMentions` (5) delegation grants, §6.7) and `via` (§16.10).
+- `edit {target, text, mentions?}`, `delete {target}`, `react {target, key, on}` and `pin {target, on}`.
+- `task {task}`: a task as a thread. `request {to, message, delegation}` is the root, to an agent participant;
+  `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`.
+- `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`.
+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
+
+- `h(0) = SHA-256("messaging/1/conv-genesis\n" || JCS(cid))`.
+- `h(seq) = SHA-256(h(seq − 1) || SHA-256(JCS(event)))`, over the raw 32-byte digests.
+- A member checks `prev = h(seq − 1)` and the signature over the raw received event before it reads any field.
+- **Gossip.** A member compares an event's `seen` with its own log (`ConvLog.relate`): `ahead` past its head (it
+  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`.
+- **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.
+- **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
+
+- **Chains.** A sender device keeps one chain per (conversation, epoch). From a chain key `ck_i`:
+  - the message key `mk_i = HKDF-SHA256(ikm = ck_i, salt = empty, info = "messaging/1/conv-msg", 32 bytes)`;
+  - the next chain key `ck_{i+1} = HKDF-SHA256(ikm = ck_i, salt = empty, info = "messaging/1/conv-chain", 32
+    bytes)`.
+
+  The first chain of an epoch starts at index 0 from 32 random bytes.
+- **Sealing a body.** `body = base64url(nonce || AES-256-GCM(mk_idx, nonce, JCS(MsgBody), aad = JCS(header)))`,
+  with a fresh 12-byte nonce and the 16-byte tag last; the header is the event without `body` and `sig`. The
+  event's `epoch` and `idx` name the key. A message key seals one body only.
+- **Sealed meta.** `create.sealedMeta` is `JCS({name?, topic?, purpose?})` sealed the same way under the creator
+  device's epoch-0 key `mk_0`, with the create event's header as AAD. The creator's first message uses index 1.
+- **Rotation.** A sender starts a new chain in the same epoch after `LIMITS.chainMessages` (500) messages on one
+  chain, or `LIMITS.chainMaxMs` (7 days) after starting it. The new chain starts from fresh random bytes at the
+  next index, so `(epoch, device, idx)` names every key: the share with the greatest index at or below `idx`
+  derives it.
+- **Receiving.** A receiver derives forward only and uses each message key once. To open messages that arrive out
+  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
+  write as another member. Within an epoch there is no post-compromise security: a copy of a device's state reads
+  every chain it held until the next rotation or epoch.
+
+### 16.6 Key shares
+
+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).
+3. `key = HKDF-SHA256(ikm = shared, salt = epk || recipient.enc, info = "messaging/1/seal", 32 bytes)`, as for
+   an envelope (§5, "Sealing").
+4. `ct = AES-256-GCM(key, nonce, JCS({shares}), aad = JCS({header, to}))`, with the tag last.
+
+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
+changes nothing:
+
+1. I-JSON (§2, `invalid_request`) and size (`too_large`); the schema, the realm and the `cid` (`invalid_request`).
+2. The chain: `seq = head + 1` and `prev = h(head)` (`conv_conflict`).
+3. The signature over the raw event (`bad_signature`).
+4. When appending live (the relay, or a member checking a pushed event): `ts` within `LIMITS.clockSkewMs` of now
+   (`expired`), and `by.device` a current device of `by.person` in the realm (`unknown_device`).
+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`: `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`.
+
+A participant **person** is the person of any participant, so the devices of a person whose agent sits in a
+conversation append its keys and rekeys. "Admin" below means `owner` or `admin`; an author's role is its own
+participant's.
+
+| Event | Allowed when |
+|---|---|
+| `create` | A **dm**: exactly two seats, both `member`, no visibility, org, permits or meta, history `none`, `cid` the derived one, and the author is the person of one seat. A **self**: one seat, the author as `owner`, `cid` the author's, history `shared`. A **group**: 3 to `LIMITS.groupParticipants` (50) distinct seats, no visibility or org. A **channel**: a visibility, and an org if public, at most `LIMITS.convParticipants` (1000) seats. In a group or channel the author is a seat as `owner`. |
+| `add` | A group or channel (never a dm or self). The author is a member, not a guest, and an admin when `invite` is `admins`. No seat is a current participant; only an owner adds an owner or an admin; the kind's limit holds (`too_large`). |
+| `accept` | The author's own participant is `invited`. |
+| `join` | A public channel the author is not in; live, the author's person is in the channel's org. |
+| `leave` | A group or channel; the author is a participant. Their agents leave with them. The last owner cannot leave while another person remains. |
+| `remove` | A group or channel. The author is an admin, and an admin never removes an owner; or the target is the author's own agent (whether or not the author is a participant). Removing a person removes their agents. The last owner cannot be removed. |
+| `role` | A group or channel. The author is an owner, or an admin setting `member` or `guest` on a participant who is not an owner. The last owner cannot be demoted. |
+| `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). |
+| `delete` | The target is a line or a task event, not deleted, and the author wrote it or is an admin. |
+| `react` | As `line`; the target is not deleted; at most `LIMITS.reactionsPerEvent` (50) keys per target (`too_large`). |
+| `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. |
+| `sync` | Only in a `self` conversation, where no other body goes (`invalid_request`). |
+| `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
+guest is `forbidden`. A rekey is **due** after a removal or a leave (cause `removed`), an add to a group (`added`),
+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`. 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
+
+A person decides which of their agents may mine which of their conversations as context, and a conversation's
+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. 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),
+  one per (agent, scope), synced in their `self` conversation. A conversation is `own` when its participant persons
+  are the person alone.
+- **Resolution** (`resolveContext`) for agent A of person P reading conversation C as context:
+  1. a `self` conversation is never mined;
+  2. C's policy `seats` or `none` forbids the read, whatever P's rules say;
+  3. else the most specific rule of P applies (a `cid` scope over a `kind` scope, then A by name over `*`), or
+     with none, the default for C's scope:
+
+     | Scope | Access | Lookback |
+     |---|---|---|
+     | `own` | `allow` | the retention |
+     | `channel.public` | `allow` | 90 days |
+     | `channel.private` | `ask` | 30 days |
+     | `group` | `ask` | 30 days |
+     | `dm` | `ask` | 14 days |
+
+     `off` forbids, `ask` holds the read for P to answer, `allow` serves it;
+  4. the lookback is the smallest of the rule's (or default's) lookback, C's `retainDays` and P's local
+     retention for C.
+- An agent seated in C reads C from its seat by its seat, not by P's rules, unless C's policy is `none`; then it
+  reads only what is addressed to it and the threads that is in (`seatReads`).
+- Agents of every client follow these rules, MCP clients included; each daemon enforces them for its own person's
+  agents.
+
+### 16.9 Limits
+
+| Limit | Value |
+|---|---|
+| `LIMITS.convParticipants` | 1000 participants (persons and agents) in a channel |
+| `LIMITS.groupParticipants` | 50 in a group |
+| `LIMITS.convOpParticipants` | 100 per `add` or `remove` |
+| `LIMITS.convEventBytes` | 256 KiB per event |
+| `LIMITS.convPlaintextBytes` | 64 KiB per message body |
+| `LIMITS.lineChars` | 40,000 UTF-16 code units |
+| `LIMITS.mentions`, `LIMITS.files`, `LIMITS.agentMentions` | 50, 10 and 5 per line |
+| `LIMITS.blobBytes` | 25 MiB per file |
+| `LIMITS.reactionsPerEvent`, `LIMITS.pins` | 50 keys per target, 100 pins per conversation |
+| `LIMITS.retainDaysDefault`, `LIMITS.retainDaysMax` | 90 days, 365 days |
+| `LIMITS.skippedKeys`, `LIMITS.chainMessages`, `LIMITS.chainMaxMs` | 1000, 500, 7 days |
+| `LIMITS.rekeyScheduleMs` | 30 days |
+| `LIMITS.keyShares` | 512 chain keys per share |
+| `LIMITS.wakeHints`, `LIMITS.contextRules` | 5, 500 |
+
+### 16.10 Linked channels (reserved)
+
+A person may link an outside chat account (Telegram, then Slack) as an alias of themselves, to reach their own
+agents from a phone. The fields below are part of the schema and are validated, but no daemon acts on them yet;
+`docs/design/conversations.md` §17 describes the plan.
+
+- **`via {channel}`** on a `line`: the person wrote it from a linked channel, `telegram` or `slack`. It is sealed and
+  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 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.
+  - `proof` is `{method: "code-sas", codeDigest, sas}`: the digest of the one-time code and the six-digit code the
+    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 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.
+
+**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.
+The cut-over never signs old plaintext for its sender or silently resends it.