feat: Security

agents-docs/FEATURES.md

@@ -9,7 +9,9 @@ It must stay accurate as new features are introduced, renamed, merged, or remove
 ## Feature list (alphabetical)
 
 - [App i18n](features/app-i18n.md) — `@ngx-translate/core` localization for the product client; English-only catalog today, same stack as the marketing website.
+- [Authentication](features/authentication.md) — signaling-server session tokens, protected REST/WebSocket identity, and client bearer storage.
 - [Custom Emoji](features/custom-emoji.md) — peer-synced user-created emoji assets, chat reaction shortcuts, and composer emoji insertion.
+- [Message Integrity](features/message-integrity.md) — signed P2P message revision chains, inventory `headHash` convergence, and Ed25519 signing-key registration on the signaling server.
 - [Mobile Capacitor](features/mobile-capacitor.md) — Capacitor native shell, mobile infrastructure facades, and phone-specific call/chat/media integrations.
 - [Server Discovery](features/server-discovery.md) — featured/trending public-server REST endpoints (server) consumed by the `/dashboard` and `/servers` client pages.
 - [Signal Server Tag](features/signal-server-tag.md) — configurable signal-server display tag shown on profile cards for a user's registration server.

agents-docs/LESSONS.md

@@ -25,6 +25,13 @@ Durable rules for AI agents working on this project. Read this file at session s
 
 ## Lessons
 
+### Persisted local user state still requires a session token [authentication] [signaling]
+
+- **Trigger:** Users appear logged in from local storage but cannot see peers online or send chat after session-token auth shipped.
+- **Rule:** before connecting signaling or loading rooms for a persisted user, require a non-expired token in `metoyou.authTokens`; redirect to `/login` on `SESSION_EXPIRED`, `auth_required`, or `auth_error`.
+- **Why:** WebSocket `identify` is skipped without a token, so `join_server`, RTC relay, and presence never establish even though the profile exists locally.
+- **Example:** `hasValidPersistedSession()` in `auth-session.rules.ts` from `loadCurrentUser$`.
+
 ### Declare MODIFY_AUDIO_SETTINGS for Android WebRTC mic capture [mobile] [android]
 
 - **Trigger:** Android users accept the microphone prompt but voice calls and channels still fail to join.

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.

agents-docs/features/authentication.md

@@ -0,0 +1,67 @@
+# Authentication
+
+Session-token authentication for the signaling server and product client.
+
+## Trust boundaries
+
+| Surface | Identity proof | Notes |
+|---|---|---|
+| Signaling server REST (mutations) | `Authorization: Bearer <token>` | Actor user IDs in request bodies are ignored; server derives `authUserId` from the token |
+| Signaling server REST (discovery) | None | `GET /api/servers`, featured/trending/search remain public |
+| Signaling server WebSocket | `identify.token` | Connections must identify before any other message type |
+| Electron Local API | Separate in-memory bearer tokens | Proxies login to allowed signaling servers only |
+| Product client local DB | OS user account | SQLite and attachments are plaintext at rest |
+
+## Login / register response
+
+```json
+{
+  "id": "<uuid>",
+  "username": "alice",
+  "displayName": "Alice",
+  "token": "<opaque-hex>",
+  "expiresAt": 1710000000000
+}
+```
+
+- Tokens are opaque 64-character hex strings stored in server SQLite (`session_tokens`).
+- Default TTL: 24 hours (`SESSION_TOKEN_TTL_MS` env override supported).
+- Passwords are stored with bcrypt; legacy SHA-256 hashes are upgraded transparently on successful login.
+
+## Protected REST routes
+
+Require `Authorization: Bearer`:
+
+- `PUT/POST/DELETE` under `/api/servers/*` (except public `GET`)
+- `PUT /api/requests/:id`
+- Plugin-support mutations under `/api/servers/:serverId/plugins/*`
+- `/api/users/device-tokens/*`
+- `POST /api/users/logout`
+
+## WebSocket identify contract
+
+```json
+{
+  "type": "identify",
+  "token": "<session-token>",
+  "oderId": "<user-id>",
+  "displayName": "Alice",
+  "connectionScope": "ws://host:3001"
+}
+```
+
+- `oderId` must match the token's user id when provided.
+- Server responds with `auth_error` or `auth_required` when authentication fails.
+
+## Client storage
+
+The product client stores tokens per signaling-server base URL in `localStorage` (`metoyou.authTokens`). An HTTP interceptor attaches the bearer token to `/api/*` requests targeting that server.
+
+Persisted local user state (`metoyou_currentUserId` + IndexedDB/SQLite profile) is **not** sufficient to use chat or presence. On startup, `loadCurrentUser$` requires a non-expired session token for the user's home/active signaling server (or any stored token as a fallback). Missing or rejected tokens dispatch `SESSION_EXPIRED` and redirect to `/login`. WebSocket `auth_required` / `auth_error` responses trigger the same path.
+
+## Security considerations
+
+- Rate limits: login/register (100 / 15 min), server join (30 / min).
+- CORS allowlist: optional `corsAllowlist` in `server/data/variables.json` or `CORS_ALLOWLIST` env (comma-separated). Empty allowlist keeps permissive CORS for local development.
+- Push-token routes require bearer auth and user-id match.
+- RTC relay: direct-message/direct-call types always relay; server-icon types require shared server membership; WebRTC offer/answer/ice remain open for cross-server DM WebRTC.

agents-docs/features/message-integrity.md

@@ -0,0 +1,60 @@
+# Message Integrity
+
+Signed, append-only **message revisions** give P2P chat a verifiable history without central message storage. The materialized `Message` row in local SQLite/IDB is a cache; peers converge via inventory snapshots and revision events.
+
+## Responsibilities
+
+- **Revision chain** — Every create, edit, delete, moderation, or plugin mutation appends a `MessageRevision` with monotonically increasing `revision`, `prevRevisionHash`, and `headHash`.
+- **Dual emit** — Outgoing mutations broadcast the legacy event (`chat-message`, `message-edited`, `message-deleted`) **and** `message-revision` so older peers keep working while integrity-aware peers prefer revisions.
+- **Inventory** — Sync inventories include `{ id, ts, rc, ac, revision, headHash }`. Peers re-fetch when remote revision is newer or the same revision has a different hash (tamper detection).
+- **Signing** — Human authors sign revisions with per-user Ed25519 keys. Public keys are registered on the signaling server; private keys stay in browser `localStorage`.
+
+## Boundaries
+
+| Layer | Owns |
+| --- | --- |
+| Product client (`toju-app`) | Revision construction, merge, verification, P2P broadcast, local persistence |
+| Signaling server (`server`) | `PUT /api/users/me/signing-key`, `GET /api/users/:id/signing-public-key` — key directory only, no message storage |
+| Electron / mobile persistence | `revision` + `headHash` on message rows; revision audit log (IDB store / SQLite meta) |
+
+Plugin API messages may emit unsigned revisions (`plugin-edit` / `plugin-delete`) when the actor is a synthetic plugin user.
+
+## Key types
+
+- `Message.revision`, `Message.headHash` — materialized cache fields on the shared `Message` model.
+- `MessageRevision` — wire + persistence audit record (`message-revision.models.ts`).
+- `MessageRevisionType` — `create`, `author-edit`, `author-delete`, `moderate-edit`, `moderate-delete`, `plugin-edit`, `plugin-delete`.
+- `ChatEvent.type: 'message-revision'` — P2P envelope carrying a full `MessageRevision`.
+
+## Merge rules
+
+1. Valid signed revision with higher `revision` wins over legacy timestamp edits.
+2. Same `revision`, different `headHash` → treat as stale/tampered and re-fetch.
+3. Unsigned revisions (no `signature`) are accepted for backward compatibility when verification is skipped.
+4. Legacy peers without `revision`/`headHash` in inventory fall back to `ts` / `rc` / `ac` comparison.
+
+## Client touchpoints
+
+- Domain rules: `message-integrity.rules.ts`, `message-revision.builder.rules.ts`, `message-sync.rules.ts`
+- Services: `MessageRevisionService`, `MessageSigningService`
+- Store: `messages.effects.ts` (outgoing dual-emit), `messages-incoming.handlers.ts` (`handleMessageRevision`), `messages.helpers.ts` (inventory + merge)
+- Plugins: `plugin-client-api.service.ts` emits revisions for send/edit/delete
+
+## Server API
+
+| Method | Path | Auth | Body / response |
+| --- | --- | --- | --- |
+| `PUT` | `/api/users/me/signing-key` | Bearer | `{ publicKeyJwk }` — stores Ed25519 public JWK on the user row |
+| `GET` | `/api/users/:id/signing-public-key` | Public | `{ publicKeyJwk }` — used by peers to verify signatures |
+
+Registration runs automatically after login/register via `AuthenticationService`.
+
+## Degraded-mode behavior
+
+- Outgoing revision signing is **best-effort**: if `Ed25519` signing fails, the client still broadcasts the legacy `chat-message` envelope (unsigned revision).
+- Incoming signed revisions are accepted without cryptographic verification when the sender's public key is not yet registered on the server, so chat is not blocked during key-registration races.
+
+## Testing
+
+- Unit: `message-integrity.rules.spec.ts`, `message-revision.builder.rules.spec.ts`, `message-revision-signing.rules.spec.ts`, `message-sync.rules.spec.ts`, `messages-incoming.handlers.spec.ts`
+- Outgoing revision wiring is covered indirectly through existing message effect tests; add focused specs when changing merge or signing behavior.