feat: Security

agents-docs/adr/0002-session-token-authentication.md

@@ -0,0 +1,13 @@
+# ADR-0002: Session-Token Authentication on the Signaling Server
+
+## Status
+Accepted
+
+## Context
+The signaling server trusted client-supplied user IDs on REST mutations and WebSocket `identify`, allowing impersonation for kicks, bans, joins, plugin administration, and push dispatch. The product client already used bearer tokens for the Electron Local API, but the shared signaling server had no equivalent binding between HTTP/WebSocket actions and a logged-in user.
+
+## Decision
+Issue opaque session tokens on login/register, persist them in server SQLite, require `Authorization: Bearer` on all mutating REST routes, and require `identify.token` on WebSocket connections before any other client message is accepted. Actor fields (`currentOwnerId`, `actorUserId`, `requesterUserId`) are derived from the token instead of request bodies.
+
+## Rationale
+This closes identity spoofing without changing the P2P product model: discovery stays public, chat/media still relay over WebSocket, and DM WebRTC signaling remains available across servers. Bcrypt password hashing with transparent SHA-256 upgrade preserves existing accounts. A deprecation window for body-only auth was intentionally omitted so all clients must authenticate in one release, avoiding prolonged dual-trust behavior.

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.