Linux: in-app calls need WebRTC in WebKitGTK (blocked on upstream 2.56 libwebrtc) #21

New Issue

2026-09-27T16:57:15-04:00

jared commented

2026-09-27 16:57:15 -04:00

Linux desktop: in-app calls need WebRTC in WebKitGTK (blocked upstream)

Status: blocked on upstream WebKitGTK. Not ours to build: we wait for the backend to ship, then check it.

Why calls don't work in the Linux app

The Linux desktop app (Tauri) renders with the system WebKitGTK, and no current WebKitGTK build has WebRTC:

Arch webkit2gtk-4.1 2.52.6: RTCPeerConnection is undefined even with enable-webrtc on. Verified 2026-09-27 in an Arch chroot: getUserMedia/getDisplayMedia exist, the peer connection doesn't.
Our AppImage bundles Ubuntu's webkit2gtk-4.1, also without GstWebRTC (no webrtcbin).
WebKitGTK 2.54 disables WebRTC entirely while the GStreamer backend is replaced by libwebrtc (2.54 highlights).
Upstream plan: "We hope to enable WebRTC support by default in the 2.56 series, scheduled around March 2027" (Igalia WIP-71).

Element Call (LiveKit) needs RTCPeerConnection plus encoded transforms (RTCRtpScriptTransform) for encrypted media. Calls work in the web app and the Windows app (WebView2).

What ships meanwhile

cinny calls-open-in-browser + this repo's webAppUrl: where the desktop app can't make calls, it explains why and offers Open in browser / Answer in browser. That opens the room in the web app; the user presses Join there.

When this unblocks

WebKitGTK ≥ 2.56 is in Arch/Ubuntu with WebRTC (libwebrtc backend) enabled.
Check that encoded transforms (RTCRtpScriptTransform) are supported, since Element Call's E2EE needs them.
Rebuild and test: 1:1 plus a 3-person encrypted Element Call, screenshare on Wayland/X11, mic permissions (src-tauri/src/lib.rs permission handler).
The "Open in browser" fallback then turns itself off, because webRTCSupported() becomes true.

Alternatives considered (research, 2026-09-27)

tauri-plugin-webrtc (CrabNebula): an RTCPeerConnection shim for WebKitGTK in Rust, claims Element Call + E2EE support. Published 2026-09-27; too new to trust yet. Worth revisiting if it matures before 2.56.
CEF (Chromium) runtime for Tauri (e.g. SableClient/tauri-runtime-cef): works, but it's pre-release and X11-only, adds about 150 MB, and the Chromium security updates become ours.
Electron for Linux: a second desktop stack to maintain.
Building our own WebKitGTK or using a Flatpak runtime: dead ends, since no runtime ships WebRTC.

## Linux desktop: in-app calls need WebRTC in WebKitGTK (blocked upstream) **Status:** blocked on upstream WebKitGTK. Not ours to build: we wait for the backend to ship, then check it. ### Why calls don't work in the Linux app The Linux desktop app (Tauri) renders with the system WebKitGTK, and no current WebKitGTK build has WebRTC: - **Arch `webkit2gtk-4.1` 2.52.6:** `RTCPeerConnection` is undefined even with `enable-webrtc` on. Verified 2026-09-27 in an Arch chroot: getUserMedia/getDisplayMedia exist, the peer connection doesn't. - **Our AppImage** bundles Ubuntu's webkit2gtk-4.1, also without GstWebRTC (no `webrtcbin`). - **WebKitGTK 2.54** disables WebRTC entirely while the GStreamer backend is replaced by libwebrtc ([2.54 highlights](https://webkitgtk.org/2026/09/16/webkitgtk-2.54-highlights.html)). - **Upstream plan:** "We hope to enable WebRTC support by default in the **2.56** series, scheduled around **March 2027**" ([Igalia WIP-71](https://blogs.igalia.com/webkit/blog/2026/wip-71/)). Element Call (LiveKit) needs `RTCPeerConnection` plus encoded transforms (`RTCRtpScriptTransform`) for encrypted media. Calls work in the web app and the Windows app (WebView2). ### What ships meanwhile cinny `calls-open-in-browser` + this repo's `webAppUrl`: where the desktop app can't make calls, it explains why and offers **Open in browser** / **Answer in browser**. That opens the room in the web app; the user presses Join there. ### When this unblocks 1. WebKitGTK ≥ 2.56 is in Arch/Ubuntu with WebRTC (libwebrtc backend) enabled. 2. Check that encoded transforms (`RTCRtpScriptTransform`) are supported, since Element Call's E2EE needs them. 3. Rebuild and test: 1:1 plus a 3-person encrypted Element Call, screenshare on Wayland/X11, mic permissions (`src-tauri/src/lib.rs` permission handler). 4. The "Open in browser" fallback then turns itself off, because `webRTCSupported()` becomes true. ### Alternatives considered (research, 2026-09-27) - **[tauri-plugin-webrtc](https://github.com/crabnebula-dev/tauri-plugin-webrtc)** (CrabNebula): an `RTCPeerConnection` shim for WebKitGTK in Rust, claims Element Call + E2EE support. Published 2026-09-27; too new to trust yet. Worth revisiting if it matures before 2.56. - **CEF (Chromium) runtime for Tauri** (e.g. [SableClient/tauri-runtime-cef](https://github.com/SableClient/tauri-runtime-cef)): works, but it's pre-release and X11-only, adds about 150 MB, and the Chromium security updates become ours. - **Electron for Linux:** a second desktop stack to maintain. - **Building our own WebKitGTK or using a Flatpak runtime:** dead ends, since no runtime ships WebRTC.

linux-call-room.png

70 KiB

linux-incoming-call.png

86 KiB