feat: Security

agents-docs/adr/0003-signed-message-revisions.md

@@ -0,0 +1,23 @@
+# ADR-0003: Signed Message Revision Chains for P2P Chat Integrity
+
+## Status
+Accepted
+
+## Context
+P2P chat sync compared timestamps, reaction counts, and attachment counts only. A peer could rewrite history or apply edits out of order with no cryptographic check. The product has no central message store, so integrity must travel with sync traffic and local audit logs.
+
+## Decision
+Adopt an append-only **revision chain** per message:
+
+- Each mutation emits a `MessageRevision` (create, edit, delete, moderation, plugin) with `revision`, `prevRevisionHash`, and `headHash` (SHA-256 over canonical head state).
+- Inventories advertise `{ revision, headHash }` so peers detect gaps and hash mismatches.
+- Human-authored revisions are signed with per-user Ed25519 keys; public keys are registered on the signaling server for verification.
+- Legacy `chat-message` / `message-edited` / `message-deleted` events continue to broadcast alongside `message-revision` for one-release backward compatibility.
+
+## Rationale
+Revision chains give deterministic merge (higher valid revision wins) without requiring a trusted relay. Signing binds edits to registered users while keeping chat payloads off the server. Dual emit avoids breaking peers that have not upgraded inventory or revision handlers yet.
+
+## Consequences
+- New persistence columns and revision audit stores on browser IDB, Electron SQLite, and Capacitor schemas.
+- Plugin synthetic users may emit unsigned revisions until a plugin signing model exists.
+- Attachment byte integrity (SHA-256 on `file-announce`) remains a separate follow-up.