feat(cli): chat — read a group's last messages, post one

chat GROUP prints the last ten messages, oldest first (-N, as head -N, or
-n N for another count, paging back past the node's 200), and -m posts one
(- reads it from stdin). The application's construction: every epoch key
from chat_keys_req, a post sealed under the current epoch through the
device subkey and signed with this machine's key on the node, the sender's
name inside the envelope; nothing sent past the node's ciphertext bound.
A stored message is read signature first, then key, then content, and one
that fails is shown as unreadable, never dropped. Not done here: the Tier 2
roster check on the signing device.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

1 files changed, 16 insertions, 7 deletions

diff --git a/docs/MESHBAY_DESIGN.md b/docs/MESHBAY_DESIGN.md
index 18c155e..799b162 100644
--- a/docs/MESHBAY_DESIGN.md
+++ b/docs/MESHBAY_DESIGN.md
@@ -3012,12 +3012,11 @@ MSE string) fed to a source buffer, with the node holding one slot per viewer.
 
 `meshbay-cli` (`packages/meshbay-cli`) is a member's groups and files from a
 terminal: `login`, `logout`, `groups`, `invitations`, `join`, `decline`,
-`leave`, `ls`, `search`, `get`, `put`, `rm`, `devices`, `trust`, `browser-access`,
-and with no
-argument an interactive two-pane view (Textual) over the same library. It is not an
-operator tool — a node is administered through `meshbay-node` and its loopback
-API (§6.7) — and it does not stream, play or chat: those belong to an engine
-with a player and a page. English only.
+`leave`, `ls`, `search`, `get`, `put`, `rm`, `chat`, `devices`, `trust`,
+`browser-access`, and with no argument an interactive two-pane view (Textual)
+over the same library. It is not an operator tool — a node is administered
+through `meshbay-node` and its loopback API (§6.7) — and it does not stream or
+play: those belong to an engine with a player and a page. English only.
 
 **The same protocol as the other clients, end to end.** The hub signs it in,
 issues the per-node token (E10) and relays the WebRTC offer and answer; from the
@@ -3051,6 +3050,16 @@ one result, keyed by its content hash, and listed from the reader's own node
 first; the others are kept as places. Like Files, and unlike the media views, it
 groups nothing into units.
 
+**Chat** (`chat`) reads the last messages (ten, or `-N`, paging back through
+`chat_hist`) and posts one, with the application's construction (§4.5): every
+epoch key from `chat_keys_req`, a message sealed under the current epoch through
+the sending device's derived subkey and signed with its key on the node, which
+must be the device `device_hello` named. A stored message is read signature
+first, then key, then content, and one that fails any of them is shown as
+unreadable, never left out. The name shown is the one sealed by the sender; the
+roster check that the signing device belongs to the account the node names
+(Tier 2, §3.3) is the application's and not done here.
+
 **Deleting** (`rm`) is `file_delete` signed with the machine's key on the node
 (§5.4): the node accepts the uploading account's devices and the operator's.
 The client checks the same rule against the index first (`uploader_id`, and the
@@ -4597,7 +4606,7 @@ and download stages, account recovery, the Windows port through packaging, and
 the Android client — the shell, native keys, downloads and uploads, casting,
 and notifications while it is closed, fetched or pushed (§11.3) — and the
 command-line client: groups, joining and leaving them, listing, search across
-groups, downloads and uploads with resume, deleting, device linking and approval, browser access, and an
+groups, downloads and uploads with resume, deleting, reading and posting chat, device linking and approval, browser access, and an
 interactive two-pane view (§8.6).
 
 The packages install: a machine has been taken from the built artefacts to a