The Companion — an optional device runtime
Status: roadmap, and now optional. The three things this was meant to add — notifications, durable keys, local decryption — the verifiable web app already does. The Companion remains a worthwhile convenience (more reliable background notifications, a Secure-Enclave keystore), but it is no longer a pillar of the platform, and nothing on the roadmap depends on it shipping.
A Witbitz app is a pure static page — which is exactly what makes its privacy checkable. A static page famously can't, on its own, hold a key safely, notify you while you're away, or decrypt locally. The Companion was conceived as the one native app that would carry those "un-static" capabilities for every Witbitz app.
Since then, the web caught up. Here is how each capability is handled today, with no app — and what a Companion would still add on top.
How it's handled without the Companion
- Reach-me → installed-PWA push. Add a Space to the home screen and the platform can reach you with a content-free push (a "something happened" tickle); the device fetches and decrypts locally. Works on iOS (16.4+, installed), Android, and desktop.
- Keys → a passkey, not a link. A passkey (WebAuthn, hardware-backed, synced by your provider — 1Password, iCloud Keychain) holds the room secret, so it stops riding the URL. See the verified room § lifecycle.
- Recovery → user-held. An encrypted recovery — a code, or a passkey-derived secret — that you control and the server can't read. Lose a link, still get back in. Never an operator key.
- Local decrypt → in the verifiable client. The reproducibly-built, egress-locked page decrypts in your own tab today; Sealed Spaces is the design that makes the key never reach the server at all — structural at-rest blindness, no native app required.
That covers the essentials — and the web version is, if anything, more verifiable than an app would be: a CSP-locked, reproducible static page is something a third party can check; an app-store binary is not.
What a Companion would still add
A thin native app is worth building as a convenience, never a foundation:
- More reliable notifications than web push, which is limited on iOS and only fires once installed.
- A Secure-Enclave keystore — hardware-isolated keys, a step beyond browser-held ones.
- One presence across every Space, and plain app-store legitimacy.
The honest boundaries
- It does not close the in-use gap. The agent turn runs on server compute, so an agent still decrypts server-side until the attested / on-device inference tier (see the double blind and the "not protected" column of Sealed Spaces). A client-side Companion doesn't change that.
- It's a convenience, not a requirement. The platform stands on the verifiable web and Sealed Spaces; the Companion is a nicety for people who want it, and can arrive whenever — or never — without moving the trust story.
Where it sits
| Capability | Today, no app | A Companion would add |
|---|---|---|
| Key storage | passkey (hardware-backed) + link fragment | Secure-Enclave keystore |
| Recovery | user-held code / passkey-derived secret | same, device-native |
| Notifications | content-free push on an installed PWA | more reliable background delivery |
| Local decrypt | in the verifiable tab; Sealed Spaces removes the key from the server | one audited runtime |
| Agent turn (in use) | server-side until the attested tier | unchanged — not what a client app fixes |
See also: the double blind (incl. Sealed Spaces) and the verified room § lifecycle.
Machine-readable source: the-companion.md · every doc in one fetch: llms-full.txt · ← delegated-authority · on-prem →