Platforms
The same GUI crate targets web, desktop, and mobile. The TUI is a separate binary that talks to the same glitr-client / api-core mailbox. Treat all four as first-class surfaces. Web is a shipped client, not a footnote.
Product chrome: UI/UX. Client notes: whatsup docs/PLATFORMS.md.
Web first-run profiles and the GUI password field are demo-grade on several rows below. That is product behavior today, not a planned hardening we forgot to mention.
Matrix
| Surface | Web PWA | Desktop | Mobile | TUI |
|---|---|---|---|---|
| Mailbox | Origin-private storage (OPFS) via git-web.js / isomorphic-git | Native gitoxide workdir | App-private files directory; a webview mailbox still needs OPFS | Filesystem workdir or git remote |
| Git network | HTTPS; optional user-supplied CORS proxy (none by default) | Direct HTTPS; optional Tor SOCKS after login | Same as desktop when the native path is used | Same as desktop |
| Identity keys | Real RSA-4096 via WebCrypto on first-run | Real RSA keygen | Real keygen on native path; webview uses WebCrypto | Real keygen |
| Encryption password | GUI does not persist it (tokens still may) | GUI does not persist it (tokens still may) | Same as desktop | Merge does not persist it |
| Live path | webrtc-peer.js + public STUN | Webview RTCPeerConnection where the OS has it; Linux falls back to webrtc-rs for data-channel chat / files | Webview RTC; camera and mic entitlements are incomplete | Native webrtc-rs data channel; paste-to-pair |
| Calls | Voice / video via getUserMedia | Calls stay webview-only; Linux WebKit often has no WebRTC | Not a launch gate; entitlements were never requested by the mock app | Local-only call screens; no A/V |
| Tor / onion | Not linked. Onion chrome hidden. Only via a linked native device | Arti after login: onion pairing, SOCKS for git | Cargo can enable Tor; not a claimed product path | Arti, onion-code paste, Tor status |
| Supply chain | Service worker, GitHub Pages, esm.sh isomorphic-git | Local binary plus embedded webview | Nightly APK / IPA (iOS unsigned) | Local binary |
| QR / camera | jsQR / qr-scan.js | Same webview path | Needs camera permission and those assets | Paste only |
Web
Primary published client. A real mailbox in the browser is WASM plus OPFS. Cross-origin HTTPS remotes need a CORS proxy the user configures (empty by default). A public proxy the user pastes still sees git HTTP.
First-run POST /profile/setup generates a real RSA-4096 identity with WebCrypto. Protocol keys still run in WASM. Connect progress shows the wait.
The GUI persist path does not write encryption_password into glitr:connect. Git tokens may still sit in that store. A same-origin script can read tokens, not the unlock password.
The service worker pins caches, including isomorphic-git from esm.sh. A malicious Pages deploy or a poisoned CDN fetch is a full client compromise. There is no Glitr-operated chat server on this path; the risk is the bytes you execute.
Onion chrome is hidden. A web tab can only send onion or git-over-Tor frames by proxying through a linked native device on an already-open data channel. Details: Tor.
Desktop
Closest to the intended native product: real keygen, filesystem git, optional Tor SOCKS, no CORS proxy for local-only.
Live pairing still prefers the webview (webrtc-peer.js via Dioxus document::eval):
- macOS (WKWebView) and Windows (WebView2) usually expose
RTCPeerConnection. - Linux WebKitGTK is often built without WebRTC. The desktop feature then falls back to a native webrtc-rs data-channel engine so Pair now, live chat, and file transfer still work. Calls stay webview-only.
- Linux also flips WebKit
enable-webrtc/enable-media-streamand allows in-app mic/camera permission requests if the distro library compiled those APIs in.
Onion pairing is the WebRTC-free desktop live path.
The GUI no longer persists the encryption password (tokens may still). The webview bridge (document::eval) is an IPC surface: PWA helpers, WebRTC JS, clipboard, service worker.
Mobile
Nightlies package the same GUI. Mailbox and Tor state use the app-private files directory — writable without a storage-permission prompt. A webview/WASM mailbox still needs OPFS.
Recorded limits (spike, not a launch gate):
| Area | What to expect |
|---|---|
| App storage | Sandbox files dir. No storage permission prompt. |
| WebRTC | Data-channel pairing and calls need the webview’s RTCPeerConnection. |
| Camera / mic | OS entitlements were never requested by the mock app. Add them before testing calls. |
| Keygen | First profile setup can stall on RSA-4096; demo keys stay the web default. |
| QR scan | Needs camera permission and the jsQR / qr-scan.js assets. |
| Tor | Feature can compile in; it is not a claimed product path. |
A successful two-device Android chat is a spike. iOS nightlies stay unsigned. Do not read this row as a shipping mobile security story.
TUI
whatsup-tui logs in against a filesystem (or git remote) mailbox. After a hidden password prompt it shows a connecting splash, then the mailbox UI.
Available: contacts, groups, local file attach, onion-code paste, Tor, native webrtc-rs data-channel live chat, paste-to-pair.
Not available: voice, video, camera QR, real call media.
The TUI persist merge copies mailbox fields (workdir, remotes, display name) and leaves the encryption password as it was — the module does not write it. That is stronger than the GUI default on this one row. Git tokens on saved remotes still persist if you entered them.
How to use the matrix
When a later page says “the host sees IPs,” that is every platform that talks HTTPS to a git host. When it says “Tor,” ignore the web column unless a native device is proxying.
Next: Git mailbox — the path every git-URL contact uses.