chore: Fix app

agents-docs/FEATURES.md

@@ -9,14 +9,27 @@ 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.
+- [Attachments](features/attachments.md) — P2P chunked file transfer over WebRTC data channels with Electron/Capacitor disk persistence.
 - [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.
+- [Desktop Local API](features/desktop-local-api.md) — Electron localhost HTTP read API, auth proxy, and offline Docusaurus docs.
+- [Direct Messaging](features/direct-messaging.md) — index entry; full contract in [Messaging](features/messaging.md).
+- [Game Activity](features/game-activity.md) — RAWG game matching, Electron process detection, and P2P now-playing sync.
+- [Invites & Join Requests](features/invites-join-requests.md) — invite links, HTML landing pages, and moderated join approval.
+- [Klipy GIFs](features/klipy-gifs.md) — server-proxied GIF search for chat and DM composers.
+- [Link Preview & Media Proxy](features/link-preview-media-proxy.md) — SSRF-guarded link unfurling and image proxy on the signaling server.
 - [Message Integrity](features/message-integrity.md) — signed P2P message revision chains, inventory `headHash` convergence, and Ed25519 signing-key registration on the signaling server.
+- [Messaging](features/messaging.md) — server-channel chat, direct messages, inventory sync, and DM delivery state machine.
 - [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.
+- [Plugins](features/plugins.md) — client plugin runtime, server metadata API, Electron plugin data, and P2P message bus.
+- [Push Notifications](features/push-notifications.md) — FCM/APNs device tokens on the server and Capacitor registration.
+- [Server Directory](features/server-directory.md) — multi-endpoint catalog, REST CRUD/join/moderation, and room signal affinity.
+- [Server Discovery](features/server-discovery.md) — featured/trending public-server REST endpoints consumed by `/dashboard` and `/servers`.
+- [Signaling](features/signaling.md) — canonical WebSocket envelope catalog, ordering invariants, and relay rules.
 - [Signal Server Tag](features/signal-server-tag.md) — configurable signal-server display tag shown on profile cards for a user's registration server.
+- [Voice & WebRTC](features/voice-webrtc.md) — voice/camera/screen-share WebRTC with signaling relay and multi-device ownership.
 
-The product client already documents its bounded contexts at `toju-app/src/app/domains/<name>/README.md` (Access Control, Attachment, Authentication, Chat, Direct Call, Direct Message, Experimental Media, Game Activity, Notifications, Plugins, Profile Avatar, Screen Share, Server Directory, Theme, Voice Connection, Voice Session). Those domain READMEs cover internal product-client behavior.
+The product client also documents its bounded contexts at `toju-app/src/app/domains/<name>/README.md` (Access Control, Attachment, Authentication, Chat, Custom Emoji, Direct Call, Direct Message, Experimental Media, Game Activity, Notifications, Plugins, Profile Avatar, Screen Share, Server Directory, Theme, Voice Connection, Voice Session). Those domain READMEs cover internal product-client behavior.
 
 `agents-docs/features/<slug>.md` is for **cross-context** contracts and feature areas that span more than one subdomain — WebSocket envelopes, IPC channels, plugin manifests, end-to-end flows that touch client + server + Electron together. Add an entry here the first time you write one.
 

agents-docs/LESSONS.md

@@ -25,6 +25,13 @@ Durable rules for AI agents working on this project. Read this file at session s
 
 ## Lessons
 
+### Run `npm run i18n:sync` after editing any `public/i18n/catalog/*.json` file [i18n] [testing]
+
+- **Trigger:** Added new `call.errors.*` keys to `toju-app/public/i18n/catalog/call.json` and used them in code; the full test run failed in `app-i18n-catalog.rules.spec.ts` with "Missing i18n keys" even though the keys existed in the catalog file.
+- **Rule:** The runtime and the catalog spec read the merged `toju-app/public/i18n/en.json`, not the per-area `catalog/*.json` files — after any catalog edit, run `npm run i18n:sync` (root script, `tools/sync-app-i18n-catalog.mjs`) and commit the regenerated `en.json` alongside the catalog change.
+- **Why:** without the sync the new strings silently fall back to raw keys at runtime and the catalog spec fails, but only in the full suite — targeted spec runs of the feature under change pass, so the failure surfaces late.
+- **Example:** `npm run i18n:sync && npm run test` after adding `call.errors.microphonePermissionDenied` to `catalog/call.json`.
+
 ### Match direct-call recipients against every local identity alias, exactly like DMs already do [direct-call] [identity]
 
 - **Trigger:** "User receiving direct call doesn't get notified" — a caller who met the callee through a room on the caller's signal server addressed the ring by the callee's *provisioned actor id*; `handleIncomingCallEvent` admitted only `payload.participantIds.includes(oderId || id)`, so the ring was silently dropped, the caller sat "In Voice", and the callee saw nothing. DMs had the identical bug fixed earlier (`baa350e`), but the fix stopped at `DirectMessageService` and never reached `DirectCallService`.

agents-docs/features/app-i18n.md

@@ -1,7 +1,14 @@
 # App i18n
 
+> **Status:** Active
+> **Last updated:** 2026-07-05
+
 Client-side UI string localization for the product client (`toju-app`), using the same `@ngx-translate/core` stack as the marketing website.
 
+## Migration status
+
+Only **English** ships today (`SUPPORTED_APP_LOCALES = ['en']`). The catalog workflow and `translate` pipe are in place, but many components still use hardcoded strings — new user-visible copy should use i18n keys; migrate adjacent strings when touching a component. There is no locale preference UI yet.
+
 ## Responsibilities
 
 - Bundle locale JSON under `toju-app/public/i18n/`.
@@ -60,3 +67,14 @@ The sync script also extracts `theme.registry.*` labels/descriptions from `theme
 - `toju-app/src/app/core/i18n/app-i18n.rules.spec.ts`
 - `toju-app/src/app/core/i18n/app-i18n.service.spec.ts`
 - `toju-app/src/app/core/i18n/app-i18n.testing.ts` — `provideAppI18nForTests()` / `initializeAppI18nForTests()` for Vitest injectors
+
+## Related
+
+- `toju-app/AGENTS.md` — i18n usage rules for agents
+- Marketing site i18n is separate: `website/public/i18n/`
+
+## Changelog
+
+| Date | Change |
+|------|--------|
+| 2026-07-05 | Documented partial migration status and locale UI gap |

agents-docs/features/attachments.md

@@ -0,0 +1,118 @@
+# Attachments
+
+> **Area:** attachments
+> **Status:** Active
+> **Last updated:** 2026-07-05
+
+## Overview
+
+Attachments move file bytes peer-to-peer over the WebRTC ordered data channel using a announce → request → chunk protocol. Chat and DMs attach metadata to messages; the signaling server does not store or relay file payloads. Sibling devices learn attachment **metadata** via `account_sync` `chat-sync-batch` but must still download bytes from a peer that has them.
+
+Domain internals: [`toju-app/src/app/domains/attachment/README.md`](../../toju-app/src/app/domains/attachment/README.md).
+
+## Responsibilities
+
+- Chunked P2P transfer with flow control and cancel semantics.
+- Auto-download when policy allows; disk streaming on Electron/Capacitor.
+- Ownership vs "shared from your device" UI rules.
+- Persist attachment rows + filesystem paths on desktop/mobile.
+
+This area does **not** own:
+
+- Message envelopes or delivery states → [messaging.md](messaging.md).
+- WebRTC negotiation → [voice-webrtc.md](voice-webrtc.md).
+
+## Key concepts
+
+- **Announce** — sender advertises `fileId`, name, size, mime without sending bytes.
+- **Mirror host** — peer that holds a complete copy and can serve chunks.
+- **Buffered send** — waits for data-channel back-pressure (4 MB high / 1 MB low water marks on chat channel).
+
+---
+
+## P2P protocol
+
+| type | Purpose |
+|------|---------|
+| `file-announce` | Metadata only |
+| `file-request` | Receiver starts download |
+| `file-chunk` | Base64 chunk (`index`, `total`, `data`) |
+| `file-chunk-ack` | Per-chunk flow control |
+| `file-cancel` | Abort in flight |
+| `file-not-found` | Host lacks bytes |
+
+**Chunk size:** `FILE_CHUNK_SIZE_BYTES` = **64 KB** (`attachment-transfer.constants.ts`).
+
+**Electron send path:** reads one chunk at a time from disk via IPC (`append-file-bytes` / read chunk) to avoid loading whole files into renderer memory.
+
+---
+
+## Persistence
+
+| Runtime | Metadata | Bytes |
+|---------|----------|-------|
+| Browser | In-memory / optional save | Below **10 MB** auto-save cap (`MAX_AUTO_SAVE_SIZE_BYTES`) |
+| Electron | SQLite `attachments` + CQRS | `user/<username>/…` via `AttachmentStorageService` / IPC |
+| Capacitor | SQLite | App-private attachment directory — [mobile-capacitor.md](mobile-capacitor.md) |
+
+---
+
+## Download / export to user location
+
+`AttachmentDownloadService.downloadToUserLocation` picks the runtime-appropriate export path:
+
+| Runtime | Behavior |
+|---------|----------|
+| Electron | `saveExistingFileAs` (disk-backed) or `saveFileAs` (blob) native save dialog |
+| Browser | Anchor `download` click on the object URL |
+| Capacitor | `CapacitorAttachmentExportService.exportToDevice`: copies the disk file from `Directory.Data` into `Directory.Documents` (or fetches the object URL and writes base64) using `buildAttachmentExportFileName` (timestamp suffix so exports never collide — Android 11+ rejects overwrites of files the app did not create). Anchor downloads do nothing in the Android WebView. |
+
+## Multi-device
+
+`chat-sync-batch` in `account_sync` carries an `attachments` map (local paths stripped). Sibling devices discover files exist; P2P `file-request` still required for bytes.
+
+---
+
+## Business rules and invariants
+
+- Transfers are between connected peers only (no server CDN).
+- Receive strategy is decided once at request time by `canReceiveAttachment` (`attachment.logic.ts`): ≤ 10 MB assembles in memory everywhere; > 10 MB streams to disk on Electron/Capacitor, assembles in memory on the browser up to its 50 MB persist cap, and is rejected with a visible `fileTooLarge` error beyond that. `handleFileChunk` must accept whatever the request gate admitted — a stricter chunk-time size cap silently drops chunks and stalls the transfer.
+- Visibility-based blob lifecycle on desktop: revoke `blob:` URLs when messages scroll off-screen if disk can rehydrate.
+- "Shared from your device" badge only when bytes are local to the viewing user.
+
+---
+
+## Technical implementation
+
+- Facade: `AttachmentFacade` → `AttachmentManagerService`
+- Protocol: `AttachmentTransferService` + `AttachmentTransferTransportService`
+- Electron IPC: `read-file-chunk`, `append-file-bytes`, `write-file`, `delete-file`, etc.
+
+---
+
+## Testing
+
+- Domain logic specs under `attachment/`
+- E2E: `e2e/tests/chat/chat-message-features.spec.ts`, `local-attachment-persistence.spec.ts`, `multi-device-attachment-sharing.spec.ts`, `large-generic-file-transfer.spec.ts` (browser receiver, generic file above the 10 MB auto-save cap)
+
+---
+
+## Security considerations
+
+- No server-side virus scanning; peers trust senders they are connected to.
+- Files stay in user data directories (Electron path jail).
+
+---
+
+## Related features
+
+- [messaging.md](messaging.md) — message + attachment metadata coupling
+- [authentication.md](authentication.md) — `account_sync` batches
+- [mobile-capacitor.md](mobile-capacitor.md) — mobile storage
+
+## Changelog
+
+| Date | Change |
+|------|--------|
+| 2026-07-13 | Capacitor download/export to public `Documents` via `CapacitorAttachmentExportService` |
+| 2026-07-05 | Expanded to full contract style |

agents-docs/features/authentication.md

@@ -1,6 +1,14 @@
 # Authentication
 
-Session-token authentication for the signaling server and product client.
+> **Area:** authentication
+> **Status:** Active
+> **Last updated:** 2026-07-05
+
+## Overview
+
+Session-token authentication binds REST mutations and WebSocket `identify` to a user identity on each signaling server. The product client may hold **multiple** server credentials (home + foreign auto-provisioned accounts) while keeping one local user profile. Multi-device tabs share one identity via separate `clientInstanceId` values and `account_sync` relay.
+
+WebSocket details: [signaling.md](signaling.md). Local API tokens: [desktop-local-api.md](desktop-local-api.md).
 
 ## Trust boundaries
 
@@ -8,8 +16,8 @@ Session-token authentication for the signaling server and product client.
 |---|---|---|
 | 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 |
+| Signaling server WebSocket | `identify.token` | Connections must identify before any other message type — see [signaling.md](signaling.md) |
+| Electron Local API | Separate in-memory bearer tokens | Proxies login to allowed signaling servers only — see [desktop-local-api.md](desktop-local-api.md) |
 | Product client local DB | OS user account | SQLite and attachments are plaintext at rest |
 
 ## Client logout
@@ -36,13 +44,81 @@ Session-token authentication for the signaling server and product client.
 
 ## Protected REST routes
 
-Require `Authorization: Bearer`:
+Require `Authorization: Bearer` (`requireAuth` middleware). Public routes are listed for contrast.
 
-- `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`
+### Users (`/api/users`)
+
+| Method | Path | Auth |
+|--------|------|------|
+| POST | `/register` | Public |
+| POST | `/login` | Public |
+| GET | `/:id/signing-public-key` | Public |
+| PUT | `/me/signing-key` | Bearer |
+| POST | `/logout` | Bearer |
+
+### Device tokens (`/api/users/device-tokens`)
+
+All routes require bearer; `userId` in body or path must equal `authUserId` (`403` otherwise).
+
+| Method | Path |
+|--------|------|
+| POST | `/` |
+| GET | `/:userId` |
+| POST | `/:userId/dispatch` |
+
+### Servers (`/api/servers`)
+
+| Method | Path | Auth |
+|--------|------|------|
+| GET | `/`, `/featured`, `/trending`, `/:id` | Public |
+| POST | `/` | Bearer |
+| PUT | `/:id` | Bearer |
+| DELETE | `/:id` | Bearer |
+| POST | `/:id/join` | Bearer |
+| POST | `/:id/leave` | Bearer |
+| POST | `/:id/heartbeat` | Bearer |
+| POST | `/:id/invites` | Bearer |
+| GET | `/:id/requests` | Bearer |
+| POST | `/:id/moderation/kick` | Bearer |
+| POST | `/:id/moderation/ban` | Bearer |
+| POST | `/:id/moderation/unban` | Bearer |
+
+### Join requests (`/api/requests`)
+
+| Method | Path | Auth |
+|--------|------|------|
+| PUT | `/:id` | Bearer (approve/deny) |
+
+### Plugin support (`/api/servers/:serverId/plugins`)
+
+| Method | Path | Auth |
+|--------|------|------|
+| GET | `/` | Public (metadata read) |
+| PUT | `/:pluginId/requirement` | Bearer |
+| DELETE | `/:pluginId/requirement` | Bearer |
+| PUT | `/:pluginId/events/:eventName` | Bearer |
+| DELETE | `/:pluginId/events/:eventName` | Bearer |
+| GET/PUT/DELETE | `/:pluginId/data/*` | **410 Gone** (server plugin data disabled) |
+
+### Public (no bearer)
+
+- `GET /api/health`, `/api/time`
+- `GET /api/link-metadata`, `/api/image-proxy`
+- `GET /api/klipy/config`, `/api/klipy/gifs`
+- `POST /api/games/match`
+- `GET /api/invites/:id`
+- `GET /invite/:id` (HTML invite page)
+- OpenAPI docs routes (`/api/openapi.json`, `/api/docs`, …) — gated by server config, not session auth
+
+Full server-directory semantics: [server-directory.md](server-directory.md).
+
+## Message signing key registration
+
+Ed25519 signing keys for [message-integrity.md](message-integrity.md) register via `PUT /api/users/me/signing-key` with `{ publicKeyJwk }`.
+
+- **When registered:** `AuthenticationService` calls `MessageSigningService.registerSigningPublicKeyIfNeeded()` after successful **home** `POST /login` and `POST /register` only (`authentication.service.ts`).
+- **Scope:** registration uses the **active** signaling server's API base (`ServerDirectoryFacade.activeServer()`). Foreign-server auto-provision (`authorizeSignalServer` / `SignalServerProvisionerService`) does **not** currently call signing-key registration — message integrity on foreign servers depends on a later login path or manual registration when that server becomes active.
+- **Storage:** private key in `localStorage` (`metoyou.messageSigningKeyPair`); public key directory on server SQLite only.
 
 ## WebSocket identify contract
 
@@ -135,3 +211,16 @@ Startup routing for signed-out visitors is decided by `resolveUnauthenticatedSta
 - 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.
+
+## Related
+
+- [signaling.md](signaling.md) — WebSocket `identify`, `account_sync`, ordering invariants
+- [desktop-local-api.md](desktop-local-api.md) — Electron Local API bearer tokens
+- [message-integrity.md](message-integrity.md) — signing keys and revision chains
+- [server-directory.md](server-directory.md) — protected server REST mutations
+
+## Changelog
+
+| Date | Change |
+|------|--------|
+| 2026-07-05 | Expanded protected-route inventory; clarified signing-key registration scope; cross-links |

agents-docs/features/custom-emoji.md

@@ -2,64 +2,125 @@
 
 > **Area:** custom-emoji
 > **Status:** Active
-> **Last updated:** 2026-06-05
+> **Last updated:** 2026-07-05
 
 ## Overview
 
-Custom emoji lets users upload small image emoji, use them in chat messages and reactions, and sync emoji assets needed for rendering to connected peers over the existing data-channel mesh.
+Custom emoji lets users upload small image emoji, use them in chat messages and reactions, and sync the image bytes to connected peers over the WebRTC data channel (and to sibling devices via `account_sync`). The signaling server never stores emoji assets.
+
+Internal UI and NgRx wiring: [`toju-app/src/app/domains/custom-emoji/README.md`](../../toju-app/src/app/domains/custom-emoji/README.md). Chat composer integration: [`toju-app/src/app/domains/chat/README.md`](../../toju-app/src/app/domains/chat/README.md).
 
 ## Responsibilities
 
-- Own custom emoji asset validation, local persistence, user-saved library membership, shortcut ranking, and peer-to-peer asset sync.
-- Expose a shared picker consumed by chat message reactions and the chat composer.
-- Keep usage ranking local to the current user; usage counts are not synced.
-- Does not store custom emoji on the signaling server.
+- Validate uploads (size, MIME), persist image assets locally, and track per-user **saved library** membership.
+- Rank shortcuts by local usage (not synced across devices).
+- Sync assets P2P (`custom-emoji-*` envelopes) and proactively push referenced emoji when sending messages.
+- Relay the same envelopes on `account_sync` for multi-device library convergence.
+- Expose `CustomEmojiPickerComponent` for composer and reactions.
 
-## Key Concepts
+This area does **not** own:
 
-- **Custom emoji asset**: A user-created image stored as a data URL with id, name, mime, size, hash, creator, timestamps, and optional saved-library membership.
-- **Known custom emoji**: A synced asset available for message rendering and forwarding, but not shown in the current user's picker unless saved.
-- **Saved custom emoji**: A known asset the current user added to their library; saved emoji appear in the picker and shortcut ranking. Library membership is **user-bound, not client-bound** — it is tracked per signed-in user (keyed by user id), so a second account on the same device never inherits the first account's library.
-- **Emoji shortcut row**: The seven most-used emoji entries for the current user plus an eighth control that opens the full selector.
-- **Custom emoji token**: The stable message/reaction representation `:emoji[id](name)`, resolved locally to the synced image asset when rendering.
-- **Composer emoji alias**: The readable inline draft representation `:name:`. The composer rewrites known aliases to stable custom emoji tokens only when sending.
+- Message send/edit transport → [messaging.md](messaging.md).
+- Profile avatar bytes → `toju-app/src/app/domains/profile-avatar/README.md`.
+- Server-side storage (none).
 
-## Peer Envelope Contract
+## Key concepts
 
-Custom emoji uses `ChatEvent` data-channel envelopes:
+- **Custom emoji asset** — image with `id`, `name`, `mime`, `size`, `hash`, `creatorUserId`, `dataUrl` (or reconstructed from chunks).
+- **Known emoji** — synced for rendering; not necessarily in the picker.
+- **Saved emoji** — in the active user's library (`metoyou_custom_emoji_saved:<userId>`); shown in picker and shortcut row.
+- **Token** — stable wire form `:emoji[id](name)` in message/reaction bodies.
+- **Composer alias** — draft form `:name:` rewritten to a token on send when the name is known.
+- **Shortcut row** — seven most-used saved entries plus opener for full picker.
 
-- `custom-emoji-summary`: `{ customEmojiSummaries: [{ id, hash, updatedAt }] }`
-- `custom-emoji-request`: `{ ids: string[] }`
-- `custom-emoji-full`: `{ customEmojiTransfer: Omit<CustomEmoji, 'dataUrl'>, total: number }`
-- `custom-emoji-chunk`: `{ customEmojiId, index, total, data }`
+---
 
-When a peer connects, each side sends a summary of known assets. The receiver requests missing or stale emoji by id, and the owner replies with a small manifest followed by bounded base64 chunks using buffered peer sends. Creating a new emoji also streams that manifest and chunk sequence to every currently connected peer. Outgoing room chat messages, edits, reactions, and direct messages proactively push every referenced custom emoji asset to connected peers in parallel with the message event, so receivers do not wait for a request round-trip. Small assets that fit under `CUSTOM_EMOJI_INLINE_MAX_JSON_BYTES` travel inline in one `custom-emoji-full` event; larger assets use manifest plus chunks. Incoming chat messages and chat-sync batches still scan for `:emoji[id](name)` tokens and request any missing assets from the sender as a repair path. Full inline `customEmoji` payloads remain accepted for backward compatibility.
+## Peer envelope contract (P2P)
 
-## Business Rules
+| type | Payload |
+|------|---------|
+| `custom-emoji-summary` | `{ customEmojiSummaries: [{ id, hash, updatedAt }] }` |
+| `custom-emoji-request` | `{ ids: string[] }` |
+| `custom-emoji-full` | manifest (`customEmojiTransfer`) ± inline bytes |
+| `custom-emoji-chunk` | `{ customEmojiId, index, total, data }` base64 |
 
-- Uploads are capped at 1 MB.
-- Accepted image types match profile avatars: WebP, GIF, JPG, and JPEG.
-- Local shortcut ranking is keyed by the active user and includes Unicode emoji plus saved custom emoji only.
-- Saved-library membership is bound to the user, not the client: `CustomEmojiService` tracks the set of saved emoji ids per user id in `localStorage` (`metoyou_custom_emoji_saved:<userId>`, mirroring the per-user usage ranking). The picker shows only emoji in the active user's saved set, so signing in as a different account on the same client never exposes the previous account's library. On first load after this change the set is seeded from legacy `savedByUser` rows the user actually created (`creatorUserId === userId`), so creators keep their library while other local accounts stay empty.
-- Message rendering reserves inline emoji space with a transparent placeholder image while a referenced custom emoji asset is not yet available; deferred markdown placeholders rewrite tokens to readable `:name:` aliases so raw `:emoji[id](name)` text never flashes in chat.
-- Seen custom emoji are not added to the picker automatically; right-click a rendered custom emoji in chat or on a custom emoji reaction and choose **Add to emoji library** from the app context menu (`NativeContextMenuComponent`).
-- Saved custom emoji can be removed from the picker library by right-clicking them inside the emoji picker and choosing **Remove from emoji library**; the asset stays available for rendering messages that already reference it.
-- Emoji hosts are marked with `data-custom-emoji` / `data-custom-emoji-library` plus `data-custom-emoji-id` so the global context menu can distinguish them from regular images and suppress the default **Copy Image** action.
-- The full emoji picker includes a search field that filters built-in Unicode emoji by common terms and saved custom emoji by name.
-- Custom emoji data-channel chunks are capped below typical SCTP message limits; back-pressure alone is not enough because a single oversized send can fire `RTCDataChannel.onerror`.
-- Completed transfers are persisted only when the reconstructed data URL matches the manifest size and hash; corrupt local rows are dropped before summaries are advertised.
+**Handshake:** on peer connect both sides send summaries; receiver requests stale/missing ids; owner sends manifest then chunked payloads via buffered sends.
 
-## Data Access
+**Proactive push:** outgoing chat/DM messages scan for tokens and push assets to connected peers in parallel with the message event.
 
-- Browser runtime stores custom emoji image assets in IndexedDB store `customEmojis` (per-user database scope).
-- Electron runtime stores custom emoji image assets in SQLite table `custom_emojis`, created by migration `1000000000011-AddCustomEmojis` (a single shared desktop database).
-- Renderer access goes through `DatabaseService` methods `saveCustomEmoji`, `getCustomEmojis`, and `deleteCustomEmoji`. These persist the image **assets** only; they are not scoped per user (the Electron table is shared across local accounts). Per-user **library membership** lives separately in `localStorage` (`metoyou_custom_emoji_saved:<userId>`), which is what keeps the picker user-bound even on a shared client database.
+**Inline threshold:** assets ≤ `CUSTOM_EMOJI_INLINE_MAX_JSON_BYTES` (48 KiB) ship in one `custom-emoji-full`; larger assets use manifest + chunks.
+
+**Repair path:** incoming messages and `chat-sync-batch` scan for tokens and request missing assets from the sender.
+
+### Multi-device (`account_sync`)
+
+Relayable types (`account-sync.rules.ts`): `custom-emoji-summary`, `custom-emoji-request`, `custom-emoji-full`, `custom-emoji-chunk`. See [signaling.md](signaling.md) and [authentication.md](authentication.md).
+
+---
+
+## Business rules and invariants
+
+- Max upload **1 MB**; MIME: WebP, GIF, JPEG/JPG (same set as profile avatars).
+- Library membership is **per user id**, not per device — second account on same machine does not inherit another user's saved set.
+- Seeing an emoji in chat does **not** add it to the library; user must **Add to emoji library** from context menu.
+- Remove from library hides picker entry but keeps asset for messages that already reference it.
+- Chunks stay below SCTP-safe sizes; oversized single sends can trigger `RTCDataChannel.onerror` even when back-pressure is idle.
+- Persist only when reconstructed `dataUrl` matches manifest **size and hash**; corrupt rows are dropped before advertising summaries.
+- Placeholder rendering avoids flashing raw tokens while assets are in flight.
+
+---
+
+## Storage
+
+| Runtime | Asset bytes | Library membership |
+|---------|-------------|-------------------|
+| Browser | IndexedDB `customEmojis` (per-user DB scope) | `localStorage` `metoyou_custom_emoji_saved:<userId>` |
+| Electron | SQLite `custom_emojis` (shared desktop DB) | same localStorage key |
+| Capacitor | SQLite `custom_emojis` in `metoyou__<userId>` | same localStorage key |
+
+API: `DatabaseService.saveCustomEmoji` / `getCustomEmojis` / `deleteCustomEmoji`.
+
+---
+
+## Technical implementation
+
+- Rules: `domains/custom-emoji/domain/custom-emoji.rules.ts`
+- Service: `CustomEmojiService`; effects: `CustomEmojiSyncEffects`
+- Picker: `feature/custom-emoji-picker/`
+- Context menu: `data-custom-emoji` / `data-custom-emoji-library` attributes on rendered hosts
+
+---
 
 ## Testing
 
-- Unit tests cover upload size validation, shortcut selection, picker search filtering, custom emoji token generation, data-channel chunk splitting, readable composer alias rewriting, transfer integrity, saved-library membership, and add/remove library context-menu actions.
+- `custom-emoji.rules.spec.ts`, `custom-emoji.service.spec.ts`, `custom-emoji-picker.component.spec.ts`
+- `account-sync.rules.spec.ts` (relayable types)
+- E2E: `e2e/tests/chat/custom-emoji-user-binding.spec.ts`
 
-## Security Considerations
+---
 
-- Emoji payloads are image-only and size-limited before persistence or broadcast.
-- Assets sync only to already connected peers; the signaling server does not persist or proxy emoji images.
+## Security considerations
+
+- Image-only, size-capped payloads before persist or broadcast.
+- Assets reach only connected peers (or same-account devices via `account_sync`); server never proxies bytes.
+
+---
+
+## Known limitations
+
+- Usage counts and shortcut ranking are **local only**.
+- Electron asset table is **shared across OS users** on one desktop install; library keys remain per MetoYou user id.
+
+---
+
+## Related features
+
+- [messaging.md](messaging.md) — tokens in message bodies, proactive push on send
+- [signaling.md](signaling.md) — `account_sync`
+- [mobile-capacitor.md](mobile-capacitor.md) — Capacitor SQLite path
+
+## Changelog
+
+| Date | Change |
+|------|--------|
+| 2026-07-05 | Restructured to match messaging doc style; fixed duplicate sections; Capacitor + account_sync |

agents-docs/features/desktop-local-api.md

@@ -0,0 +1,53 @@
+# Desktop Local API
+
+> **Status:** Active
+> **Last updated:** 2026-07-05
+
+## Overview
+
+Electron hosts an optional **localhost HTTP API** that exposes read-only access to the local SQLite database, proxies login to allowed signaling servers, and serves bundled Docusaurus documentation offline.
+
+## Responsibilities
+
+| Layer | Owns |
+|-------|------|
+| Electron `api/router.ts` | HTTP routes, bearer token store, CQRS query dispatch |
+| Desktop settings | Enable/disable Local API, port, allowed signal servers |
+| `docs-site` build | Static bundle mounted at `/docusaurus/*` |
+
+## Trust boundary
+
+Separate **in-memory bearer tokens** from signaling-server session tokens. Login via Local API issues a local token; read routes require `Authorization: Bearer`. See [authentication.md](authentication.md).
+
+## Routes (summary)
+
+| Method | Path | Auth | Purpose |
+|--------|------|------|---------|
+| GET | `/api/health` | No | Local API liveness |
+| GET | `/api/openapi.json`, `/docs`, `/scalar/api-reference.js` | No | API docs (Scalar) |
+| GET | `/docusaurus/*` | No | In-app documentation site |
+| POST | `/api/auth/login` | No | Proxy to configured signaling server; returns local bearer |
+| POST | `/api/auth/logout` | Bearer | Revoke local token |
+| GET | `/api/profile` | Bearer | Current user profile |
+| GET | `/api/rooms`, `/api/rooms/{roomId}`, `.../users`, `.../messages`, `.../bans` | Bearer | Read-only room data |
+| GET | `/api/messages/{messageId}`, `.../reactions`, `.../attachments` | Bearer | Message graph |
+| GET | `/api/users/{userId}`, `/api/attachments`, `/api/plugin-data` | Bearer | User + plugin data reads |
+| GET | `/api/meta/{key}` | Bearer | Meta key lookup |
+
+Database routes return **503** when SQLite is not initialised.
+
+## IPC
+
+- `get-local-api-status`, `open-local-api-docs`, `open-docusaurus-docs`
+
+## Related
+
+- [authentication.md](authentication.md) — trust table
+- `electron/CONTEXT.md` — Local API vocabulary
+- `docs-site/CONTEXT.md` — documentation bundle
+
+## Changelog
+
+| Date | Change |
+|------|--------|
+| 2026-07-05 | Initial Local API route catalog |

agents-docs/features/direct-messaging.md

@@ -0,0 +1,29 @@
+# Direct Messaging
+
+> **Area:** messaging
+> **Status:** Active
+> **Last updated:** 2026-07-05
+
+## Overview
+
+Direct messaging (1:1 and group PMs) is documented in full in **[messaging.md](messaging.md)** — transports, delivery state machine, sync protocol, storage, and security. This file remains as an index entry in [FEATURES.md](../FEATURES.md).
+
+## Quick reference
+
+- **Domain:** `toju-app/src/app/domains/direct-message/`
+- **Entry points:** `DirectMessageService`, `PeerDeliveryService`, `FriendService`
+- **Persistence:** `metoyou_direct_message_*` (per-user local storage)
+- **P2P types:** `direct-message`, `direct-message-status`, `direct-message-mutation`, `direct-message-typing`, `direct-message-sync-request`, `direct-message-sync`
+- **Calls:** `direct-call` shares `PeerDeliveryService` → [voice-webrtc.md](voice-webrtc.md)
+
+## Related
+
+- [messaging.md](messaging.md) — full cross-context contract
+- [signaling.md](signaling.md) — WebSocket relay
+- Domain README: [`toju-app/src/app/domains/direct-message/README.md`](../../toju-app/src/app/domains/direct-message/README.md)
+
+## Changelog
+
+| Date | Change |
+|------|--------|
+| 2026-07-05 | Slimmed to index; comprehensive content moved to messaging.md |

agents-docs/features/game-activity.md

@@ -0,0 +1,54 @@
+# Game Activity
+
+> **Status:** Active
+> **Last updated:** 2026-07-05
+
+## Overview
+
+"Now playing" game detection: Electron foreground-window/process heuristics, RAWG metadata match via signaling server, and P2P `game-activity` broadcast to peers. Shown on profile cards and room sidebars.
+
+## Responsibilities
+
+| Layer | Owns |
+|-------|------|
+| `game-activity` domain | Scan loop, confidence scoring, P2P broadcast, user store updates |
+| Electron IPC | `get-running-process-names`, `get-active-game-candidate` |
+| Signaling server | `POST /api/games/match` (RAWG proxy + miss cache) |
+| P2P | `game-activity` data-channel event |
+
+## Server API
+
+### `POST /api/games/match`
+
+- **Auth:** Public
+- **Body:** `{ processNames: string[], candidates?: { processName, score }[] }` (bounded list sizes)
+- **Response:** `{ game: MatchedGame | null }` — RAWG-backed title, cover art, store links
+
+Misses cached in server SQLite (`GameMatchMiss`) to limit API calls.
+
+## Client detection
+
+- Periodic scan (default 10 s, configurable 5–60 s in localStorage `metoyou_game_scan_interval_ms`).
+- Ignores launcher/helper processes via `IGNORED_PROCESS_NAMES` and regex patterns.
+- **Electron:** suppresses scan when MetoYou window is focused; prefers foreground-window candidate from `get-active-game-candidate`.
+- **Browser/Capacitor:** no process scan — activity only from P2P peers.
+
+## P2P event
+
+```json
+{ "type": "game-activity", "activity": { "game", "startedAt", "processName", ... } }
+```
+
+Peers merge into `User.gameActivity` in NgRx store.
+
+## Related
+
+- [signaling.md](signaling.md) — not WS-relayed
+- [server-directory.md](server-directory.md) — API base URL for match endpoint
+- Domain README: [`toju-app/src/app/domains/game-activity/README.md`](../../toju-app/src/app/domains/game-activity/README.md)
+
+## Changelog
+
+| Date | Change |
+|------|--------|
+| 2026-07-05 | Initial cross-context game-activity contract |

agents-docs/features/invites-join-requests.md

@@ -0,0 +1,65 @@
+# Invites & Join Requests
+
+> **Status:** Active
+> **Last updated:** 2026-07-05
+
+## Overview
+
+Invite links and join-request approval let users join private or moderated chat-servers without public listing. Spans signaling **server** REST + HTML invite pages and the product **client** `server-directory` invite feature.
+
+## Responsibilities
+
+- Server: create time-limited invites, resolve invite metadata, record join requests, notify requesters on moderation decisions.
+- Client: create/copy invite links, render invite landing UX, call join API with invite codes/passwords.
+- It does NOT own: WebSocket room membership (`join_server` after REST join succeeds).
+
+## Key concepts
+
+- **Invite:** opaque id mapping to a server; may expire.
+- **Join request:** pending membership when server requires approval.
+- **request_update:** server-pushed WebSocket notification when a moderator approves/denies.
+
+## REST API
+
+### Invites
+
+| Method | Path | Auth | Purpose |
+|--------|------|------|---------|
+| POST | `/api/servers/:id/invites` | Bearer | Create invite (moderator) |
+| GET | `/api/invites/:id` | Public | Resolve invite metadata + server card |
+| GET | `/invite/:id` | Public | HTML invite landing page (browser) |
+
+### Join
+
+| Method | Path | Auth | Purpose |
+|--------|------|------|---------|
+| POST | `/api/servers/:id/join` | Bearer | Join with password, invite id, or public access; may create join request |
+
+### Join requests (moderation)
+
+| Method | Path | Auth | Purpose |
+|--------|------|------|---------|
+| GET | `/api/servers/:id/requests` | Bearer (`manageServer`) | List pending requests |
+| PUT | `/api/requests/:id` | Bearer (`manageServer`) | Approve or deny; body `{ status }` |
+
+`PUT /api/requests/:id` validates optional `ownerId` matches authenticated user, checks `manageServer` permission, updates status, and sends `notifyUser(request.userId, { type: 'request_update', request })`.
+
+## Client flow
+
+1. Moderator creates invite via `ServerDirectoryFacade.createInvite()`.
+2. Recipient opens `/invite/:id` or deep link; client resolves `GET /api/invites/:id`.
+3. Authenticated user calls `POST /api/servers/:id/join` with invite payload.
+4. On approval-required servers, user waits for `request_update` or polls requests list (moderator UI).
+
+## Related
+
+- [server-directory.md](server-directory.md) — join/leave REST
+- [authentication.md](authentication.md) — bearer on mutations
+- [signaling.md](signaling.md) — `join_server` after join
+- Domain README: [`toju-app/src/app/domains/server-directory/README.md`](../../toju-app/src/app/domains/server-directory/README.md)
+
+## Changelog
+
+| Date | Change |
+|------|--------|
+| 2026-07-05 | Initial cross-context invite/join-request contract |

agents-docs/features/klipy-gifs.md

@@ -0,0 +1,44 @@
+# Klipy GIFs
+
+> **Status:** Active
+> **Last updated:** 2026-07-05
+
+## Overview
+
+GIF search in chat and DM composers via a **Klipy API proxy** on the signaling server. API keys stay server-side; clients call same-origin routes on the active signal server.
+
+## Responsibilities
+
+- Server: proxy/search Klipy API (`variables.json` `klipyApiKey`).
+- Client `chat` domain: `KlipyService`, composer picker; DMs reuse the same integration.
+
+## API
+
+### `GET /api/klipy/config`
+
+- **Auth:** Public
+- **Response:** `{ enabled: boolean }` — `enabled` when server has a configured API key
+
+### `GET /api/klipy/gifs`
+
+- **Auth:** Public
+- **Query:** `q` (search), `page`, `per_page` (default 24, max 50)
+- **Response:** Normalised `{ gifs: [{ id, slug, title, url, previewUrl, width, height }], hasNext }`
+- **Upstream:** `https://api.klipy.com/api/v1` with 8 s timeout
+
+## Client behavior
+
+- GIF picker visibility is resolved against the **current chat-server's** signal server (not a global offline endpoint) so KLIPY availability matches the room's backend.
+- Selected GIFs send as markdown image messages; rendering uses [link-preview-media-proxy.md](link-preview-media-proxy.md) image proxy when needed.
+
+## Related
+
+- [server-directory.md](server-directory.md) — per-room signal server for config
+- [direct-messaging.md](direct-messaging.md) — DM composer reuse
+- Domain README: [`toju-app/src/app/domains/chat/README.md`](../../toju-app/src/app/domains/chat/README.md)
+
+## Changelog
+
+| Date | Change |
+|------|--------|
+| 2026-07-05 | Initial Klipy proxy contract |

agents-docs/features/link-preview-media-proxy.md

@@ -0,0 +1,46 @@
+# Link Preview & Media Proxy
+
+> **Status:** Active
+> **Last updated:** 2026-07-05
+
+## Overview
+
+The signaling server fetches untrusted URLs on behalf of clients for **link embed previews** and **image proxying**, with SSRF guards. Chat and DM composers render embeds using these endpoints.
+
+## Responsibilities
+
+- Server: outbound fetch with host validation, caching, size limits.
+- Client `chat` domain: request metadata when messages contain URLs; render cards in message list.
+- It does NOT store embeds long-term on the server beyond in-memory cache.
+
+## API
+
+### `GET /api/link-metadata`
+
+- **Auth:** Public
+- **Query:** `url` (http/https)
+- **Response:** `{ title?, description?, imageUrl?, siteName? }`
+- **Guards:** `resolveAndValidateHost` + `safeFetch`; 8 s timeout; HTML capped at 512 KB; in-memory cache sized by `variables.json` link-preview config
+
+### `GET /api/image-proxy`
+
+- **Auth:** Public
+- **Query:** `url` (http/https)
+- **Response:** Raw image bytes (`Content-Type` from origin)
+- **Limits:** image/* only; max 8 MB; 8 s timeout; SSRF validation
+- **Cache:** `Cache-Control: public, max-age=3600`
+
+## Client usage
+
+Message markdown / link-embed pipeline calls link-metadata for unfurling; proxied images load through `/api/image-proxy` when direct fetch would fail (CORS, mixed content).
+
+## Related
+
+- [server-directory.md](server-directory.md) — requests use active server's API base
+- Domain README: [`toju-app/src/app/domains/chat/README.md`](../../toju-app/src/app/domains/chat/README.md)
+
+## Changelog
+
+| Date | Change |
+|------|--------|
+| 2026-07-05 | Initial link preview / image proxy contract |

agents-docs/features/message-integrity.md

@@ -1,6 +1,14 @@
 # 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.
+> **Area:** messaging
+> **Status:** Active
+> **Last updated:** 2026-07-05
+
+## Overview
+
+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 (`revision`, `headHash`) and `message-revision` events.
+
+Parent transport and sync context: [messaging.md](messaging.md).
 
 ## Responsibilities
 
@@ -15,7 +23,7 @@ Signed, append-only **message revisions** give P2P chat a verifiable history wit
 | --- | --- |
 | 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) |
+| Electron / mobile persistence | `revision` + `headHash` on message rows; revision audit log in IDB store (browser), SQLite `meta` table (Electron **and Capacitor** — keys `message-revision:<messageId>:<revision>`) |
 
 Plugin API messages may emit unsigned revisions (`plugin-edit` / `plugin-delete`) when the actor is a synthetic plugin user.
 
@@ -47,7 +55,23 @@ Plugin API messages may emit unsigned revisions (`plugin-edit` / `plugin-delete`
 | `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`.
+Registration runs automatically after **home** login/register via `AuthenticationService` — see [authentication.md](authentication.md) for foreign-server scope.
+
+## Multi-device relay (`account_sync`)
+
+`message-revision` chat events are relayable to sibling connections via WebSocket `account_sync` (alongside legacy `chat-message` paths documented in [authentication.md](authentication.md)). Inventory convergence still prefers P2P data-channel sync when peers are connected.
+
+## Related
+
+- [authentication.md](authentication.md) — signing-key registration, `account_sync` chat batches
+- [signaling.md](signaling.md) — `account_sync` envelope
+- [mobile-capacitor.md](mobile-capacitor.md) — Capacitor `meta` revision keys
+
+## Changelog
+
+| Date | Change |
+|------|--------|
+| 2026-07-05 | Capacitor meta persistence; account_sync cross-ref; signing registration scope |
 
 ## Degraded-mode behavior
 

agents-docs/features/messaging.md

@@ -0,0 +1,209 @@
+# Messaging
+
+> **Area:** messaging
+> **Status:** Active
+> **Last updated:** 2026-07-13
+
+## Overview
+
+Messaging in MetoYou covers two transports that share inventory-sync concepts and (for DMs) a monotonic delivery state machine. **Server-channel chat** is broadcast by the signaling server over WebSocket (`chat_message`) as a narrow fallback when P2P data channels are down — the server does not persist message bodies. **Direct messages** (1:1 and group DMs) are primarily peer-to-peer over the WebRTC ordered data channel, with WebSocket signaling relay when no channel is open and an offline queue when neither path succeeds.
+
+On both transports the client maintains local history (Electron SQLite / browser IndexedDB for server channels; user-scoped `localStorage` for DMs) and a **chunked inventory-sync protocol** so peers reconcile missing rows without flooding the link.
+
+This document is the cross-context contract: envelope names, sync protocol, delivery states, edit/delete rules, and storage boundaries. Internal NgRx orchestration lives in [`toju-app/src/app/domains/chat/README.md`](../../toju-app/src/app/domains/chat/README.md) and [`toju-app/src/app/domains/direct-message/README.md`](../../toju-app/src/app/domains/direct-message/README.md). WebSocket relay rules: [signaling.md](signaling.md). Signed revision chains: [message-integrity.md](message-integrity.md).
+
+## Responsibilities
+
+- Send server-channel chat over WebSocket fallback (`chat_message`) and primarily over P2P (`chat-message`, `edit-message`, `delete-message`, `message-revision`).
+- Send, edit, delete, and react in direct messages over the data channel with signaling fallback.
+- Carry typing indicators: server channels (`typing` → `user_typing`) and DMs (`direct-message-typing`).
+- Reconcile peer history via the inventory protocol (`chat-inventory` / `chat-sync-batch`; DM `direct-message-sync`).
+- Drive a monotonic DM delivery state machine: `QUEUED → SENT → DELIVERED → ACKNOWLEDGED`.
+- Relay multi-device chat via `account_sync` (`chat-message`, `message-revision`, `chat-sync-batch`).
+
+This area does **not** own:
+
+- Attachment payloads or chunked file transfer → [attachments.md](attachments.md).
+- WebRTC session setup and data-channel lifecycle → [voice-webrtc.md](voice-webrtc.md).
+- Write permission resolution (`writeMessages`, `manageMessages`, bans) → `toju-app/src/app/domains/access-control/README.md`.
+- Full WebSocket envelope catalog (identity, voice, plugins) → [signaling.md](signaling.md).
+
+## Key concepts
+
+- **Server-channel message** — room-scoped text in a saved chat-server. Primary path: P2P `chat-message` on the data channel. Fallback: server broadcasts `chat_message` to other connections in the room.
+- **Direct message** — 1:1 or group PM. Persisted per user under `metoyou_direct_message_*` keys (domain-owned storage, not the global messages CQRS table).
+- **Conversation** — DM thread (`direct` or `group`). Upgrading a 1:1 call to a group creates a **new** group conversation; the original 1:1 history is not copied.
+- **Inventory event** — `chat-inventory` (P2P): sender announces message ids plus integrity fields (`ts`, `rc`, `ac`, `revision`, `headHash`); receiver requests missing or stale ids.
+- **Sync batch** — `chat-sync-batch`: chunked response, **200 messages per envelope** (`CHUNK_SIZE` in `message-sync.rules.ts`).
+- **Delivery state** — DM-only enum: `QUEUED (0) → SENT (1) → DELIVERED (2) → ACKNOWLEDGED (3)`. Advanced only via `advanceDirectMessageStatus` (never backwards).
+- **Peer delivery** — `PeerDeliveryService` tries data channel, then signaling forward, then offline queue.
+
+---
+
+## Transports
+
+### Server-channel chat
+
+**P2P (primary):** `chat-message`, `edit-message`, `delete-message`, `message-revision`, reactions, and inventory events on the ordered data channel. See [message-integrity.md](message-integrity.md) for dual-emit revision behavior.
+
+**WebSocket (fallback):** Client sends `chat_message`; `handleChatMessage` (`server/src/websocket/handler.ts`) broadcasts to other connections in the room. The server does **not** handle `edit_message` or `delete_message` on the wire — edits and deletes are P2P (and `account_sync` for sibling devices).
+
+**Typing:** Client sends `typing`; server broadcasts `user_typing` (transient, no persistence).
+
+**Multi-device:** Sibling tabs receive live chat via `account_sync` payloads (`chat-message`, `message-revision`, `chat-sync-batch`). See [authentication.md](authentication.md).
+
+### Direct messages
+
+**P2P (primary):** Events on the shared ordered data channel (same peer connections as voice/chat).
+
+**WebSocket (fallback):** `PeerDeliveryService.sendViaSignaling` forwards these types to `targetUserId` without requiring shared server membership:
+
+| type | Purpose |
+|------|---------|
+| `direct-message` | New message |
+| `direct-message-status` | Delivery / ack |
+| `direct-message-mutation` | Edit, delete, reactions |
+| `direct-message-typing` | Typing indicator |
+| `direct-message-sync-request` | Request snapshot |
+| `direct-message-sync` | Bounded history merge |
+
+**Offline queue:** When both paths fail, `OfflineMessageQueueService` retains message ids; replay runs on `peerConnected$` / `networkRestored$` (no scheduled retry timer).
+
+### Storage
+
+| Data | Where |
+|------|--------|
+| Server-channel messages | `DatabaseService` → Electron SQLite or browser IndexedDB (`messages` store) |
+| Direct messages | `metoyou_direct_message_*` via direct-message repositories |
+| Signaling server | **No message bytes** — broadcast/relay only |
+
+---
+
+## Inventory / sync protocol
+
+Shared shapes in `toju-app/src/app/shared-kernel/chat-events.ts`:
+
+| Event | Role |
+|-------|------|
+| `chat-inventory-request` | Ask peer for inventory |
+| `chat-inventory` | Announce ids + integrity snapshots |
+| `chat-sync-request` | Request specific missing ids |
+| `chat-sync-batch` | Up to **200** messages per envelope |
+| `direct-message-sync-request` / `direct-message-sync` | DM-scoped snapshot merge |
+
+Rules (`message-sync.rules.ts`, `message-integrity.rules.ts`):
+
+- Merges are **additive** — sparser peers never wipe richer local history.
+- `findMissingIds` compares remote inventory to local `revision` / `headHash` (and legacy `ts` / `rc` / `ac`).
+- `INVENTORY_LIMIT` = 1_000_000 (safety ceiling for pathological rooms).
+- Sync polling: 10 s when catching up, 15 min after a clean cycle (`SYNC_POLL_FAST_MS` / `SYNC_POLL_SLOW_MS`).
+
+---
+
+## Delivery state machine (DMs only)
+
+| Value | Numeric | Meaning |
+|-------|---------|---------|
+| `QUEUED` | 0 | Composed locally; no successful send yet |
+| `SENT` | 1 | Data channel or signaling forward accepted the payload |
+| `DELIVERED` | 2 | At least one recipient acknowledged receipt |
+| `ACKNOWLEDGED` | 3 | Full recipient set acknowledged (1:1: the peer; group: every participant) |
+
+`advanceDirectMessageStatus` only moves forward (`direct-message.logic.ts`). Server-channel messages have no application-level delivery enum; the UI treats them as sent once the transport accepts the event.
+
+---
+
+## Edit and delete
+
+**Server channels:** Outgoing edits check `canEditMessage(message, userId)` before broadcast. Incoming P2P `edit-message` / `delete-message` merge via NgRx handlers; signed paths prefer `message-revision` when integrity is enabled.
+
+**DMs:** `direct-message-mutation` with types `edit`, `delete`, `reaction-add`, `reaction-remove`. `applyMutation` in `DirectMessageService` updates by `messageId` but **does not verify** the mutator is the original author — a non-cooperating peer could mutate another user's row. Server chat enforces authorship on **outgoing** edits only.
+
+Deletes keep tombstone semantics (`isDeleted`, empty `content`) so inventory sync can converge.
+
+---
+
+## Business rules and invariants
+
+- The signaling server is **not authoritative** for message content — it relays `chat_message` and DM types opaquely.
+- DM events are **ignored** unless the local user is in `recipients` / `participants` or already has the conversation locally.
+- Recipient matching (DM **and** `direct-call`) must accept **every local identity alias** — home id, entity id, peer id, and each provisioned signal-server actor id from `SignalServerCredentialStoreService` — because senders who met the recipient on a foreign signal server address them by the provisioned actor id (`direct-message-identity.rules.ts`, `direct-call-participant-identity.rules.ts`).
+- DM status transitions are **monotonic**.
+- Inventory merges never downgrade a row with a newer `revision` / `headHash`.
+- 1:1 → group upgrade **does not copy** private history into the new group thread.
+- Unread counts are **idempotent by message id** — re-sync does not double-increment.
+- Incoming DMs raise a system notification via `NotificationsFacade.handleIncomingDirectMessage` (title = sender name; `shouldDeliverDirectMessageNotification` suppresses only when the conversation is on screen in an active window, notifications are disabled, or the user is busy). System messages (e.g. call-started) and deletions never notify. On Capacitor this flows through the same `DesktopNotificationService` → LocalNotifications routing as server chat.
+
+---
+
+## Technical implementation
+
+### Server
+
+- `server/src/websocket/handler.ts` — `handleChatMessage`, `handleTyping`, DM forward via `forwardRtcMessage` / `DIRECT_SIGNALING_TYPES`.
+- No message CQRS or entities on the server.
+
+### Product client
+
+| Area | Location |
+|------|----------|
+| Server chat effects / handlers | `store/messages/`, `domains/chat/` |
+| DM service / queue | `domains/direct-message/application/services/` |
+| Sync rules | `domains/chat/domain/rules/message-sync.rules.ts` |
+| Wire types | `shared-kernel/chat-events.ts`, `direct-message-contracts.ts` |
+| Account sync relay | `infrastructure/realtime/account-sync/` |
+
+### Electron
+
+- Server-channel rows: TypeORM `Message` entity + CQRS `save-message` / `delete-message`.
+- DMs: renderer `localStorage` repositories (not the main message table).
+
+---
+
+## Testing
+
+- Unit: `message-sync.rules.spec.ts`, `message-integrity.rules.spec.ts`, `message.rules.spec.ts`, `direct-message.service.spec.ts`, `direct-message.logic` specs, `messages-incoming.handlers.spec.ts`, `account-sync-chat.helper.spec.ts`.
+- E2E: `e2e/tests/chat/chat-message-features.spec.ts`, `multi-client-chat-sync.spec.ts`, `dm-flow.spec.ts`, `multi-device-attachment-sharing.spec.ts`, `e2e/tests/voice/dm-header-call-ring.spec.ts` (DM-header call ring, incl. cross-signal actor-id addressing).
+
+---
+
+## Performance considerations
+
+- Sync batches: **200 messages per `chat-sync-batch` envelope**.
+- `chat_message` broadcast is O(connections in room) per send.
+- Group DMs: O(recipients) transport attempts per message.
+
+---
+
+## Security considerations
+
+- **No end-to-end encryption** for message bodies. WebRTC data channels use DTLS; signaling fallback is TLS WebSocket; local DBs store plaintext.
+- **DM `applyMutation` does not verify authorship** on incoming mutations.
+- **No server-side rate limit** on `chat_message` volume.
+
+---
+
+## Known issues and limitations
+
+- **No server-side chat log** — late joiners depend on peers with local history or `account_sync` from a sibling device.
+- **DM mutation authorship** not verified on receive.
+- **Offline queue** replays only on peer connect / network restore events.
+
+---
+
+## Related features
+
+- [signaling.md](signaling.md) — WebSocket relay and ordering invariants
+- [message-integrity.md](message-integrity.md) — signed revision chains
+- [attachments.md](attachments.md) — file payloads alongside chat events
+- [voice-webrtc.md](voice-webrtc.md) — data channel transport
+- [authentication.md](authentication.md) — `account_sync` multi-device relay
+- [direct-messaging.md](direct-messaging.md) — short index (defers here)
+
+## Changelog
+
+| Date | Change |
+|------|--------|
+| 2026-07-13 | Incoming DMs raise system notifications through the notifications domain (previously unread-badge only) |
+| 2026-07-13 | Recipient matching for DM and `direct-call` events must span all local identity aliases (provisioned actor ids included) |
+| 2026-07-05 | Initial comprehensive messaging contract (replaces thin direct-messaging summary) |

agents-docs/features/mobile-capacitor.md

@@ -31,10 +31,6 @@ npm run cap:sync
 npm run cap:open:android
 npm run cap:open:ios
 
-### Linux: Android Studio path
-
-Capacitor defaults to `/usr/local/android-studio/bin/studio.sh`. If Android Studio is installed elsewhere (common with **Flatpak** from Flathub), `npm run cap:open:android` uses `tools/resolve-android-studio-path.js` to locate `studio.sh` (Flatpak `active` symlink, Toolbox, snap, `/opt`, etc.). Override anytime with `CAPACITOR_ANDROID_STUDIO_PATH`.
-
 # Convenience (build + sync + open)
 npm run cap:build:android
 npm run cap:build:ios
@@ -44,6 +40,10 @@ npm run cap:apk:android
 # → toju-app/android/app/build/outputs/apk/debug/app-debug.apk
 ```
 
+### Linux: Android Studio path
+
+Capacitor defaults to `/usr/local/android-studio/bin/studio.sh`. If Android Studio is installed elsewhere (common with **Flatpak** from Flathub), `npm run cap:open:android` uses `tools/resolve-android-studio-path.js` to locate `studio.sh` (Flatpak `active` symlink, Toolbox, snap, `/opt`, etc.). Override anytime with `CAPACITOR_ANDROID_STUDIO_PATH`.
+
 Config: `toju-app/capacitor.config.ts` (`webDir: ../dist/client/browser`).
 
 ### CI (Gitea)
@@ -85,13 +85,15 @@ Re-run `npm run cap:assets:android` whenever `images/icon-new-rounded.png` chang
 | Feature | Status | Notes |
 |---------|--------|-------|
 | Push/local notifications | **Working (partial)** | Local notifications always available; remote push (FCM/APNs) registers only when Firebase/APNs is configured — app starts normally without `google-services.json` |
+| Chat message notifications | **Working** | `DesktopNotificationService` routes to `MobileNotificationsService.showMessage()` on Capacitor (LocalNotifications channel `toju-messages`); web `Notification` API is never used on native shells |
 | Server push dispatch | **Working (configured)** | Tokens persist in server SQLite; outbound FCM/APNs via env credentials |
 | In-call notifications | **Working (Capacitor)** | Persistent notification with answer/mute/hang-up actions |
 | Stream pop-out (PiP) | **Working (partial)** | Document PiP when WebView supports it; Android native PiP fallback via `MetoyouMobile` plugin |
 | Background voice | **Working (partial)** | Android foreground service; iOS `UIBackgroundModes` audio + CallKit active-call bridge |
 | iOS CallKit | **Working (partial)** | `MetoyouMobile.startCallKitSession` reports active calls; requires Xcode target wiring after `cap:sync` |
-| Screensharing | **Limited** | Disabled on iOS WebView; Android `getDisplayMedia` may work |
+| Screensharing | **Hidden on native mobile** | `getDisplayMedia` is unavailable in mobile WebViews; all screen-share buttons (private call, voice controls, floating controls, voice workspace) are gated behind `!viewport.isMobile() && !MobilePlatformService.isNativeMobile()` |
 | Composer attachments | **Working** | Mobile attachment button + hidden file input |
+| Attachment download/export | **Working** | `AttachmentDownloadService` delegates to `CapacitorAttachmentExportService` on native shells: copies disk-backed files (or fetches the object URL) into the public `Documents` directory with a timestamped name; anchor `download` links do nothing in the Android WebView |
 | Camera sharing | **Working** | Existing `getUserMedia` camera path in WebRTC stack |
 | Speakerphone | **Working (partial)** | Android `AudioManager` via `MetoyouMobile`; iOS `@capgo/capacitor-audio-session`; direct-call speaker toggle on native mobile |
 | Local DB (SQLite) | **Working** | `DatabaseService` routes Capacitor shells to `CapacitorDatabaseService` (native SQLite CRUD) |
@@ -103,7 +105,7 @@ Re-run `npm run cap:assets:android` whenever `images/icon-new-rounded.png` chang
 - **iOS CallKit:** Plugin Swift source ships in `ios/App/App/MetoyouMobilePlugin.swift`; add it to the Xcode target if not auto-linked. Incoming-call UI is not fully bridged to WebRTC answer/hang-up yet.
 - **iOS screenshare:** `getDisplayMedia` is not available in WKWebView.
 - **Android PiP:** Native PiP enters activity-level PiP; WebView video may not always render inside PiP on all OEM WebViews.
-- **Production discovery:** `signal.toju.app` may not expose `/api/servers/featured` or `/trending`; client skips those calls for known hosts.
+- **Legacy discovery endpoints:** Older signal servers may not expose `/api/servers/featured` or `/trending` (they resolve as `/servers/:id` and return 404). The client still calls those routes on every online endpoint and **falls back per-endpoint to `GET /api/servers`** when 404 is returned — see [server-discovery.md](server-discovery.md).
 - **Push delivery:** Requires FCM service account and APNs key configuration on the signaling server.
 
 ## Push notification setup (FCM / APNs)
@@ -133,8 +135,11 @@ Declared in `toju-app/android/app/src/main/AndroidManifest.xml`:
 | `BLUETOOTH_CONNECT` | Bluetooth headset routing during calls (Android 12+) |
 | `POST_NOTIFICATIONS` | Incoming/active call notifications |
 | `FOREGROUND_SERVICE` / `FOREGROUND_SERVICE_MICROPHONE` | Background voice session |
+| `READ_EXTERNAL_STORAGE` (maxSdk 32) / `WRITE_EXTERNAL_STORAGE` (maxSdk 29) | Attachment export to public `Documents` on Android 10 and below |
 
-Before WebRTC capture, the client calls `MobileMediaService.ensureVoiceCapturePermissions()` / `ensureCameraCapturePermissions()`, which delegate to `MetoyouMobile.requestVoiceCapturePermissions()` / `requestCameraCapturePermissions()` on Capacitor shells. If the native plugin is unavailable or the bridge call fails, capture preflight defers to the WebView `getUserMedia` permission flow instead of aborting voice/camera joins.
+Before WebRTC capture, the client calls `MobileMediaService.ensureVoiceCapturePermissions()` / `ensureCameraCapturePermissions()`, which delegate to `MetoyouMobile.requestVoiceCapturePermissions()` / `requestCameraCapturePermissions()` on Capacitor shells. If the native plugin is unavailable or the bridge call fails, capture preflight defers to the WebView `getUserMedia` permission flow instead of aborting voice/camera joins. Preflight only blocks capture on an explicit native `denied` state (`mobile-media-permission.rules.ts`); a `prompt` state is deferred to the WebView so the user still gets the permission dialog.
+
+Join and capture failures are surfaced in the UI instead of failing silently: `DirectCallService.joinCall` sets a `joinError` signal (`call.errors.*` i18n keys for signaling, capture-unsupported, mic permission, and mic unavailable cases), and the private-call and voice-controls components surface camera errors the same way.
 
 On Capacitor startup, `MobileRuntimePermissionsService` (via `MobileAppLifecycleService.initialize()`) proactively prompts for microphone, camera, local-notification, and push-notification runtime permissions so Android 13+ shells do not keep every permission in the "Not allowed" state until the user joins voice or receives a call.
 
@@ -165,16 +170,19 @@ Tokens persist in server SQLite (`device_tokens` table). Outbound push uses repo
 | `APNS_BUNDLE_ID` | Defaults to `com.metoyou.app` |
 | `APNS_USE_SANDBOX` | `true` for development builds |
 
-Manual dispatch (ops/testing):
+Manual dispatch (ops/testing). Requires `Authorization: Bearer`; `:userId` in the path **must match** the authenticated user (`403` otherwise):
 
 ```http
 POST /api/users/device-tokens/:userId/dispatch
+Authorization: Bearer <token>
 { "title": "Incoming call", "body": "Alice is calling" }
 ```
 
+`POST /api/users/device-tokens` and `GET /api/users/device-tokens/:userId` apply the same rule: body/param `userId` must equal the bearer identity.
+
 ## Android foreground service
 
-`VoiceCallForegroundService` starts when `MobileCallSessionService` begins an active call. Required manifest permissions:
+`VoiceCallForegroundService` starts when `MobileCallSessionService` begins an active call. The voice-channel path also starts/stops it directly: `MediaManager.enableVoice()` / `disableVoice()` call `startMobileVoiceForegroundSession()` / `stopMobileVoiceForegroundSession()` (`infrastructure/mobile/logic/mobile-voice-foreground-session.ts`) so channel voice keeps the mic alive when the app backgrounds. Required manifest permissions:
 
 - `FOREGROUND_SERVICE`
 - `FOREGROUND_SERVICE_MICROPHONE`
@@ -193,10 +201,13 @@ The service shows a low-importance ongoing notification while a call is active.
 - Routing: `infrastructure/persistence/database-backend.rules.ts` — Capacitor uses SQLite, not IndexedDB.
 - Per-user database files: `metoyou__<userId>` via `mobile-sqlite-database-name.rules.ts`.
 - First launch runs DDL migrations stored in the `meta` table. Schema init failures are cached per database file so the client does not retry in a loop.
+- **Custom emoji assets** persist in the `custom_emojis` table (`CapacitorDatabaseService.saveCustomEmoji` / `getCustomEmojis` / `deleteCustomEmoji`).
+- **Message revisions** persist in `meta` under keys `message-revision:<messageId>:<revision>` (JSON payload). See [message-integrity.md](message-integrity.md) and [custom-emoji.md](custom-emoji.md).
 
 ## Capacitor plugin loading
 
-- `infrastructure/mobile/adapters/capacitor/capacitor-plugin-loader.ts` uses **static** `@capacitor/*` imports and `Capacitor.isPluginAvailable()` before returning a plugin. Do not `import()` plugin modules dynamically or `await` plugin objects (Capacitor proxies expose a throwing `.then()` stub).
+- `infrastructure/mobile/adapters/capacitor/capacitor-plugin-loader.ts` loads `@capacitor/*` modules via **dynamic `import()`** only when `isCapacitorNativeRuntime()` is true, and checks `Capacitor.isPluginAvailable()` before returning a plugin. Electron and browser shells never evaluate these imports at startup.
+- Do not `await` a Capacitor plugin proxy object directly — Capacitor proxies expose a throwing `.then()` stub; always call methods on the resolved plugin instance.
 - After adding or upgrading Capacitor plugins, run `npm run build:prod && npm run cap:sync` so Android/iOS native projects register `App`, `AppUpdate`, `LocalNotifications`, push, and SQLite.
 
 ## Safe area (Android)
@@ -267,10 +278,16 @@ Phase 3 delivered:
 3. iOS CallKit bridge (partial) via `MetoyouMobile` plugin and `MobileCallKitService`.
 4. Android Firebase Gradle wiring with `google-services.json.example` (real file gitignored).
 5. Capacitor plugin availability checks to avoid hard failures when plugins are missing pre-sync.
-6. Discovery endpoint skip for production signal hosts without featured/trending routes.
+6. Discovery 404 fallback to public server listing on legacy signal hosts (see [server-discovery.md](server-discovery.md)).
 
 Remaining work:
 
 - Wire CallKit answer/end actions back into `DirectCallService`.
 - Migrate legacy IndexedDB mobile data into SQLite where needed.
-- Deploy featured/trending routes to production signal servers or add capability negotiation in health checks.
+
+## Changelog
+
+| Date | Change |
+|------|--------|
+| 2026-07-13 | Chat notifications routed to LocalNotifications (`toju-messages` channel + `ic_stat_metoyou` status icon); capture preflight blocks only on native `denied`; call join/camera errors surfaced via `call.errors.*`; voice channels start the foreground service; screen share hidden on native mobile; attachment export to `Documents`; full-screen overlays use `metoyou-fixed-safe-viewport` |
+| 2026-07-05 | Corrected discovery fallback (not host skip), plugin-loader dynamic imports, markdown fence; added Capacitor custom-emoji/revision persistence and dispatch auth rules |

agents-docs/features/plugins.md

@@ -0,0 +1,70 @@
+# Plugins
+
+> **Status:** Active
+> **Last updated:** 2026-07-05
+
+## Overview
+
+Client-only plugin runtime with server-stored **metadata** (install requirements, event definitions) and Electron-local **plugin data** persistence. Plugins extend chat slash commands, toolbar actions, DOM mounts, and a P2P message bus — they never execute on the signaling server.
+
+## Responsibilities
+
+| Layer | Owns |
+|-------|------|
+| Product client (`plugins` domain) | Manifest validation, load order, `PluginHostService`, UI registry, store installs |
+| Electron | Local manifest discovery (`plugins/`, `plugin-bundles/`), `plugin_data` CQRS table, path jail |
+| Signaling server | Requirement/event metadata REST + `plugin_event` WebSocket broadcast; **no** plugin code execution |
+| P2P data channel | `plugin-message-bus` events (ignored by chat reducers) |
+
+Server plugin **data** HTTP routes return **410 Gone** (`PLUGIN_DATA_DISABLED`).
+
+## Server REST (`/api/servers/:serverId/plugins`)
+
+| Method | Path | Auth |
+|--------|------|------|
+| GET | `/` | Public (metadata snapshot) |
+| PUT | `/:pluginId/requirement` | Bearer |
+| DELETE | `/:pluginId/requirement` | Bearer |
+| PUT | `/:pluginId/events/:eventName` | Bearer |
+| DELETE | `/:pluginId/events/:eventName` | Bearer |
+| GET/PUT/DELETE | `/:pluginId/data/*` | 410 (disabled) |
+
+## WebSocket
+
+| type | Direction | Purpose |
+|------|-----------|---------|
+| `plugin_requirements` | Server → client | Snapshot after `join_server` / `view_server` |
+| `plugin_event` | Client → server → room | Validated broadcast of plugin events |
+| `plugin_error` | Server → client | Validation failure |
+
+See [signaling.md](signaling.md).
+
+## Manifest scopes
+
+- `scope: "client"` — global desktop/browser plugins (Settings → Client plugins).
+- `scope: "server"` — per chat-server plugins; join may block until user consents to required plugins.
+
+Store source manifests support HTTPS `bundle`/`bundleUrl` with optional SHA-256 `integrity` verification before `import()`.
+
+## Electron IPC / storage
+
+- `list-local-plugin-manifests`, `get-local-plugins-path`, `grant-plugin-read-root`
+- Plugin preferences and `api.clientData` / `api.serverData` → `plugin_data` table (user-scoped)
+- Cached bundles: `plugin-bundles/<plugin-id>/<version>/main.js`
+
+## Client API surface (summary)
+
+Plugins receive `TojuClientPluginApi`: `commands`, `ui.mountElement`, `ui.registerToolbarAction`, `messageBus`, `messages.setTyping`, `context.getCurrent()`, `clientData`/`serverData` async storage.
+
+## Related
+
+- [signaling.md](signaling.md) — `plugin_event`, `plugin_requirements`
+- [server-directory.md](server-directory.md) — server-scoped install on join
+- [authentication.md](authentication.md) — bearer on metadata mutations
+- Domain README: [`toju-app/src/app/domains/plugins/README.md`](../../toju-app/src/app/domains/plugins/README.md)
+
+## Changelog
+
+| Date | Change |
+|------|--------|
+| 2026-07-05 | Initial cross-context plugin contract |

agents-docs/features/push-notifications.md

@@ -0,0 +1,53 @@
+# Push Notifications
+
+> **Status:** Active
+> **Last updated:** 2026-07-05
+
+## Overview
+
+Mobile remote push (FCM/APNs) and server-side device token storage. Desktop uses local/Electron notifications via the `notifications` domain.
+
+## Responsibilities
+
+| Layer | Owns |
+|-------|------|
+| Signaling server | `device_tokens` SQLite table; FCM/APNs dispatch |
+| Capacitor client | Token registration via `MobilePushRegistrationService` |
+| Server env | FCM service account + APNs key configuration |
+
+## REST API (`/api/users/device-tokens`)
+
+All routes require bearer; `userId` must match authenticated identity.
+
+| Method | Path | Purpose |
+|--------|------|---------|
+| POST | `/` | Upsert `{ userId, platform: "android"\|"ios", token }` |
+| GET | `/:userId` | List tokens for user |
+| POST | `/:userId/dispatch` | Manual push `{ title, body, data? }` (ops/testing) |
+
+## Server configuration
+
+Repository-root `.env`:
+
+| Variable | Purpose |
+|----------|---------|
+| `FCM_SERVICE_ACCOUNT_PATH` or `FCM_SERVICE_ACCOUNT_JSON` | Android FCM HTTP v1 |
+| `APNS_KEY_PATH`, `APNS_KEY_ID`, `APNS_TEAM_ID` | iOS APNs HTTP/2 |
+| `APNS_BUNDLE_ID` | Default `com.metoyou.app` |
+| `APNS_USE_SANDBOX` | Development builds |
+
+## Mobile client
+
+- Optional Firebase: app starts without `google-services.json`; registration skipped when remote push not configured.
+- See [mobile-capacitor.md](mobile-capacitor.md) for FCM/APNs setup, permissions, and in-call local notifications.
+
+## Related
+
+- [authentication.md](authentication.md) — bearer + userId match rules
+- [mobile-capacitor.md](mobile-capacitor.md) — client registration and foreground service
+
+## Changelog
+
+| Date | Change |
+|------|--------|
+| 2026-07-05 | Initial push notification contract |

agents-docs/features/server-directory.md

@@ -0,0 +1,96 @@
+# Server Directory
+
+> **Area:** server-directory
+> **Status:** Active
+> **Last updated:** 2026-07-05
+
+## Overview
+
+Server directory is the cross-context contract for **which signaling servers exist**, how clients health-check and route to them, and how public/private chat-servers are created, joined, updated, moderated, and discovered over REST. It spans the signaling **server** (`server/src/routes/servers.ts`, CQRS handlers) and the product **client** (`server-directory` domain + `ServerDirectoryFacade`).
+
+Curated browse lists (featured/trending) are documented separately in [server-discovery.md](server-discovery.md). WebSocket membership (`join_server`, presence) is in [signaling.md](signaling.md).
+
+## Responsibilities
+
+- Server: persist public server records, memberships, channels, roles, bans, invites, join requests; expose REST CRUD and access checks.
+- Client: maintain configured endpoint list, health/compatibility probes, canonical endpoint dedup by `serverInstanceId`, room `sourceId`/`sourceUrl` affinity, and HTTP orchestration for all server operations.
+- It does NOT own: P2P chat transport, voice WebRTC, or local Electron room/message persistence (except mirroring server metadata into local DB after join).
+
+## Key concepts
+
+- **ServerEndpoint:** configured signaling base URL with health status, latency, and version compatibility.
+- **ServerInfo:** public server card shape returned by search/discovery/GET — includes `sourceId`, `sourceName`, `sourceUrl` filled by the client API layer.
+- **Room signal affinity:** each saved room records which endpoint registered it; reconnect prefers that URL before fallback endpoints.
+- **serverInstanceId:** stable id from `GET /api/health` used to collapse alias URLs to one canonical endpoint.
+
+## Public REST (no bearer)
+
+| Method | Path | Purpose |
+|--------|------|---------|
+| GET | `/api/health` | Liveness, `serverVersion`, `serverInstanceId`, optional `serverTag` |
+| GET | `/api/servers` | Free-text search / public listing (`q`, `limit`) |
+| GET | `/api/servers/featured` | Curated popular list — [server-discovery.md](server-discovery.md) |
+| GET | `/api/servers/trending` | Curated active list — [server-discovery.md](server-discovery.md) |
+| GET | `/api/servers/:id` | Single server metadata |
+
+## Protected REST (bearer required)
+
+All mutations derive the actor from the session token; body user ids are not trusted.
+
+| Method | Path | Purpose |
+|--------|------|---------|
+| POST | `/api/servers` | Register a new public server |
+| PUT | `/api/servers/:id` | Update name, description, channels, icon metadata, access settings |
+| DELETE | `/api/servers/:id` | Unregister server (owner) |
+| POST | `/api/servers/:id/join` | Join or request access (password, invite, public) |
+| POST | `/api/servers/:id/leave` | Leave membership |
+| POST | `/api/servers/:id/heartbeat` | Refresh `lastSeen` for trending ranking |
+| POST | `/api/servers/:id/invites` | Create invite link — [invites-join-requests.md](invites-join-requests.md) |
+| GET | `/api/servers/:id/requests` | List pending join requests (moderators) |
+| POST | `/api/servers/:id/moderation/kick` | Remove member |
+| POST | `/api/servers/:id/moderation/ban` | Ban member (optional expiry) |
+| POST | `/api/servers/:id/moderation/unban` | Lift ban |
+
+Join-request approval: `PUT /api/requests/:id` — [invites-join-requests.md](invites-join-requests.md).
+
+Plugin metadata under `/api/servers/:serverId/plugins` — [plugins.md](plugins.md).
+
+## Client endpoint lifecycle
+
+1. Load endpoints from `localStorage` (`metoyou_server_endpoints`); reconcile with environment defaults.
+2. `testAllServers()` probes `GET /api/health` (5 s timeout); on failure falls back to `GET /api/servers`.
+3. Mark incompatible when `serverVersion` fails semantic compatibility check.
+4. `resolveCanonicalEndpoint()` collapses aliases sharing the same `serverInstanceId`.
+5. Cold-start room reconnect waits for the initial health sweep before opening WebSockets.
+
+## Multi-endpoint behavior
+
+| Operation | Fan-out |
+|-----------|---------|
+| Search (`searchServers` with `searchAllServers`) | All online endpoints, dedupe by server id |
+| Discovery (featured/trending) | All online endpoints + 404→public list fallback |
+| Room CRUD/join | Authoritative room `sourceUrl` first; temporary fallback to other compatible endpoints on outage |
+
+Only `status === 'incompatible'` stops fallback with an update-required message. Network errors and Cloudflare 521/522 must continue to the next endpoint.
+
+## Server-owned channel metadata
+
+`PUT /api/servers/:id` persists the server's `channels` array (text + voice). The client round-trips channel create/rename/delete through this API — local-only channel state is not authoritative. Server-side normalisation deduplicates names within each channel type.
+
+## WebSocket complement
+
+After REST join, the client sends `join_server` on the room's signaling URL. Presence (`server_users`, `user_joined`, `user_left`) is room-scoped on the WebSocket — see [signaling.md](signaling.md).
+
+## Related
+
+- [server-discovery.md](server-discovery.md) — featured/trending ranking and browse UI
+- [authentication.md](authentication.md) — bearer tokens for mutations
+- [invites-join-requests.md](invites-join-requests.md) — invite links and approval workflow
+- [signal-server-tag.md](signal-server-tag.md) — `serverTag` on health + profile cards
+- Product-client domain README: [`toju-app/src/app/domains/server-directory/README.md`](../../toju-app/src/app/domains/server-directory/README.md)
+
+## Changelog
+
+| Date | Change |
+|------|--------|
+| 2026-07-05 | Initial cross-context server-directory REST contract |

agents-docs/features/server-discovery.md

@@ -2,7 +2,7 @@
 
 > **Area:** server-directory
 > **Status:** Active
-> **Last updated:** 2025-02-14
+> **Last updated:** 2026-07-05
 
 ## Overview
 
@@ -67,13 +67,24 @@ Both endpoints live in `server/src/routes/servers.ts` and **must be registered b
 ## Client internals
 
 - `ServerDirectoryApiService.getFeaturedServers()` / `getTrendingServers()` call the routes through a shared private `getDiscoveryServers(path)` helper and normalise into `ServerInfo[]`.
+- **Multi-endpoint fan-out:** discovery queries **every online endpoint** (`getSearchableEndpoints()` + `forkJoin`), deduplicated by server ID — mirroring free-text search. Querying only the active endpoint made the default `/servers` view appear empty when populated servers lived on other endpoints.
+- **Legacy 404 fallback:** when `GET /api/servers/featured` or `/trending` returns **404** (older signal servers resolve those paths as `/servers/:id`), `fetchDiscoveryFromEndpoint` falls back per-endpoint to the public `GET /api/servers` listing (`fetchPublicServerListForDiscovery`) instead of returning `[]`. Verified in `server-directory-api.service.spec.ts` (including production hosts like `signal.toju.app`).
 - `ServerDirectoryService` → `ServerDirectoryFacade` expose `getFeaturedServers()` / `getTrendingServers()` as the domain boundary.
 - `FindServersComponent` (`/servers`) composes **Recently active** (the user's saved rooms, capped at 6), **Featured**, and **Trending** sections, all rendered through `app-server-browser` with `[showMyServers]="true"`.
 - `DashboardComponent` (`/dashboard`) is a single-column landing page (max-width centered, no in-page sidebars): a header greeting (no emoji), a global search with `Ctrl+K` focus and localStorage-backed **Recent Searches** chips shown beneath it, three primary action cards (Find People → `/people`, Find Servers → `/servers`, Create Server → `/create-server` — one link each), and discovery panels **People you might know**, **Popular Servers**, **Your Friends**, and **Recently Active Servers**. Each list is capped at 5 (`DISCOVERY_LIMIT`). It loads `popularServers` on init from `getFeaturedServers(5)`, falling back to `getTrendingServers(5)` when featured is empty; reuses `app-friend-button` for Add and `app-user-avatar` for people rows. `peopleYouMightKnow` excludes existing friends (via `FriendService.friendIds()`); `friends` lists discovered people who are friends. "See all" header links route to the matching `/people` or `/servers` page (no duplicated footer links). Recent searches are recorded on Enter (deduped, most-recent-first, capped at 8) and persisted under `metoyou_dashboard_recent_searches`.
 - The servers-rail top button (`servers-rail.component`) is the **Dashboard** button (`lucideLayoutDashboard`, `title="Dashboard"`); its `goToDashboard()` handler deselects any active voice server and navigates to `/dashboard`. A **Create a server** button (`lucidePlus`, `data-testid="server-rail-create"`) sits below the saved-server icons and opens `app-create-server-dialog` (a Toju modal on desktop / bottom sheet on mobile) which dispatches `RoomsActions.createRoom` directly; the dashboard / `/create-server` route remains as an alternative entry point. Rail icons (`h-12 w-12`, `md:h-11 w-11`) animate their corner radius on hover and `:active` for a Discord-style squircle effect.
-- On mobile (`ViewportService.isMobile()`), `DashboardComponent`, `FindPeopleComponent` (`/people`), and `FindServersComponent` (`/servers`) each mount their page body inside a single `<swiper-container>` slide next to `app-servers-rail` (rail `shrink-0`, content `flex-1` with a left border), mirroring the chat-room / DM-workspace mobile layout so the primary navigation rail stays reachable. The page body is shared between the desktop and mobile branches via an `<ng-template #pageContent>` + `[ngTemplateOutlet]`, and each component declares `schemas: [CUSTOM_ELEMENTS_SCHEMA]` for the Swiper custom elements.
+- On mobile (`ViewportService.isMobile()`), discovery routes (`/dashboard`, `/people`, `/servers`) render their page body full-width via `<ng-template #pageContent>` + `[ngTemplateOutlet]`. The **servers rail is global** in `app.html` (`shouldShowMobileAppServersRail` in `core/platform/mobile-shell-layout.rules.ts`) — discovery pages must **not** embed a second `<app-servers-rail>` or Swiper stack. Chat-room and DM-workspace routes keep their own embedded rail inside Swiper and hide the global shell rail (see `toju-app/AGENTS.md`).
 
 ## Related
 
 - Product-client domain README: `toju-app/src/app/domains/server-directory/README.md`
+- Full server-directory REST contract (CRUD, join, moderation): [server-directory.md](server-directory.md)
 - People discovery (`/people`): `toju-app/src/app/domains/direct-message/README.md`
+- Mobile shell: [mobile-capacitor.md](mobile-capacitor.md)
+
+## Changelog
+
+| Date       | Change                                                                                                         |
+| ---------- | -------------------------------------------------------------------------------------------------------------- |
+| 2026-07-05 | Added multi-endpoint fan-out and 404 fallback; corrected mobile shell layout (global rail, no per-page Swiper) |
+| 2025-02-14 | Initial documentation                                                                                          |

agents-docs/features/signal-server-tag.md

@@ -1,10 +1,18 @@
 # Signal Server Tag
 
+> **Status:** Active
+> **Last updated:** 2026-07-05
+
 Users registered on a signal server can show that server's display tag on their profile card (opened by clicking their name or avatar).
 
+## Responsibilities
+
+- Server: expose a human-readable tag per **endpoint** (not per user identity).
+- Client: resolve tag for a user's **home** signaling server (`homeSignalServerUrl`) and render on profile cards.
+
 ## Server configuration
 
-`server/data/variables.json` accepts an optional `serverTag` string. When omitted, the server falls back to its public URL built from `serverProtocol`, `serverHost`, and `serverPort`.
+`server/data/variables.json` accepts an optional `serverTag` string. When omitted, the server falls back to its public URL built from `serverProtocol`, `serverHost`, and `serverPort` (`server/src/config/variables.ts`).
 
 ## Health API
 
@@ -12,11 +20,27 @@ Users registered on a signal server can show that server's display tag on their
 
 ## WebSocket presence
 
-The client sends `homeSignalServerUrl` in `identify` messages. The signaling server echoes that value in `server_users` and `user_joined` payloads so other clients can resolve the correct tag.
+The client sends `homeSignalServerUrl` in `identify` messages. The signaling server echoes that value in `server_users` and `user_joined` payloads so other clients can resolve the correct tag. See [signaling.md](signaling.md).
 
 ## Client behavior
 
 - Login and registration store `homeSignalServerUrl` on the current user.
-- Profile cards show the resolved tag beside the username in muted text.
+- Profile cards show the resolved tag beside the username in muted text (`profile-signal-server-tag.component`).
 - Configured labels render as `#tag`; URL fallbacks render as a globe icon with the URL in a tooltip.
-- Tag resolution prefers the endpoint's cached `serverTag` from health checks, then falls back to the stored home URL.
+- Tag resolution (`signal-server-tag.rules.ts`): match `homeSignalServerUrl` against configured endpoints and prefer cached health `serverTag`; otherwise show the raw URL fallback.
+
+## Testing
+
+- `toju-app/src/app/domains/server-directory/domain/logic/signal-server-tag.rules.spec.ts`
+- `server/src/websocket/handler-status.spec.ts` (presence payload includes `homeSignalServerUrl`)
+
+## Related
+
+- [server-directory.md](server-directory.md) — endpoint health cache
+- [authentication.md](authentication.md) — `homeSignalServerUrl` on identify
+
+## Changelog
+
+| Date | Change |
+|------|--------|
+| 2026-07-05 | Clarified per-endpoint tag vs per-user home URL; added test references |

agents-docs/features/signaling.md

@@ -0,0 +1,152 @@
+# Signaling (WebSocket)
+
+> **Area:** realtime
+> **Status:** Active
+> **Last updated:** 2026-07-05
+
+## Overview
+
+The signaling server exposes a single WebSocket per origin that carries identity, room membership, presence, WebRTC SDP/ICE relay, selected server-relayed chat/DM/voice fallbacks, plugin events, and multi-device `account_sync`. The product client implements the consumer in `toju-app/src/app/infrastructure/realtime/signaling/`.
+
+**Canonical contract:** this document and [`server/src/websocket/handler.ts`](../../server/src/websocket/handler.ts). Do **not** treat `toju-app/src/app/shared-kernel/signaling-contracts.ts` as authoritative — it lists legacy types (`join`, `leave`, `chat`, `ice-candidate`) that do not match the live server.
+
+## Responsibilities
+
+- Authenticate connections via `identify` (session token).
+- Track per-connection room membership and broadcast room-scoped presence.
+- Relay WebRTC offers/answers/ICE between peers that share server membership (or DM/direct-call rules).
+- Relay narrow server fallbacks when P2P data channels are unavailable (chat, DM, voice presence).
+- Forward `account_sync` payloads to sibling connections for the same user identity.
+- It does NOT own: P2P data-channel payloads (attachments, message inventory, custom emoji chunks, plugin message bus), local persistence, or REST server-directory APIs.
+
+## Key concepts
+
+- **Envelope:** JSON object with required `type` string; additional fields vary by type.
+- **oderId:** user identity on the wire (legacy spelling, matches server code).
+- **clientInstanceId:** per-tab/device id stored in `sessionStorage`; multiple open connections per `oderId` are allowed.
+- **connectionScope:** optional string grouping connections (e.g. browser profile).
+- **voiceActive:** server marks the connection that owns outbound RTC relay for a user; updated from `voice_state` payloads.
+
+## Ordering invariants
+
+1. **`identify` before anything else** — unauthenticated connections receive `auth_required` for all types except `identify` and `keepalive`.
+2. **Per-connection serialization** — `handleWebSocketMessage` chains handlers per `connectionId` so `join_server` cannot run while `identify` is still awaiting the token DB lookup.
+3. **Client replay on reconnect** — `SignalingManager.reIdentifyAndRejoin` sends `identify` then re-joins rooms; see [`toju-app/src/app/infrastructure/realtime/README.md`](../../toju-app/src/app/infrastructure/realtime/README.md).
+
+## Connection lifecycle (server → client)
+
+On connect the server assigns a `connectionId` and may emit:
+
+| type | When |
+|------|------|
+| `connected` | Immediately after WebSocket open (`server/src/websocket/index.ts`) |
+
+On disconnect, if the connection was voice-active, the server broadcasts a cleared `voice_state` via `finalizeVoiceDisconnectForConnection`.
+
+## Inbound types (client → server)
+
+| type | Auth | Behavior |
+|------|------|----------|
+| `keepalive` | Optional | Responds `keepalive_ack` with `serverTime` |
+| `identify` | N/A (establishes auth) | Validates session token; sets `oderId`, profile fields; evicts stale same `(oderId, connectionScope, clientInstanceId)` sockets; emits `account_sync_peer_online` to siblings |
+| `join_server` | Required | Access check; adds `serverId` to connection; sends `server_users` + `plugin_requirements`; may broadcast `user_joined` (identity-aware) |
+| `view_server` | Required | Switches `viewedServerId`; refreshes `server_users` + `plugin_requirements` |
+| `leave_server` | Required | Removes membership; may broadcast `user_left` with remaining `serverIds` |
+| `offer`, `answer`, `ice_candidate` | Required | Relay to `targetUserId` when peers share server membership |
+| `direct-message`, `direct-message-status`, `direct-message-mutation`, `direct-message-typing`, `direct-message-sync-request`, `direct-message-sync`, `direct-call` | Required | Relay to `targetUserId` (DM rules — no shared-server requirement) |
+| `server_icon_peer_request`, `server_icon_peer_data` | Required | Relay when both users share `serverId` membership |
+| `chat_message` | Required | Broadcast to server members (excludes sender connection) |
+| `voice_state` | Required | Updates `voiceActive` / snapshot; broadcast to server members |
+| `voice_client_takeover` | Required | Notifies sibling connections via `notifyOtherConnectionsForOderId` |
+| `account_sync` | Required | Forwards `payload` object to other connections for same `oderId` |
+| `typing` | Required | Broadcast `user_typing` to server members |
+| `status_update` | Required | Broadcast `status_update` (`online` \| `away` \| `busy` \| `offline`) to joined servers |
+| `server_icon_available` | Required | Records local `iconUpdatedAt` per server on the connection |
+| `server_icon_sync_request` | Required | Responds `server_icon_sync_peers` with peers having newer icons |
+| `plugin_event` | Required | Validates against server plugin metadata; broadcast or `plugin_error` |
+
+Unknown inbound types are logged and ignored.
+
+### `identify` request fields
+
+| Field | Required | Notes |
+|-------|----------|-------|
+| `token` | Yes | Session token from REST login/register |
+| `oderId` | No | If present, must match token user id |
+| `displayName` | No | Defaults to existing or `"User"` |
+| `description`, `profileUpdatedAt`, `homeSignalServerUrl` | No | Profile card fields |
+| `clientInstanceId` | No | Per-tab id for multi-device and voice ownership |
+| `connectionScope` | No | Eviction scope for stale sockets |
+
+Errors: `auth_error` with `MISSING_TOKEN`, `INVALID_TOKEN`, or `USER_ID_MISMATCH`.
+
+## Server-emitted types (server → client)
+
+| type | Trigger |
+|------|---------|
+| `keepalive_ack` | Response to `keepalive` |
+| `auth_required` | Message before `identify` |
+| `auth_error` | Failed `identify` |
+| `access_denied` | `join_server` rejected (`serverId`, `reason`) |
+| `server_users` | After join/view; lists unique users in room |
+| `user_joined` | New identity in server (excludes same identity's connections) |
+| `user_left` | Identity fully left server (`serverIds` = remaining rooms) |
+| `plugin_requirements` | Plugin install snapshot after join/view |
+| `plugin_error` | Invalid plugin event |
+| `server_icon_sync_peers` | Response to `server_icon_sync_request` |
+| `account_sync_peer_online` | Sibling connection came online |
+| `account_sync` | Relayed multi-device payload |
+| `chat_message` | Relayed room chat fallback |
+| `user_typing` | Typing indicator |
+| `status_update` | Presence status change |
+| `voice_state` | Voice roster / disconnect cleanup |
+| `voice_client_takeover` | Another tab took voice ownership |
+| `plugin_event` | Broadcast plugin event |
+| Forwarded RTC/DM | Copies of client messages with `fromUserId` set |
+
+## Relay rules
+
+- **RTC (`offer` / `answer` / `ice_candidate`):** forwarded when sender and target share any server membership.
+- **Direct signaling types:** forwarded to `targetUserId` without shared-server check.
+- **Server icon P2P:** both users must be members of `message.serverId`.
+- **Broadcasts** (`chat_message`, `voice_state`, `typing`, etc.): exclude sender **connection id** (not whole identity) so multi-device sessions still receive updates.
+- **`user_joined` / `user_left`:** exclude whole **identity** so other users do not see duplicate join/leave for multiple tabs.
+
+## P2P vs signaling split
+
+| Transport | Carries |
+|-----------|---------|
+| **WebRTC data channel** | Chat events, attachments, custom emoji, message revisions/inventory, profile avatar bytes, voice/screen control, plugin message bus, game activity |
+| **WebSocket signaling** | Identity, membership, presence, RTC SDP/ICE, chat/DM/voice fallbacks, `account_sync`, plugin events |
+
+Server-relayed chat (`chat_message`) and DM types exist so users see written chat and delivery state while data channels are down. Media, attachments, and inventory sync remain peer-plane responsibilities.
+
+## Multi-device (`account_sync`)
+
+The client wraps relayable local changes in `account_sync` envelopes. The server forwards the inner `payload` to other open connections for the same `oderId`. When a device identifies, siblings receive `account_sync_peer_online` and push snapshots (saved servers, friends, emoji library, chat history batches, etc.). See [authentication.md](authentication.md) and domain-specific feature docs.
+
+## Client implementation map
+
+| Concern | Location |
+|---------|----------|
+| One socket per signal URL | `signaling/signaling.manager.ts` |
+| Route picker | `signaling/signaling-transport-handler.ts` |
+| Room affinity | `signaling/server-signaling-coordinator.ts` |
+| Inbound dispatch | `signaling/signaling-message-handler.ts` |
+| Constants (intervals, types) | `realtime.constants.ts` |
+
+## Related
+
+- [authentication.md](authentication.md) — session tokens and `identify` trust boundary
+- [direct-messaging.md](direct-messaging.md) — DM envelope relay types
+- [voice-webrtc.md](voice-webrtc.md) — RTC relay and `voice_state`
+- [plugins.md](plugins.md) — `plugin_event` / `plugin_requirements`
+- [message-integrity.md](message-integrity.md) — signed revisions (P2P; `account_sync` relay)
+- Product client deep dive: [`toju-app/src/app/infrastructure/realtime/README.md`](../../toju-app/src/app/infrastructure/realtime/README.md)
+- Server handler: [`server/src/websocket/handler.ts`](../../server/src/websocket/handler.ts)
+
+## Changelog
+
+| Date | Change |
+|------|--------|
+| 2026-07-05 | Initial canonical envelope catalog; deprecates `shared-kernel/signaling-contracts.ts` as wire source |

agents-docs/features/voice-webrtc.md

@@ -0,0 +1,60 @@
+# Voice & WebRTC
+
+> **Status:** Active
+> **Last updated:** 2026-07-05
+
+## Overview
+
+Voice channels, camera, and screen-share use direct **WebRTC** peer connections between clients. The signaling server relays SDP offers/answers/ICE and **voice presence** (`voice_state`); media never flows through the server.
+
+## Responsibilities
+
+| Layer | Owns |
+|-------|------|
+| `infrastructure/realtime/` | WebRTC sessions, negotiation, data channels, RNNoise worklet |
+| `voice-connection` / `voice-session` domains | Facades, workspace UI, settings, multi-device ownership |
+| `screen-share` domain | Source picker, quality presets (Electron) |
+| Signaling server | RTC relay + `voice_state` / `voice_client_takeover` broadcast |
+
+## WebSocket signaling types
+
+| type | Purpose |
+|------|---------|
+| `offer`, `answer`, `ice_candidate` | WebRTC negotiation relay to `targetUserId` |
+| `voice_state` | Voice roster (mute/deafen/speaking, channel id); sets `voiceActive` on one connection per user |
+| `voice_client_takeover` | Notify sibling tabs to yield voice ownership |
+
+Relay rules: RTC messages require shared server membership (except DM-specific types). See [signaling.md](signaling.md).
+
+## Multi-device voice
+
+- Only one connection per `oderId` may be `voiceActive`; RTC offers route to that connection (fallback: any open connection).
+- Other tabs show passive UI and may send `voice_client_takeover`.
+- `clientInstanceId` in `identify` and voice payloads distinguishes tabs.
+
+## Media pipeline (client)
+
+- **Voice:** `getUserMedia` → optional RNNoise AudioWorklet → gain → same-room peer routing only.
+- **Camera:** separate video track; same-room filter.
+- **Screen share:** on-demand via data-channel `SCREEN_SHARE_REQUEST`; platform-specific capture (browser `getDisplayMedia`, Electron picker, Linux PulseAudio routing).
+
+## P2P data channel
+
+Carries voice/screen control messages, chat, attachments, and state sync — not server-relayed. Data-channel failure triggers peer renegotiation or full rebuild (see realtime README).
+
+## Mobile / Capacitor
+
+Background voice uses Android foreground service + iOS audio/CallKit bridges — [mobile-capacitor.md](mobile-capacitor.md). Screen share is limited on mobile WebViews.
+
+## Related
+
+- [signaling.md](signaling.md) — envelope catalog
+- [direct-messaging.md](direct-messaging.md) — private calls share `PeerDeliveryService`
+- [`toju-app/src/app/infrastructure/realtime/README.md`](../../toju-app/src/app/infrastructure/realtime/README.md) — negotiation, recovery, RNNoise
+- Domain READMEs: `voice-connection`, `voice-session`, `screen-share`
+
+## Changelog
+
+| Date | Change |
+|------|--------|
+| 2026-07-05 | Initial cross-context voice/WebRTC contract |