@joe-broadhead/messaging 0.7.1 → 0.9.0

package/CHANGELOG.md

@@ -6,6 +6,368 @@ Versions follow [Semantic Versioning](https://semver.org); see
 
 ## [Unreleased]
 
+## [0.9.0] - 2026-11-11
+
+**What Jelly asked for in opencode-messaging #17, #18, #19 and #24.** The person sees their agents' tasks as a view
+(who does the task, for whom, a sign-in it waits on, why it was refused) and stops one with a source-issued action.
+Inbound tasks become notices. A resting Jelly host wakes for a teammate's dm. The person answers two questions about
+who may reach them. The 0.8.0 follow-ups for mixed versions, the `conv.caps` presence oracle and the control-op drain
+are here too.
+
+**Upgrade the relay, then the daemons, in any order after it.** 0.9.0 and 0.8.0 daemons interoperate (below). Stores
+only grow: the daemon store goes to schema 5 and the relay database to schema 4, and a rollback keeps the data.
+
+### Compatibility
+
+- **0.9.0 and 0.8.0 daemons interoperate** (spec §8.3). Nothing on the wire between daemons was removed or tightened.
+  - Conversations, message requests and tasks work in both directions. Both releases advertise the
+    `conversations` feature that `conv.caps` checks, so neither answers the other with `peer_outdated`.
+  - A 0.9.0 executor's sign-in names its tool in the task status as A2A extension data
+    (`metadata["urn:messaging:ext:sign-in:v1"]`, spec §6.2, "Sign-in"). A 0.8.0 requester still reads a valid status
+    and its text.
+  - A 0.9.0 device advertises the new presence feature `reach` (spec §6.5). A 0.8.0 device does not, and **does not
+    enforce the reach choices** (spec §6.9, "Older daemons do not enforce the choices"). A relation grant synced to a
+    0.8.0 device of the same person is skipped there (`grant.sync.skipped`), and it keeps working.
+- **dm wakes need the relay at 0.9.0** (relay schema 4). A 0.8.0 relay parses `wake.arm` without `dms` and still arms
+  the host's agents and awaited tasks, so a 0.9.0 host behind it arms no dm and wakes as before. A 0.8.0 daemon never
+  sends `dms`, and a 0.9.0 relay arms it as before.
+- **A 0.8.0 daemon behind a 0.9.0 relay** gets the new optional `unknown` in a `conv.caps` answer only over the new
+  budget (below). It cannot parse that answer and goes ahead without one, as 0.8.0 already did when `conv.caps` was
+  refused.
+- **Rollback keeps the data.** Daemon schema 5 and relay schema 4 are additive, with generation 2 and `min_reader` 1,
+  so 0.8.0 opens both. A 0.8.0 daemon ignores the reach tables and does not enforce the choices; a 0.8.0 relay
+  ignores `dir_wake_dms`, and the rows it leaves name a ticket that no longer counts.
+
+### Added
+
+- **The task view (#17)** (spec §8.2, "The task view"). Every `TaskRecord` the daemon projects carries fields it
+  computes and never stores or sends:
+  - `agent`, the counterpart session; `person: {id, name}`, verified by the realm, never parsed from an agent's name;
+    `org` (`same`, `other` or `none`);
+  - `signIn: {tool?, by}` in `AUTH_REQUIRED`, where `by` (`you` or `them`) is computed by the viewer's own daemon and
+    never read from the peer. An executor names the tool with `task.update {signIn: {tool}}`;
+  - `refusal: {reason}` in `REJECTED`.
+  - `tool` and `reason` come only from the executor itself, through `cleanPeerText`, capped at
+    `TASK_SIGN_IN_TOOL_CHARS` and `TASK_REFUSAL_CHARS`. Agent tools show them fenced when the peer wrote them.
+- **Task notices (#18)** (spec §8.2, "Notices"). A task another person's agent asked of one of this person's agents
+  files a `message` notice with `key: "task:<task id>"` when this device accepts it. It copies no text and is never a
+  `request`. An ask held for consent stays a `request` until its person answers. A task between the person's own
+  agents files none.
+- **dm wakes (#19)** (spec §7 and §8.11, "Wake tickets").
+  - `wake.arm` takes `dms`, at most `WAKE_DMS` (256). The relay presents the ticket for a line in an armed dm by its
+    other person while the host is offline, within the existing budget (1 a minute, 6 an hour, 48 a day).
+  - The daemon arms the verified dms whose other person shares a channel with this person as a member, and returns
+    their count (`dms`). It never arms a person this person blocked or muted, or one their reach choices hide.
+  - It reads the candidates' directory views in batches (`LIMITS.dirLookupPersons` to a lookup) before it decides.
+  - The list is what held at the arm: a block while the host sleeps applies at the next arm, so at most one wake.
+  - Neither side logs a dm's id. The relay can't tell a line from other sealed events in an armed dm, so a reaction or
+    edit there may also wake the host, within the budget.
+- **Consent choices (#24)** (spec §6.9, "Reach choices").
+  - `reach.get`, `reach.set {revision, changes}` and `reach.set.preview`, on the human tier only. "Who can message
+    you" is Open, Ask me first (the default) or Never for people outside the org. "How agents may ask yours" is Open,
+    Ask me first or Never for the org's agents.
+  - Each choice is the person's own signed grant on a relation subject (`{relation: "outside" | "org"}`). A grant for
+    one person or conversation wins over it.
+  - A stale `revision` is the new error `conflict`, and nothing changes.
+  - Under Never, an outsider whose person grant sets no `chat` is refused, and their lines are hidden in existing
+    conversations at read time. Choosing again shows them. The org, the person's own lines and outsiders' agents are
+    never hidden. A person the realm no longer knows stays visible.
+  - CLI: `messaging reach`.
+- **Action tokens** (spec §8.2, "Action tokens"; design §12.5).
+  - On the human tier the daemon puts `{name, token}` on what it renders: `actions` on every `request.list` item, one
+    per answer its kind takes, and `cancel` on a task this person's agent asked that has not ended. The executor side
+    never gets `cancel`.
+  - A token binds the action, the item and the view: the admin connection, and under a Jelly host the grant's `dev`
+    and `mbr`. It is spent at its first presentation, matched or not, and lives 10 minutes. At most 256 are held per
+    view and 4,096 in all. They are in memory only, so a restart invalidates every one.
+  - A token is never logged or printed, and the agent tier never receives one or redeems one.
+  - `request.answer` and `request.answer.preview` take `token`, never with `all`. Under a Jelly host `request.answer`
+    requires it. `task.cancel` takes exactly one of `key` (the requester session) and `token` (the person, human
+    tier). A preview checks a token without spending it. Every failure is `grant_invalid`.
+- **The person's tasks, and Stop** (spec §8.2, "The person's tasks").
+  - `tasks.list` and `tasks.get`, on the admin socket with no session key, Jelly class `view`, read every side of a
+    task this device's sessions hold, as `PersonTask`. That is the task view as the owner sees it, the agent's
+    `session` name and never its key, and `cancel`, which stops the task through `task.cancel {taskId, token}`.
+  - A person-level `conv.sync` carries `task` entries, rendered for each reader. Task changes share the replay
+    buffer with conversation changes.
+  - Only this device's tasks are listed.
+- **`task.question`** (spec §8.2, "The task view").
+  - On the agent tier, from the executing session only. It ties a task in `AUTH_REQUIRED` or `INPUT_REQUIRED` to the
+    host's own pending approval or question, `{sessionId, approvalId}`.
+  - It is held in memory only and untied by any later status. It is shown only on the person's own reads, never on
+    the agent tier, in an event, or to the peer.
+  - When the session registered a host session, `sessionId` must be that one (`forbidden`).
+- **The `reach` presence feature** (spec §6.5): a device that enforces the reach choices says so.
+- **`device.list` features** (spec §8.2, "Devices"). Each of the person's own devices lists the presence features last
+  verified from it. They are absent when none was seen, which means unknown, not none.
+- **`request.waiting` states `resend` and `outdated`** (spec §8.2, §8.3 "Mixed versions").
+  - `resend`: a message request sent from 0.7.1 that its recipient held and nobody answered is shown, not re-signed
+    or resent. A request still in flight at the upgrade can't be told from a line and is not shown.
+  - `outdated`: a request whose recipient device answered with a `delivered` receipt, which only an older client sends
+    on accepting. It must be sent again once they update.
+
+### Fixed
+
+- **Presence for people who only talk in conversations** (spec §15.10). The presence audience, and the relation
+  `conv.caps` uses, counts accepted members of one conversation the relay sequences: an external dm only once
+  activated, never an invited participant. A cross-org contact no longer drops out of presence 30 days after their
+  last envelope.
+- **A control op no longer fails with a spurious `conv_conflict`** when maintenance queues a share while it drains. It
+  drains until nothing is pending, up to 3 drains. A conversation that refills on every drain is `conv_conflict`, "the
+  conversation is busy sending; try again", which can be retried as is (spec §13).
+
+### Security
+
+- **The engine always sends the strictest cut asked for a removed device** (spec §16.4, "Device cuts"). This was
+  an ordering bug in the daemon's conversation engine, present since 0.8.0, that no 0.8.0 IPC call could reach.
+  - Asked to rekey a device with an earlier `until` while a weaker rekey of that device was already queued or in
+    flight, the engine returned the queued one and dropped the earlier cut.
+  - No IPC method passes `until`, the engine isn't part of the package's exports, and the daemon's automatic rekeys
+    after a removal never ask for a stricter cut than the one they queue.
+  - Fixed and guarded by tests:
+    - a queued rekey stands in only when its cut is at least as strict;
+    - two cuts of one device combine as a union in the verifier;
+    - a cut covers the device's held entries.
+- **`conv.caps` is no longer a free presence oracle** (spec §7). Answers about unrelated persons count against
+  `LIMITS.requestsPerDay` (20) distinct persons per asking person per UTC day, shared by that person's devices.
+  Related persons, and persons already asked about that day, are always answered. Past the budget the answer names
+  the rest in `unknown`, and `peer_outdated` still applies to anyone named `outdated`.
+- **A token answers only what it was offered for.** A forged, spent, expired, dropped or mismatched token, or one
+  from another view or an earlier start, does nothing. Under a Jelly host a call that carries a token needs an action
+  grant, even for an agent-tier method.
+- **Action tokens and the question association never leave the person's own clients**, and neither is ever logged.
+
+### Stores
+
+**Stores only grow** (spec §8.8). Generation stays 2 and `min_reader` stays 1.
+
+- **Daemon store, schema 5** (`packages/daemon/store-schemas/5.json`) adds `reach_grants` and `reach_reviews`: the
+  reach choices, apart from `grants`. A daemon before schema 5 would delete a `grants` row it cannot parse, so it
+  ignores these tables instead.
+- **Relay database, schema 4** (`packages/relay/store-schemas/4.json`) adds `dir_wake_dms` and an index on `exp`. A
+  row counts only with its ticket's `exp`, and goes with it.
+- Action tokens and the question association add no table: they are held in memory only.
+
+### Tests
+
+- Each new check has a test that goes red when the check is removed: the token bindings, single use, expiry,
+  restart, tier and log; the executor never gets `cancel`; Never in existing conversations; the arm's block, mute and
+  reach rules; the expiry purge of armed dms; the question on one device holding both sides of a task.
+- The mixed-version e2e with message requests runs in both realms against `@joe-broadhead/messaging@0.7.1` when
+  `MESSAGING_E2E_OLD` is set. The gates skip it.
+
+## [0.8.0] - 2026-11-10
+
+**Conversations replace chat and mail.** A dm, a group, a channel and a mail between two agents are now all one
+thing: a conversation, a signed, hash-chained log that the relay sequences and stores encrypted, and that each member
+verifies (spec §6.8, §16). Each sender device encrypts to the conversation with a sender key, so each line is one
+ciphertext, stored once (spec §16.5, §16.6). Tasks and delegation keep their envelopes and work as before.
+
+**Upgrade the relay first, then every daemon of a realm together** (docs/distribution.md, "Upgrading from 0.7.1 to
+the conversations release"). Stores only grow: nothing resets, and a rollback keeps the data.
+
+### Breaking
+
+- **0.7.1 and 0.8.0 daemons cannot exchange chat, mail or message requests** (spec §8.3, "Mixed versions"). Tasks,
+  presence and the directory still work in both directions.
+  - **0.8.0 → 0.7.1.** Before it creates a dm, group or channel with a person, adds a person, or sends a message
+    request, a 0.8.0 daemon asks the relay (the new `conv.caps` frame, spec §7). If every device of that person with
+    current presence lacks the `conversations` feature, the call fails with the new error `peer_outdated`, "<handle>
+    needs to update Messaging", and nothing is created or sent, so no contact is left half-open. A person with no
+    presence within the envelope TTL gives the relay no evidence, and the call goes ahead.
+  - **0.7.1 → 0.8.0.** A 0.8.0 daemon refuses a 0.7.1 chat line, plain mail or message request with a `rejected`
+    receipt, code `refused`. 0.7.1 shows only `refused` and its hint "do not retry; tell your person": **to a 0.7.1
+    user, `refused` from an updated colleague means "update Messaging".**
+  - **Rollout.** The relay first: it opens a 0.7.1 database in place and still serves every frame 0.7.1 uses, so 0.7.1
+    daemons keep working through it. Then every daemon of a realm, in one window.
+- **Message requests pending at the upgrade must be sent again.** A request you sent from 0.7.1 that was not yet
+  answered is not carried over: it no longer shows in `request.waiting`, so send it again once both sides run 0.8.0.
+  A request you received and had not answered shows in `request.list` with state `resend`; it cannot be accepted,
+  because 0.7.1 requests carry no sender-signed proof, so ask its sender to send it again. Nothing is re-signed from
+  copied text.
+- **IPC methods removed, with no aliases** (spec, "Conversation IPC cut-over"; design §14): `msg.send`, `person.send`,
+  `channel.create`, `channel.invite`, `channel.leave`, `channel.remove`, `search`, `conv.subscribe`, `agents.list` and
+  `agents.read`. `conv.list`, `conv.read` and `people.get` (now a batch of 1–100 ids) keep their names with the
+  conversation shapes. The chat `conv.markRead` is gone from the live API; its conversation form is staged (below).
+  - Plain mail is a `conv.send` line. A task is `task.create`, and an answer to a task waiting for input is
+    `task.continue`, both on the agent tier; `task.list/get/update/cancel` are unchanged.
+  - A daemon refuses plain agent-mail envelopes, including mail held before the upgrade and released after it. The
+    rows stay in the store but are not served.
+- **New live methods** (`LIVE_CONVERSATION_METHODS`, spec §8.2):
+  - agent and human tier: `conv.list`, `conv.read`, `conv.send`, `conv.react`, `conv.edit`, `conv.delete` (an agent
+    edits or deletes only its own lines), `conv.search`, `conv.context`, `conv.access`, `conv.sync`;
+  - human tier (admin socket only): `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.get`, `sessions.list`, `request.waiting`.
+- **Staged, not live.** These contracts are in `@messaging/core` with no handler and no tier; a call to one is refused
+  (design, "Lane 4 live boundary"):
+  - read state and preferences: `conv.markRead`, `conv.markUnread`, `conv.prefs`, `conv.follow`, `conv.save`,
+    `conv.saved`, `conv.draft`, `conv.localRetention`;
+  - history as context: `context.get`, `context.set`, `context.set.preview`;
+  - the channel catalogue: `conv.catalogue`, `conv.publish`;
+  - files: `file.get`;
+  - typing and activity: `conv.typing`, `session.activity`, `turn.cancel`;
+  - scheduled lines: `conv.schedule`, `conv.scheduled`, `conv.unschedule`.
+
+  Until read state lands, views carry no read positions, unread counts, preferences or follow state, and the filters
+  that need them (`conv.list` `unread` and `mentions`, `conv.threads` `unread` and `following`) are refused with
+  `invalid_request`, never answered with an empty page. `conv.backfill` verifies the relay history it can fetch and
+  answers `complete: false`.
+- **CLI.**
+  - `messaging message-status` is removed. `messaging status --help` points to `chat read` and `task`.
+  - `messaging send <participant|cid> [text…]` sends a conversation line as the person (`conv.send`). It creates the
+    dm when there is none, and prints `Pending <id> in <cid>` or `Waiting for consent.`. `--task` and `--continue`
+    send to one agent session, as before.
+  - `messaging chat list/read/post/search` take conversation ids (`cid`) and opaque `--cursor`s, not room names.
+    `chat search --room` is now `--cid`. `chat read` no longer changes read state, and `--keep-unread` is gone.
+  - `messaging listen` follows `conv.sync`. It prints conversation metadata and stream gaps, never the text.
+- **MCP** (`messaging-mcp`, spec §11). Ten tools: `contacts`, `conversations`, `send`, `inbox`, `read`, `search`,
+  `context`, `tasks`, `task_update` and `task_cancel` (0.7.1 had eight, without `conversations` and `context`).
+  `--channel` is removed: the daemon decides which conversations an agent may read. Addresses are participants and
+  `cid`s, not `person:`, `agent:` or `channel:` names.
+- **Package exports** (`@joe-broadhead/messaging/core`; a breaking change for the OpenCode plugin):
+  - removed: `AgentSummary`, `ChannelConv`, `ChatLine`, `ChatSeq`, `ChatText`, `ConvCursor`, `ConvEntry`,
+    `ConvPlace`, `ConvSummary`, `ConversationRef`, `RoomRef`, `conversationOf`, `conversationOfPeer`,
+    `decodeToolCursor`, `encodeToolCursor`, `presentConvEntry`, `presentLine`, `presentMail`, `presentSent` and
+    `sealKeyShares` (now `sealKeyShare`, one recipient); in `./core/testing`, `sealKeySharesWith` (now
+    `sealKeyShareWith`);
+  - changed: `AGENT_METHODS`, `HUMAN_METHODS` and `IPC_METHODS` (the method lists above), `TOOL_VERBS` (now only
+    `contacts`, `tasks`, `task_update` and `task_cancel`; all ten tools are `CONVERSATION_TOOL_VERBS`, with
+    `ConversationTools`), `AgentTool`,
+    `TOOL_DESCRIPTIONS`, `TOOL_REMEDIES`, `ErrorCode` (adds `peer_outdated`), `LIMITS`, `DOMAIN`, and the consent,
+    device, Jelly and surface method tables;
+  - `./ipc`, `./ipc/testing`, `./testing/jelly-id` and `./zod` export the same names as 0.7.1.
+
+### Conversations
+
+- **Dms, groups, channels and threads** (spec §6.8, §16). One log per conversation. Membership, roles and policy
+  are ops in the log, so every member computes the same participants at every position. A reply names its root.
+  Edits, deletes, reactions and pins are events that name their target. A dm starts with no shared history. Channels
+  share their history with new members, and groups and dms rekey when someone is added.
+- **Agents are participants.** A participant is a person or one agent of a person (`person/agent`). Mail between two
+  agents is a line in their dm.
+- **An agent can start a dm with another agent.** `conv.send {to: "person/agent"}` with no dm makes the person's
+  device sign the create, with only the two agents as participants. The daemon relies on the client's first-send
+  confirmation, as 0.7.1 mail did. The agent's lines wait on the sending device until the recipient seats its agent,
+  keep the id the send returned, and lapse after 7 days (at most 50 waiting per dm). An agent still cannot start a dm
+  with a person, or add or seat anyone.
+- **Consent on invitations.** The recipient person's `ask` decides an agent-dm invitation: `open` seats the agent,
+  `request` holds it for the person, and `no` declines it silently. Until it is accepted, the relay serves an invitee
+  only the signed ops and digests: no ciphertext, no key shares, and only op pushes (spec §7, "Conversation frames").
+- **Message requests on conversations** (spec §16.11). A first message to a person of another org is a signed,
+  portable request: the sender's device signs a descriptor that commits to the sealed opening text. The relay refuses
+  an external dm without request admission. Accepting signs a decision, activates the dm once, and imports the
+  opening as its first line, under its original author and id. `request.waiting` shows `held` only from an
+  authenticated hold, and `pending-delivery` while delivery is unconfirmed. Requests pending at the upgrade must be sent
+  again (Breaking, above). Crossed requests make one dm.
+- **Guests.** A person of another org joins a conversation as a guest. A guest cannot invite, cannot change role out
+  of guest, and an agent of a guest inherits the guest's role. Keys and content reach a guest only after acceptance
+  (and, where history is not shared, after a rekey). These rules are enforced by the log and the relay. The daemon
+  does not yet create the inviter's signed preview that a guest's acceptance needs, so inviting a guest end to end
+  is not available in 0.8.0.
+- **The inbox is a projection.** `inbox.list/get/ack` and `item.read` return task items and verified lines in accepted
+  agent dms addressed to that session. A line's id is its event id, with its `cid`. Acknowledgements belong to the
+  participant and survive an agent restart with a new session key. Plain mail stored before the upgrade is not
+  returned.
+- **Own-person wakes on lines.** A person's line to their own agent (the other end of the dm, or a mention) wakes a
+  sleeping Jelly host, as mail did in 0.7.1 (spec §7, "Wake tickets"; §16.2). The relay takes the author's person from
+  the authenticated device, never from the event, and uses the existing ticket, gap and budget rules. Another person's
+  line never wakes your host.
+- **`contacts.list`** returns accepted conversations only: `cid`, `kind`, optional `name` and `dmWith`. No transcript,
+  read position or unread count.
+- **Blocks.** A blocked person's events are hidden from reads, search, previews and replay. The verified log stays
+  intact.
+- **Maintenance.** The daemon retries the conversation outbox, schedules due epoch rekeys, answers new members'
+  channel history after a random 0–30 s delay, and expires local message text and search rows after retention, keeping
+  digests and ops so the chain stays verifiable. Ops never expire (design §4.4, D2).
+- **Key shares go one per recipient device and are not entries of the log**; the relay serves each only to its
+  recipient (design §4.4, D1).
+- **Relay frames** (spec §7): `conv.append`, `conv.share`, `conv.fetch`, `conv.head` and `conv.caps`, with `conv.ok`,
+  `conv.shared`, `conv.entries`, `conv.heads`, `conv.capabilities` and `conv.push`; and the request mailbox
+  `request.settle`, `request.state` and `request.settled`. The relay sequences each log and checks appends against its
+  copy (membership, the author's current device, op heads, epochs, orgs), and members verify everything it serves.
+- **Presence** advertises the `conversations` feature.
+
+### Security
+
+- **New entries need the author's current device.** A conversation entry from a device that is no longer the author's
+  current binding is held: it keeps the chain but adds no state and no text, and is re-checked when the realm view
+  changes. Accepted history keeps its historical verification.
+- **Rejected entries leave bounded evidence**: at most 128 rejected wire entries, and at most 512 junk and held
+  alarms, deduplicated across retries and restarts.
+- **A message an author was not allowed to send is quarantined**, not shown.
+- **HTTP response bodies are bounded while they stream** (daemon: Jelly environment, device login, directory home;
+  relay: Jelly directory). A response over the limit is cancelled, not buffered.
+- **Relay error text stays out of the daemon's logs**: `relay.disconnected` no longer logs the relay's message.
+- **Consent races.** A block made while a request's directory work is in flight is checked again before the request is
+  sent. Request pacing is reserved before any asynchronous work, so concurrent requests cannot pass the limit.
+  Answering a held request settles the request and the grant (`always` or `block`) in one transaction.
+- **Agents are bound to their session.** The daemon binds every agent call to a session registered on that
+  connection, and rechecks membership and session ownership after rendering. Cursors bind to the query and session.
+  Peer text, author names and conversation names in MCP output are fenced, and long text carries a truncation marker.
+- **Interim projection bounds**: projection refuses logs above 10,000 entries and responses above 512 KiB, pending
+  load tests.
+
+### Fixed
+
+- **A sync that overlaps the daemon's own append is accepted.** A page that repeats an entry the flush path just stored
+  failed with "entry does not extend head N"; repeated entries are now checked by seq and dropped, and a different
+  entry is `conv_conflict`.
+- **`conv.add` and `conv.remove` no longer fail with "a conversation event is still pending"** while maintenance key
+  shares are queued: the control path drains them first.
+- **Removing a person while history shares to them are queued no longer stalls the outbox.** A queued share is dropped
+  only when the conversation's own verified log removes its device (`conversation.share.dropped`, ids only). An explicit
+  device rekey goes ahead of queued events.
+- **Reads no longer re-verify whole logs.** Verified event signatures are remembered (16,384 successes, never
+  failures), which removed the main CPU cost of reads and the timeouts it caused under load.
+- **A line that becomes readable when its key arrives late streams as a new event.**
+- **`messaging listen` fixes its stream position before it says it is ready**, so no event is missed at start.
+- **`messaging daemon stop` waits for the home lock to be released**, and checks that an older daemon has exited.
+- **Contact requests whose delivery is unconfirmed stay visible as pending.**
+
+### Federation foundation (not live)
+
+Groundwork for messaging between realms (docs/design/federation.md). **Nothing is wired into the daemon or the relay,
+and nothing in 0.8.0 talks to another realm.**
+
+- `@messaging/core` verifies another realm's identity proofs: its directory and full roster histories, including
+  complete epoch rotation chains.
+- The daemon has a journal of foreign pins (trust on first use), proof results and human key reviews, with bounded
+  evidence that never drops an authenticated removal. Its durable storage is not built yet.
+- The relay has a roster discovery handler (`/.well-known/messaging.json`) that is not installed in its HTTP server.
+- An isolated two-realm e2e fixture.
+
+### Stores
+
+**Stores only grow** (spec §8.8). Every migration is additive; the generation stays 2 and `min_reader` stays 1, so a
+0.7.x messagingd or relay still opens what 0.8.0 writes.
+
+- **Daemon store, schema 4** (`packages/daemon/store-schemas/2.json`–`4.json`): schema 2 adds `conv_logs`,
+  `conv_entries`, `conv_shares`, `conv_cursors`, `conv_outbox`, `conv_keys`, `conv_alarms` and `conv_fts`; schema 3
+  `conv_held`; schema 4 `conv_evidence`. Message requests use rows in the existing `kv` table.
+- **Relay database, schema 3** (`packages/relay/store-schemas/2.json`, `3.json`): schema 2 adds `conv_logs`,
+  `conv_entries`, `conv_members` and `conv_shares`; schema 3 `conv_request_decisions`.
+- **The old chat and mail tables stay**, unused. No table is dropped.
+- **Rollback keeps the data**, measured for both stores. A 0.7.1 relay database opens in 0.8.0, and 0.7.1 reopens
+  it. A 0.7.1 home opens in the 0.8.0 daemon (schema 4); 0.7.1's `messagingd` then starts on it, keeps the team and
+  its identity, logs no error and leaves the conversation tables alone, and 0.8.0 reads the same conversations
+  again afterwards. Conversations sent on 0.8.0 are not visible on 0.7.1. Spec §8.8 states both schemas.
+
+### Documentation
+
+- `packages/daemon/docs/messagingd.md` and `cli.md` describe conversations; docs/distribution.md has "Upgrading from
+  0.7.1 to the conversations release".
+- The spec names the MCP server's ten tools; tests check the spec against the error codes, stream record kinds,
+  `request.waiting` states, tool names and staged methods.
+- A test fails when any CLI help names a command that does not exist.
+
+### Tests
+
+- An opt-in mixed-version e2e against a real older release (`MESSAGING_E2E_OLD`, `MESSAGING_E2E_OLD_MACHINES`), in a
+  roster realm. The directory realm against a real 0.7.1 is covered by unit tests only.
+- Red-when-removed tests for the agent's own-line edit and delete, the agent's dm creation rule, and the relay's
+  shares-only-to-readers filter.
+
 ## [0.7.1] - 2026-11-09
 
 **No store change.** A 0.7.0 home and a 0.7.0 relay database open unchanged, and a 0.7.0 messagingd or relay still
@@ -67,8 +429,8 @@ opens what 0.7.1 writes. 0.7.0 was the last store reset: from 0.7.0 on, stores o
   create` / `team join`). Inbox, transcripts, grants, tasks and notices stay in the old home, which messagingd
   0.6.0 still opens; a 0.6.0 snapshot does not restore. Reset the managed relay and every home that uses it on the
   same day: the relay's directory restarts empty.
-- Until the first release another person uses, a store change edits the baseline, raises the generation and
-  resets the stores again, and its release notes say so. From that release on, stores only grow.
+- **0.7.0 is the first release another person uses and the last store reset** (owner, 2026-11-08).
+  From this release on, stores only grow through additive migrations; the baseline and generation stay fixed.
 - Stored inbox peers, task peers and provenance now use the API's `device` and `agent`, not the first shape's
   `machine` and `session`.