# Voice auf Linux

Type: grilling
Status: resolved
Blocked by: —
Parent: ../map.md

## Question

Was ist die Zusage an Linux-Nutzer bezüglich Sprachanrufen — und wenn Voice dort laufen
soll, über welchen Medien-Stack?

Aufgeworfen von [*Recherche: WebRTC im Tauri-WebView (Mobile)*](01-research-webrtc-tauri-mobile.md).
Die erwartete schlechte Nachricht kam nicht von Mobile, sondern von Linux.

### Befundlage (belegt, siehe §5 der Recherche)

WebRTC ist in Tauris Linux-WebView (WebKitGTK 4.1) an **drei unabhängigen Gates** blockiert:

1. **Compile-Time.** `ENABLE_WEB_RTC` folgt `ENABLE_EXPERIMENTAL_FEATURES`, das auf `OFF`
   steht. Debian/Ubuntu und Alpine setzen es belegbar nicht → `RTCPeerConnection` existiert
   im JS-Global gar nicht. Arch/Fedora unverifiziert (Experiment E5 in der Recherche).
2. **Runtime-Setting.** `WebKitSettings:enable-webrtc` ist Default `FALSE` und wird von wry
   nie gesetzt.
3. **Permission.** `permission-request` ist Default Deny; wry 0.55.1 verbindet das Signal
   überhaupt nicht.

Gate 2 und 3 wären aus dem App-Code über `WebviewWindow::with_webview` lösbar (bzw. ab
Tauri 2.12 sauber über `on_permission_request`). **Gate 1 hängt am Distro-Paket des
Nutzers und ist von uns nicht lösbar.**

Das trifft ausgerechnet die Gruppe, die für dieses Projekt zentral ist: Selbsthoster sind
linux-lastig.

### Optionen, alle unattraktiv

1. **Voice auf Linux als nicht unterstützt deklarieren.** Chat läuft voll, Voice nicht.
   Ehrlich und billig — und wahrscheinlich der Weg, der die Simplizitätsdoktrin am wenigsten
   verletzt. Aber schmerzhaft für die Kernzielgruppe.
2. **Nativer Medien-Stack nur auf Linux.** `livekit/rust-sdks` (`libwebrtc`-Crate, echtes
   libwebrtc mit NetEQ/AEC/Opus, laut README inkl. Linux) im Tauri-Rust-Layer. Bricht die
   Architektur-Einheitlichkeit: Voice läge auf drei Plattformen im WebView und auf einer in
   Rust. Zusätzlich ein großer vorkompilierter nativer Blob pro Plattform.
   *(`webrtc-rs` ist hierfür **kein** Ersatz — es ist ein reiner Protokoll-Stack ohne
   Geräte-Capture, ohne Codecs, ohne Jitter-Buffer, ohne Echo-Cancellation.)*
3. **Nativer Stack auf allen Plattformen.** Einheitlich, aber verwirft den kostenlosen
   WebView-Pfad auf drei von vier Zielen und zieht den nativen Blob überallhin.
4. **Eigenes WebKitGTK bündeln.** Widerspricht der Simplizitätsdoktrin frontal.
5. **Auf Upstream warten.** Löst Gate 2 und 3, **nie Gate 1**. Also keine Lösung.

### Zu entscheiden

- Welche Option — und wie wird die Einschränkung dem Nutzer gegenüber **sichtbar** gemacht,
  statt ihn in einen Timeout laufen zu lassen? (Feature-Detection `typeof RTCPeerConnection`
  ist trivial und sollte in jedem Fall passieren.)
- Falls (2) oder (3): wo verläuft dann die Rust↔WebView-Naht? Bei nativem Audio ist der
  WebView **nicht mehr der Medien-Endpunkt** — Capture und Wiedergabe liegen in Rust, und
  die UI bekommt nur heruntergerechnete Metering-Werte über IPC, niemals rohes PCM.
  Zurück-Injizieren von PCM in den WebView geht in Chromium, aber **nicht** in WebKitGTK.
  Rückkopplung auf [*Wo lebt die WS-Verbindung im Client*](05-wo-lebt-die-ws-verbindung.md).
**Beantwortet (14.08.2026): Linux ist eine vollwertige Client-Plattform.** Damit ist der
billige Ausweg verbaut — Option 1 bedeutet, auf einer erklärten Zielplattform ein
Kernfeature nicht anzubieten. Sie bleibt formal wählbar, muss aber als bewusster
Produktverzicht begründet werden, nicht als technische Notwendigkeit.

Realistisch bleiben damit **(2)** nativer Stack nur auf Linux und **(3)** nativer Stack
überall. Die eigentliche Frage dieses Tickets ist die Abwägung zwischen diesen beiden:
Einheitlichkeit gegen Kostenminimierung.

### Kopplung

Wirkt auf [*Voice-Topologie*](04-voice-topologie.md) zurück: fällt hier ein nativer Pfad,
ändern sich dort die Optionen. Die beiden Tickets können in beliebiger Reihenfolge laufen,
aber das zweite muss das Ergebnis des ersten kennen.

---

## Answer

Entschieden am 14.08.2026.

### 0. Zusätzlich geprüft: Flatpak löst Gate 1 nicht

Die Recherche hatte Gate 1 als „hängt am Distro-Paket" eingestuft. Das gilt aber nur, solange
der Nutzer das Distro-Paket benutzt — ein Flatpak bringt WebKitGTK aus seinem Runtime mit.
Geprüft, Ergebnis negativ:

- Das **GNOME-Runtime baut WebKitGTK ohne den WebRTC-Flag**; die Antwort im Flathub-Forum auf
  die Frage nach dem Patchen lautete sinngemäß „macht ein Issue bei gnome-build-meta auf"
  ([Flathub Discourse](https://discourse.flathub.org/t/patching-gnome-runtime/10682)).
- Das einzige dokumentierte funktionierende Rezept verlangt, **WebKitGTK selbst zu
  kompilieren** (`-DENABLE_MEDIA_STREAM=ON -DENABLE_WEB_RTC=ON`) **und zusätzlich wry zu
  patchen** — erprobt auf NixOS unter X11, mit GBM-Fehlern unter Wayland und nicht
  aufgelisteten v4l2loopback-Geräten
  ([Tauri Discussion #8426](https://github.com/tauri-apps/tauri/discussions/8426)).

Für ein Entwicklungssystem machbar, für Endnutzer nicht. **Gate 1 hat heute keine
nutzerseitige Lösung.**

### 1. WebView auf drei Plattformen, nativer Stack nur auf Linux

Windows, Android und iOS nutzen den kostenlosen, funktionierenden WebView-Pfad. Linux bekommt
`livekit/rust-sdks` (`libwebrtc`-Crate) im Rust-Layer — echtes libwebrtc mit NetEQ, AEC/AGC/NS
und Opus, laut README inklusive Linux.

`webrtc-rs` ist **kein** Ersatz: reiner Protokoll-Stack ohne Geräte-Capture, ohne Codecs, ohne
Jitter-Buffer, ohne Echo-Cancellation.

Die Alternative „nativ überall" war knapp und hat ein starkes Argument — ein Pfad statt zwei,
eine Berechtigungslogik, eine Testmatrix, und die wry-Eigenheit (Mikrofonrechte werden auf iOS
bedingungslos an jeden Origin vergeben) wäre komplett aus dem Spiel. Sie verliert, weil sie
einen auf drei Plattformen funktionierenden Gratis-Pfad wegwirft. **Der akzeptierte Preis sind
zwei Medienpfade auf Dauer**, mit zwei Berechtigungsmodellen und zwei Fehlerbildern.

**Nützliche Nebenwirkung:** weil Linux den nativen Stack *unbedingt* nutzt und nicht nur dort,
wo die WebView-Variante versagt, spielt es keine Rolle mehr, ob eine Distribution WebKitGTK
mit WebRTC gebaut hat. **Experiment E5 der Recherche (Arch/Fedora prüfen) entfällt damit.**
Und weil es hier nur um Audio geht, ist der GBM-/Wayland-Fehler aus #8426 gegenstandslos — er
betrifft die Videoausgabe des WebViews.

### 2. Die Naht ist eine explizite Verzweigung im Frontend, ganz oben

Rust meldet dem Frontend eine Fähigkeit — sinngemäß `mediaOwner: "webview" | "native" | "none"`
— und das Voice-Modul verzweigt **einmal**, an seiner Spitze. Darunter zwei klar getrennte
Implementierungen: `RTCPeerConnection` im WebView, oder Tauri-Commands in den nativen Stack.

Das ist ehrlich gegenüber der Realität, dass sich die Fälle nicht nur mechanisch
unterscheiden, sondern auch in der Oberfläche: **auf Linux gibt es kein `<audio>`-Element**,
weil PCM sich in WebKitGTK nicht zurückinjizieren lässt (in Chromium ginge es). Der native
Pfad besitzt dort die Wiedergabe vollständig, und Pegelanzeigen kommen als
heruntergerechnete Werte über IPC — **niemals rohes PCM**.

Verworfen: ein `MediaEngine`-Trait in Rust. Es wäre die sauberere Fassade, verlangte aber eine
Steuerungsumkehr — die WebView-Implementierung müsste ihre eigentliche Arbeit per IPC nach
oben ans Frontend delegieren. Ebenfalls verworfen: eine Naht nur auf Signaling-Ebene, weil die
Duplizierung dann bis in die Oberfläche reicht und Verhaltensunterschiede versehentlich statt
absichtlich entstehen.

### 3. Gestaffelt: Voice erscheint zuerst auf den WebView-Plattformen

Linux zeigt Voice solange sauber als „noch nicht verfügbar" an — über die gemeldete Fähigkeit
`none`, **nicht** über eine WebView-Feature-Erkennung, weil die auf Linux dauerhaft negativ
bliebe und nichts über den nativen Pfad aussagt. Chat läuft dort voll.

Das Argument ist Risikoreihenfolge: der WebView-Pfad validiert das Signaling-Protokoll billig
auf drei Plattformen, und der native Stack steckt danach in ein bereits bewährtes Protokoll.
Den schweren, unerprobten Medien-Stack gegen ein gleichzeitig unerprobtes Protokoll zu bauen,
verdoppelt die Unbekannten in einem Schritt — und bei einem Fehler wüsste niemand, welche
Seite schuld ist.

**Bewusst in Kauf genommen:** die Zielgruppe ist linuxlastig, und „Voice, aber nicht bei dir"
ist keine gute erste Begegnung. Wer es einmal als „geht auf Linux nicht" abgespeichert hat,
prüft später nicht nach. Das ist der Preis dafür, das Feature überhaupt in Nutzerhände zu
bringen, bevor Monate in den nativen Stack fließen — und er ist erträglich, weil die Ansage
ehrlich und sichtbar ist statt stillschweigend.

### Folgen für andere Tickets

- [*Voice-Topologie*](04-voice-topologie.md): der native Stack liefert auf Linux echtes
  libwebrtc, Mesh funktioniert dort also genauso. Die Topologie-Entscheidung wird durch dieses
  Ticket **nicht** eingeschränkt.
- [*Voice-Signaling-Protokoll*](09-voice-signaling-protokoll.md): der signierte
  DTLS-Fingerprint muss auf **beiden** Pfaden erzeugbar sein — im WebView über
  `RTCPeerConnection.generateCertificate()`, nativ über die Zertifikats-API von libwebrtc. Die
  Naht für das Pinning darf also nicht an einer WebView-API hängen.