# Map: WebSocket-Realtime-Layer + Voice-Signaling-Fundament

**Status: abgeschlossen.** Alle elf Tickets sind aufgelöst; das Ziel — eine
implementierbare Spec — ist erreicht. Dieses Verzeichnis ist die Begründungsschicht
zum Realtime-Code: *warum* etwas so gebaut ist, samt der verworfenen Alternativen.
Offene Arbeit steht nicht hier, sondern als Issue im GitLab.

Der Effort umfasst beide Repos (`rustification-server` und `rustification-client`);
die Dokumente liegen hier, weil das Gewicht der Spec serverseitig ist.

Entstanden mit `/wayfinder`; Label dort: `wayfinder:map`.

## Destination

Eine implementierbare Spec für einen WebSocket-Realtime-Layer **neben** dem bestehenden
REST-API (Nachrichten-Push für alles Persistierte) plus das **Voice-Signaling-Fundament**
(Room join/leave, Teilnehmerliste, SDP/ICE-Relay — kein Audio), zugeschnitten für den
Tauri-Client auf Desktop und Mobile im Foreground.

Fertig, wenn jemand die Spec ohne Rückfragen implementieren kann und der spätere
E2EE-Effort sie nicht ungültig macht.

**Dieser Effort plant, er baut nicht.** Jedes Ticket beantwortet eine Entscheidung.
Die Umsetzung ist ein eigener Effort.

## Notes

### Produktkontext

Rustification ist als Alternative zu Matrix gedacht, mit zwei erklärten Erfolgsfaktoren:

1. **Deployment-Simplizität** — wie leicht, schnell und reproduzierbar ist ein Server
   aufgesetzt und einsatzbereit?
2. **Nutzersicherheit** — Schutz vor Angriffen und Data-Leaks.

Zielbild: Firmen, die mit sensiblen Daten umgehen (eigene Instanz), und eine öffentliche
Discord-Alternative für Privatnutzer. Jeder Nutzer soll einen eigenen Server hosten können.

**Bedrohungsmodell: der Serverbetreiber ist ein Angreifer.** Das ist der Grund, warum
echtes E2EE gerechtfertigt ist und nicht bloß Verschlüsselung at rest.

### Codebases

| | |
|---|---|
| `rustification-server` | Rust, Axum 0.8, SQLx 0.9 / PostgreSQL 17, JWT + Argon2, Tokio. Migrationen embedded. |
| `rustification-client` | Tauri v2. Frontend React 18 + TS (Vite). Client-Backend Rust, ruft REST via `reqwest`. Ziele: Windows, Linux, Android, iOS. |

Stand heute: **Polling.** `MessageList.tsx:33` fährt ein `setInterval(load, 3000)`,
zusätzlich zählt `ChatPage.tsx` nach dem Senden einen `refreshKey` hoch. Beides wird
ersetzt. (Der Client-README beschreibt darüber hinaus Member-Panel und Settings-Seite,
die es im Code noch nicht gibt.)

Weitere Bestandsfakten aus den Recherchen: `axum = "0.8.9"` ist **ohne `ws`-Feature**
eingebunden, es gibt keinen Graceful Shutdown, und `Extension<Claims>` wird nirgends gelesen.
Auf Client-Seite existieren `src-tauri/gen/android` und `gen/apple` noch nicht — Mobile ist
nie initialisiert worden, es gibt also nichts zu migrieren. Und es gibt weder WebRTC- noch
WebSocket-Code: grüne Wiese.

### Feststehende Randbedingungen

Diese sind **entschieden** und werden von den Tickets nicht neu aufgemacht:

| Thema | Entscheidung |
|---|---|
| REST vs. WS | REST bleibt für Auth, CRUD und History. WS macht Push + Voice-Signaling. |
| Protokollform | **Dumb Pipe** `{conversation, cursor}` für alles Persistierte; eigenes flüchtiges Format nur für Voice-Signaling. Die Naht verläuft entlang *persistiert vs. flüchtig*. |
| Deployment | **Harte Regel: eine Binary + Postgres.** TURN ist optionale, extern konfigurierbare Abhängigkeit — ohne sie läuft Chat voll, Voice eingeschränkt. |
| Zustellung | Best-effort + `?since`-Backfill nach Reconnect. Keine Server-Queue, keine ACKs — die DB *ist* die Queue. |
| Fan-out | **Revidiert am 14.08.2026 durch *Fan-out-Architektur*:** kein Trait, keine zweite Implementierung — **immer** über `pg_notify`, auch bei einer Instanz. Ein Trigger auf `conversation_events` feuert, der Server hört sich per `PgListener` selbst zu. Ein Pfad für Ein- und Mehr-Instanz-Betrieb, der getestete Pfad ist der Produktionspfad. Kein Redis. *(Ursprünglich: In-Process hinter einem Trait, `NOTIFY` als zweite Impl — formuliert, bevor feststand, dass der Event 60 Byte groß ist und der Trigger ohnehin feuert.)* |
| Server-Modell | **Keine Föderation.** Der *Client* hält N Verbindungen zu N unabhängigen Servern; kein Server-zu-Server-Protokoll. |
| Krypto | Nachrichteninhalte sind im Protokoll undurchsichtige Blobs. Metadaten darf der Server sehen. Volles E2EE-Design ist ein Folge-Effort. |
| Mobile | Foreground ja. Background-Delivery und Push out of scope. |
| Bestandsdaten | Keine. Migrationen dürfen brechen. |
| Client-Plattformen | Windows, Linux, Android, iOS — **Linux ist vollwertige Client-Plattform**, nicht nur Server-Host (bestätigt 14.08.2026). Das verbaut den billigen Ausweg bei *Voice auf Linux*. |
| **Keine fremden Origins im WebView** | wry vergibt Mikrofonrechte ohne App-Beteiligung — auf iOS in 0.55.1 bedingungslos `Grant` für jeden Origin. Solange nur eigener gebündelter Code läuft, ist das harmlos; ein `<iframe>`, eine Link-Vorschau oder eine Einbettung fremder Inhalte bekäme sofort Mikrofonzugriff, ohne dass die App gefragt wird. Ab Tauri 2.12 (`on_permission_request`) kontrollierbar — bis dahin ist diese Regel der einzige Schutz. |

### Skills pro Session

Jede Session, die ein Ticket bearbeitet: `/grilling` und `/domain-modeling`.
Recherche-Tickets: `/research` als Subagent. Prototyp-Tickets: `/prototype`.

### Council-Verdikt (14.08.2026)

Position: *Zuschnitt grundsätzlich richtig, aber zu groß und an einer Stelle sachlich
falsch — Protokoll auf einen generischen Änderungs-Event reduzieren, Mobile-WebRTC-
Recherche vor alle Voice-Entscheidungen ziehen.* Konfidenz 71 %.

Drei kritische Risiken:

1. **Cursor-Lücke** — **aufgelöst am 14.08.2026**: Zähler pro Conversation unter Zeilen-Lock,
   damit ist Commit-Reihenfolge gleich Cursor-Reihenfolge. Siehe *Monotoner Cursor*.
2. **Mobile-WebRTC-Unbekannte** — **aufgelöst am 14.08.2026, positiv**: Android, iOS und
   Windows tragen WebRTC im WebView. An seine Stelle tritt ein neues Risiko, das die
   Recherche gefunden hat: **Linux trägt es nicht**, und Linux ist die Heimplattform der
   Zielgruppe Selbsthoster. → *Voice auf Linux*.
3. **Bedrohungsmodell-Lücke** — **aufgelöst**: der Betreiber ist Angreifer (siehe oben).

Korrektur am Verdikt: das Argument „Dumb Pipe ist E2EE-agnostisch, weil kein Inhalt
durch den Socket geht" ist **falsch** — unter E2EE ist der Inhalt ohnehin ein Blob, den
der Server nicht lesen kann. Der Dumb Pipe gewinnt bei Simplizität, `NOTIFY`-Tauglichkeit
und Cache-Konsistenz, nicht bei der Sicherheit.

Minderheitsvotum (🎨 Visionary): *„Matrix ist seit zehn Jahren exakt dieses Produkt —
ein Matrix-Client in Tauri bringt dich in einem Wochenende weiter."* Bewusst verworfen:
Föderation ist der Grund für Matrix' Betriebsaufwand, und Simplizität im Deployment ist
hier das Differenzierungsmerkmal.

## Decisions so far

<!-- eine Zeile pro geschlossenem Ticket: Gist + Link -->

- [Recherche: WebRTC im Tauri-WebView (Mobile)](issues/01-research-webrtc-tauri-mobile.md) —
  **iOS, Android und Windows tragen WebRTC im WebView** (iOS ab 14.3 mit
  `NSMicrophoneUsageDescription`; Android ab API 21 mit `RECORD_AUDIO` **und**
  `MODIFY_AUDIO_SETTINGS`; Windows ohne Konfiguration). **Linux nicht** — drei unabhängige
  Gates in WebKitGTK, eines davon distro-seitig unlösbar. Council-Risiko 2 positiv
  aufgelöst. Zwei Befunde mit Folgen: der Signaling-Server kann DTLS-Fingerprints tauschen
  (RFC 8827) und der spezifizierte Gegenmechanismus ist nirgends implementiert; wry vergibt
  Mikrofonrechte ohne App-Beteiligung.
  Details: [`research/01-webrtc-tauri-mobile.md`](research/01-webrtc-tauri-mobile.md)
- [Recherche: WS-Auth, Heartbeat und Reconnect](issues/03-research-ws-auth-reconnect.md) —
  Faktenlage zu allen sechs Teilfragen, ohne Empfehlung. Vier Befunde mit Folgen: **(a)** der
  `Authorization`-Header ist der einzige Kanal, der in den Proxy-Defaults nicht mitgeloggt wird
  (Caddy redigiert ihn aktiv, `request.uri` nicht) — und `Sec-WebSocket-Protocol` wird sehr wohl
  geloggt; **(b)** die Browser-API muss laut WHATWG alle Fehlerdetails verschlucken, im WebView
  ist „Token abgelaufen" nicht von „Server down" unterscheidbar, im Rust-Layer schon;
  **(c)** `axum::serve(...).with_graceful_shutdown(...)` beendet WS-Verbindungen nicht und
  wartet nicht auf sie — eigenes Tracking ist zwingend; **(d)** `tokio::sync::watch` passt
  semantisch besser zum Dumb Pipe als `broadcast`.
  Details: [`research/03-ws-auth-reconnect.md`](research/03-ws-auth-reconnect.md)
- [Monotoner Cursor](issues/02-monotoner-cursor.md) — **ein Zähler `seq` pro Conversation,
  vergeben per `UPDATE conversations SET seq = seq + 1 … RETURNING` in derselben Transaktion
  wie die Änderung.** Der Zeilen-Lock erzwingt Commit-Reihenfolge == `seq`-Reihenfolge; die
  Korrektheit folgt aus der Konstruktion. Die Änderungsachse ist eine neue Tabelle
  `conversation_events` (die Log-Zeile *ist* der Dumb-Pipe-Event), nicht eine Spalte auf
  `messages` — nur so werden Edits, Soft-Deletes und Reactions vom Backfill erfasst.
  `?since=N` liefert **aufgelösten Zustand inkl. Tombstones**, nicht rohe Events: idempotent
  und koaleszierend, und das Log bleibt reine Signalisierung. Keine Retention, dafür ein
  Antwortlimit mit `resync`-Antwort — derselbe Pfad bedient auch Erstverbindung und
  `RecvError::Lagged`. **Nebenbefund: `created_at` verliert seine Sortierrolle** — es ist
  `NOW()`, also Transaktionsstart, und die heutige Sortierung in `list_messages` ist damit
  schon jetzt falsch. Council-Risiko 1 aufgelöst.
- [Wo lebt die WS-Verbindung im Client](issues/05-wo-lebt-die-ws-verbindung.md) — **eigene
  Implementierung im Tauri-Rust-Layer** (`tokio-tungstenite`), Pool im `AppState`, Zustellung
  per `emit`. Entscheidend waren `Authorization: Bearer` (einziger Kanal, den die
  Proxy-Defaults nicht loggen) und dass `tungstenite::Error::Http` die volle Antwort trägt,
  während der WebView laut WHATWG nur `1006` sehen darf. `tauri-plugin-websocket` geprüft und
  verworfen (dünne API, dokumentierter Nachrichtenverlust, von den Maintainern erklärtermaßen
  nicht gepflegt). **Voice-Signaling läuft ebenfalls über diesen Socket**, nur die
  `RTCPeerConnection` lebt im WebView — die im Ticket vermutete Spannung löst sich auf.
  **Rust macht den Backfill selbst und emittiert aufgelöste Entitäten**, die Cursor-Buchhaltung
  liegt also bei Verbindung und Token statt im Frontend. Alle konfigurierten Server sind im
  Vordergrund verbunden. `BASE_URL` wird zur Server-Liste im `tauri-plugin-store`;
  Geheimnisse kommen hinter ein `SecretStore`-Trait, dessen Implementierung der E2EE-Effort
  wählt.
- [Dumb-Pipe-Event & Backfill-Endpunkt](issues/06-dumb-pipe-event-und-backfill.md) — Event ist
  **minimal `{conversation, seq}`** (~60 Byte, JSON, keine Protokollversion); `kind` und
  `target_id` bewusst weggelassen, weil additiv nachrüstbar. `conversation_events.kind` bleibt
  damit serverintern. Aufholen nach Reconnect läuft über ein **Manifest** (`GET /sync` liefert
  `{conversation_id, seq}` für alle Mitgliedschaften — eine Abfrage) plus gezielte Backfills:
  bei 40 Conversations und 3 geänderten 1+3 Requests statt 40. **`resync` ist ein
  unterschiedener Antworttyp bei 200**, kein 4xx — es ist der Normalfall bei jeder
  Erstverbindung und darf nicht durch Fehlerpfade laufen. Limit 500 Entitäten, Tombstones
  werden mitgeliefert. **Klartext-Grenze konkret gezogen** und damit bindend für den
  E2EE-Effort: Blob werden `messages.content`, `attachments.filename`, `attachments.mime_type`
  und `reactions.emoji` (deterministisch, damit der `UNIQUE`-Constraint greift); Routing-,
  Ordnungs- und Autorisierungsfelder plus Zeitstempel bleiben lesbar. Drei Endpunkte:
  `/sync`, `/conversations/{id}/changes`, `/conversations/{id}/messages` (seitenweise).
- [Fan-out-Architektur](issues/08-fan-out-architektur.md) — Registry
  `conversation_id → Verbindungen` plus eine zweite `user_id → Verbindungen` für
  Mitgliedschaftswechsel (ein Beitretender steht noch nicht in der ersten). Je Verbindung ein
  **Dirty-Set** `HashMap<Conversation, seq>` + `Notify` statt eines Kanals — perfektes
  Zusammenfassen, kein Überlauf, kein Überlauf-Fehlerpfad; Eintrag als `max()`, weil `NOTIFY`
  Reihenfolge nur je Listener garantiert. Log-Zeile schreibt der Handler, `pg_notify` feuert
  ein dreizeiliger Trigger auf `conversation_events` — damit ist der Signalpfad unvergesslich.
  **Der Trait ist gestrichen** (siehe Randbedingung Fan-out oben). Zwei akzeptierte Kosten:
  `PgListener` belegt eine dedizierte Verbindung außerhalb des Pools, und eine volle
  Notify-Queue lässt Transaktionen beim Commit scheitern. Eine eingeführte Lücke ist
  geschlossen: **nach jedem Listener-Reconnect geht ein Resync-Hinweis an alle Verbindungen**,
  weil `NOTIFY` keine Historie hat.
  **Tragende Einsicht des Tickets:** weil nur der neueste `seq` je Conversation zählt, darf
  das Fan-out zusammenfassen und sogar verlieren — Lag ist Latenz, nicht Datenverlust.
- [Verbindungsaufbau & Auth über WS](issues/07-verbindungsaufbau-und-auth.md) —
  `Authorization: Bearer` im Handshake. **In-Band-Re-Auth** statt Verbindungs-TTL: der Client
  schiebt das erneuerte Token über den ohnehin bidirektionalen Socket, statt bei 15 Minuten
  Tokenlebensdauer zwölfmal pro Stunde neu zu verbinden; Widerruf wirkt trotzdem innerhalb der
  Restlaufzeit. **Autorisierung liegt bei den REST-Endpunkten**, nicht bei der Registry — der
  Event trägt keinen Inhalt, Registry-Drift leckt also höchstens Metadaten.
  **Client pingt alle 15 s** (Protokoll-Ping, in Rust verfügbar; 15 s wegen des striktesten
  belegten Proxy-Idle-Timeouts von 20 s), Server führt `last_seen`. **Acht Verbindungen je
  Nutzer, die älteste weicht** — nicht die neue abweisen, sonst sperrt ein hängengebliebener
  Socket das Gerät aus. **Eigene Close-Codes, drei Handlungsklassen** (sofort / Backoff /
  gar nicht), Full Jitter beim Backoff. Graceful Shutdown wird selbst gebaut
  (`CancellationToken` + `TaskTracker`), weil axum WS-Verbindungen nicht abwartet.
- [Voice auf Linux](issues/11-voice-auf-linux.md) — **Flatpak zusätzlich geprüft und als Lösung
  ausgeschlossen**: das GNOME-Runtime baut WebKitGTK ohne WebRTC-Flag, und das einzige
  funktionierende Rezept verlangt, WebKitGTK selbst zu kompilieren *und* wry zu patchen.
  Gate 1 hat keine nutzerseitige Lösung. Entscheidung: **WebView-Pfad auf Windows, Android und
  iOS; nativer Stack (`livekit/rust-sdks`) nur auf Linux** — der Gratis-Pfad auf drei
  Plattformen wiegt schwerer als die Einheitlichkeit; akzeptierter Preis sind zwei Medienpfade
  auf Dauer. Die Naht ist **eine explizite Verzweigung im Frontend**, gesteuert über eine von
  Rust gemeldete Fähigkeit (`webview` / `native` / `none`), kein Trait mit Steuerungsumkehr.
  **Gestaffelt:** Voice erscheint zuerst auf den drei WebView-Plattformen, Linux zeigt es
  ehrlich als noch nicht verfügbar — der WebView-Pfad validiert das Signaling-Protokoll billig,
  bevor der schwere native Stack hineinsteckt. **Nebenwirkung: Experiment E5 der WebRTC-Recherche
  (Arch/Fedora prüfen) entfällt**, weil Linux den nativen Stack unbedingt nutzt.
- [Voice-Topologie](issues/04-voice-topologie.md) — **Mesh, harte Obergrenze sechs
  Teilnehmer**, serverseitig durchgesetzt; der Server fasst nie Audio an. **Kein spekulativer
  SFU-Vorbau**: ein SFU-Protokoll ist client-zu-Server adressiert, ein Mesh-Protokoll
  peer-zu-peer — eine „SFU-taugliche Naht" heute wäre Selbsttäuschung. Ein SFU wäre ein
  bewusster Protokollbruch in einem eigenen Effort, nicht ausgeschlossen, aber auch nicht
  vorbereitet. Dazu **eine Datenschutz-Politik je Instanz**, vom Server gesetzt und im
  Signaling übermittelt: *streng* = `iceTransportPolicy: "relay"` **plus** Opus `cbr=1`/`usedtx=0`,
  *offen* = Standard-ICE und Standard-Opus. Die Kopplung folgt der Bedrohung — beide Lecks
  entstehen am selben Ort: über das Relay sieht der Betreiber Paketgrößen und damit
  Sprechaktivität, direkt sieht er nichts, dafür lernt der Peer die IP. Der Client **zeigt den
  Modus an**. TURN bleibt damit optional: ohne TURN läuft Voice im offenen Modus eingeschränkt,
  im strengen gar nicht — und der Betreiber legt den Schalter selbst um.
- [Voice-Signaling-Protokoll](issues/09-voice-signaling-protokoll.md) — **Discord-Modell:**
  `voice_rooms` ist eine eigenständige Entität mit *zwei möglichen Eltern* — `workspace_id`
  (dauerhafter Sprachkanal, für alle Workspace-Mitglieder sichtbar und betretbar) **oder**
  `conversation_id` (Direktanruf aus DM/Gruppe, endet beim Auflegen), per `CHECK` genau eines.
  Das spiegelt das Muster, das `conversations` schon benutzt. **Autorisierung läuft durch genau
  eine Funktion**, weil Rollen später Conversations *und* Räume gleichermaßen einschränken
  sollen. Raumzustand in `voice_participants` in Postgres — nötig, weil Mehr-Instanz-Betrieb
  seit Ticket 08 ab Tag eins möglich ist; Geisterzeilen fängt `last_seen` über den bestehenden
  15-s-Heartbeat ab. Adressierung über **`session_id`, nicht `user_id`** (Multi-Device).
  **Der Beitretende bietet an** — Konvention, kein Mechanismus; bei Video/Screenshare später
  durch Perfect Negotiation zu ersetzen. **Fingerprint-Pinning: Naht jetzt, Füllung durch den
  E2EE-Effort** — bis dahin zeigt der Client dauerhaft und nicht wegklickbar an, dass das
  Gespräch unverifiziert ist. Eine eigene Voice-Identität wurde bewusst verworfen, weil Nutzer
  sonst später zwei Identitäten und zwei Verifikationsrituale hätten. Politik und
  zeitbeschränkte TURN-Credentials reisen in der Beitrittsantwort; Raumgröße wird serverseitig
  durchgesetzt.
- [Client-Integration](issues/10-client-integration.md) *(Prototyp:
  `rustification-client`, Branch `prototype/frontend-zustandsmodell`)* — **Der Client vergibt die
  Nachrichten-ID**, nicht der Server. Der Prototyp hat gezeigt, dass optimistisches Senden
  sonst nicht zusammenführbar ist: dieselbe Nachricht steht zweimal da, einmal mit `seq` und
  einmal ohne. `messages.id` kommt damit vom Client statt aus `DEFAULT gen_random_uuid()` —
  Nebengewinn: Senden wird idempotent, ein Wiederholungsversuch ist ein No-op.
  **Zweiter Befund: eine Ungelesen-Zahl ist ohne Nachladen nicht ableitbar**, weil `seq`
  Events zählt und nicht Nachrichten. Daraus die Regel: Rust lädt **für DMs** nach (Zahl),
  für Channels und Gruppen nicht (nur ein Punkt) — dasselbe Discord-Verhalten wie beim
  Raummodell, und `conversations.kind` gibt die Unterscheidung schon her. Zustandsform: je
  Server ein Verbindungszustand, je Conversation `{geladen, ungelesen, nachrichten[]}`; keine
  Zustandsbibliothek nötig, weil es keinen abgeleiteten Zustand gibt.

## Not yet specified

- **Presence, Typing-Indikator und Read-Receipts als Event-Typen.** Bewusst hinter das
  erste lauffähige Push geschoben — es sind Goodies, nicht der Hauptfokus. Read-Receipts
  brauchen zusätzlich ein Schema (`message_reads` existiert nicht). **Haben seit
  *Monotoner Cursor* ein Zuhause:** sie werden `kind`-Werte in `conversation_events`, das
  Log trägt sie ohne Umbau mit. Wird spezifizierbar, sobald
  *Dumb-Pipe-Event & Backfill-Endpunkt* steht. **Ausnahme:** die Teilnehmerliste
  eines Voice-Rooms ist nicht dasselbe wie Chat-Presence und bleibt im Scope von
  *Voice-Signaling-Protokoll*.
- **Verhalten beim Mobile-Resume aus dem Hintergrund.** Was genau passiert, wenn die App
  nach Minuten oder Stunden zurückkommt — Reconnect-Backoff, Cursor-Sprung, UI-Zustand.
  Hängt an *Dumb-Pipe-Event & Backfill-Endpunkt* und *Verbindungsaufbau & Auth über WS*.
- **Rate-Limiting auf Handshakes.** *Verbindungsaufbau & Auth über WS* hat das Limit pro
  Nutzer entschieden (acht, älteste weicht), ein Rate-Limit auf Verbindungsversuche aber
  bewusst offengelassen: es trifft ein anderes Missbrauchsmuster und ist ohne Betriebserfahrung
  nicht kalibrierbar — ein Reconnect-Sturm nach einem Neustart sieht aus wie ein Angriff.
  Wird scharf, sobald es Zahlen aus dem Betrieb gibt.
- **Observability des WS-Layers.** Was misst man an offenen Verbindungen, Registry-Größe,
  Zustellverzögerung? Seit *Fan-out-Architektur* gibt es zwei konkrete Pflichtmetriken statt
  einer vagen Frage: die **Füllung der Postgres-Notify-Queue** (läuft sie voll, scheitern
  Transaktionen beim Commit) und **Reconnects des `PgListener`** (jeder löst einen
  Resync-Hinweis an alle Verbindungen aus). Der Rest ist noch nicht scharf.
- **Auth-UI bei N Servern.** N Server heißt N Refresh-Zyklen und N Ablaufzeitpunkte — wie
  sieht die Oberfläche aus, wenn Server C eine Neuanmeldung braucht, während A und B laufen?
  Die Speicherfrage ist durch *Wo lebt die WS-Verbindung im Client* geklärt (Liste im Store,
  Geheimnisse hinter dem `SecretStore`-Trait); die UI-Seite hängt an
  *Verbindungsaufbau & Auth über WS*.
- **Rollenmodell für Conversations und Voice-Rooms.** Erklärtes Ziel: Rollen sollen später
  steuern, welche Conversations und welche Voice-Rooms für wen sichtbar und betretbar sind.
  *Voice-Signaling-Protokoll* hat dafür die Naht gesetzt — Autorisierung läuft durch genau eine
  Funktion, damit kein raumspezifisches Modell entsteht. Das Modell selbst ist noch nicht
  scharf: `workspace_members.role` kennt heute nur `owner`/`admin`/`member`, ein
  Berechtigungsbegriff fehlt völlig.
- **Mobile-Plattform-Setup vor der Implementierung.** `src-tauri/gen/android` und
  `gen/apple` existieren noch nicht — Mobile ist nie initialisiert worden. Dazu die sieben
  Experimente aus §8 der WebRTC-Recherche, allen voran E1 (`getUserMedia` auf einem
  physischen iPhone, je einmal mit und ohne Info.plist-Key) und E2
  (`MODIFY_AUDIO_SETTINGS` wirklich zwingend?). Blockiert die Spec-Arbeit **nicht**,
  gehört aber vor die Implementierung — vermutlich als Task-Ticket im Umsetzungs-Effort.

## Out of scope

- **Vollständiges E2EE-Design** — Schlüsselverwaltung, Multi-Device-Sync (Desktop + Mobile
  parallel ist gefordert), Rotation, Gruppen-Mitgliederwechsel, Geräteverlust,
  Attachment-Verschlüsselung. Eigener Folge-Effort in der Größenordnung dieses hier.
  In *dieser* Map steckt davon nur, was das Protokoll heute festlegen muss.
  **Neu bekannte Kopplung (14.08.2026):** *sicheres* Voice hängt am E2EE-Effort. Der
  Signaling-Server kann DTLS-Fingerprints tauschen (RFC 8827), und der Gegenmechanismus
  verlangt, den Fingerprint signiert durch einen E2EE-Kanal zu übertragen — den es heute
  nicht gibt. *Voice-Signaling-Protokoll* legt die Naht fest, kann sie aber nicht einlösen.
  Voice ist damit erst nach dem E2EE-Effort gegen den Betreiber geschützt.
  **Zweite Kopplung:** `voice_rooms.name` ist nutzererzeugter Inhalt und fiele unter die
  Blob-Regel — aber ein neues Workspace-Mitglied müsste die Raumliste lesen können, ohne
  vorher Schlüsselmaterial zu haben. Ein Schlüsselverwaltungsproblem, das dort gelöst gehört.
- **Audio-Übertragung selbst** — WebRTC-Peers, Codecs, Echo-Cancellation, SFU-Betrieb.
  Dieser Effort endet beim Signaling.
- **Push-Notifications / Background-Delivery auf Mobile** — FCM/APNs, Delivery-Queue,
  Wakeup-Semantik. Orthogonale Infrastruktur.
- **Föderation (Server-zu-Server)** — bewusste Produktentscheidung: isolierte Instanzen
  sind das Differenzierungsmerkmal gegenüber Matrix, nicht der Rückstand. Der Client
  verbindet sich zu mehreren Servern; die Server reden nie miteinander.
- **Wahl der `SecretStore`-Implementierung** — *Wo lebt die WS-Verbindung im Client* hat die
  Naht festgelegt (Tokens und Refresh-Tokens hinter einem Trait mit zwei Methoden), die
  Implementierung aber bewusst an den E2EE-Effort abgegeben: der hat dasselbe Problem für
  Geräteschlüssel, in verschärfter Form. OS-Keychain ist der naheliegende Kandidat, hat aber
  auf Linux die schwächste Stelle (Secret Service braucht gnome-keyring oder KWallet).
- **Portable Schlüssel-Identität** (Schlüsselpaar statt Server-Account als Identität) —
  reizvoll im E2EE-Kontext, aber eine Entscheidung des E2EE-Efforts. Lässt sich später
  ergänzen, ohne den WS-Layer zu brechen.
- **Mehr-Instanz-Betrieb** — Sticky Sessions, Load-Balancer-Konfiguration, Deployment.
  Im Scope ist nur die *Trait-Naht*, die den späteren Wechsel ermöglicht.
- **Serverseitige Suche** — unter E2EE ohnehin tot; braucht clientseitige Indizes.
- **Metadaten-Minimierung** (Sealed Sender, Padding) — widerspricht direkt der Entscheidung,
  Read-Receipts und Presence überhaupt zu wollen.
- **TURN-Betrieb** (coturn-Konfiguration, Credential-Rotation) — optionale externe
  Abhängigkeit, nicht Teil der Spec.