Desktop client cannot connect to a self-hosted relay using a private CA (tokio-tungstenite pinned to webpki-roots)

Start with Cargo.toml:123, desktop/src-tauri/Cargo.toml:86, and desktop/src-tauri/src/native_websocket.rs; compare the tokio-tungstenite TLS features and the connect_async(url) call. Reproduce against a relay using a private CA installed in the OS trust store, then verify the desktop WebSocket connects and the connection banner and live message updates work without a rebuild-specific fork.

Describe the bug

The desktop client cannot open a WebSocket to a self-hosted relay whose TLS certificate chains to a private/internal CA.

tokio-tungstenite is pinned to the rustls-tls-webpki-roots feature, which compiles in a fixed list of public CAs and cannot read the OS trust store. native_websocket.rs calls connect_async(url) with no custom Connector, so that feature decides everything and there is no way to supply an internal root.

The symptom is unusually confusing to diagnose: the webview's HTTP requests succeed, because those use system trust. So the app looks functional — you can authenticate, create channels and send messages — while the connection banner is permanently wrong and there is no live push. New messages only appear after a manual refresh. It reads like a server outage, but the client never attempts the WebSocket at all.

Steps to reproduce

1. Stand up a self-hosted relay behind TLS with a certificate issued by an internal CA that IS installed in the OS trust store.
2. In the desktop client choose "I already have a community" then "I'm a member or admin", and enter the relay URL as https://relay.example.internal (normalizeRelayUrl maps https to wss).
3. Authentication succeeds and HTTP-backed actions work, but no WebSocket is ever established. The sidebar shows "Can't reach the relay" while messages still send over HTTP.

Expected behavior

The client should be able to trust a CA that is already present in the operating system's trust store, so a self-hosted relay with an internal certificate works without patching and rebuilding.

Any of these would resolve it:

• switch the feature to rustls-tls-native-roots
• keep webpki-roots and add native roots alongside it
• build a custom Connector from OS roots, optionally plus an extra CA path supplied by config or env

Version and platform

• Buzz version: 0.5.0 (desktop .deb). Also verified still present on origin/main at 346ae8cad on 2026-08-07.
• OS: Ubuntu 24.04.3 LTS

Logs / additional context

Relevant lines on main today:

• Cargo.toml:123 — tokio-tungstenite = { version = "0.29", features = ["rustls-tls-webpki-roots"] }
• desktop/src-tauri/Cargo.toml:86 — same
• desktop/src-tauri/src/native_websocket.rs — connect_async(url), no Connector

Workaround we are using: change the desktop feature to rustls-tls-native-roots and rebuild. It is a one-line change and it works, but it means maintaining a fork and rebuilding on every release.

Two things that may be worth weighing:

• The self-hosting documentation points at private CAs, so this affects the documented deployment path rather than an exotic setup.
• buzz-cli is NOT affected. It is HTTP-only via reqwest → hyper-rustls → rustls-native-certs, so it uses the OS trust store and works against the same relay unpatched. That asymmetry between the CLI and the desktop client is what made this take a while to isolate.