# 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](https://docs.witbitz.chat/docs/room-link-auth.md).
- **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](https://docs.witbitz.chat/docs/the-double-blind.md) 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](https://docs.witbitz.chat/docs/the-double-blind.md) and the "not protected" column of
  [Sealed Spaces](https://docs.witbitz.chat/docs/the-double-blind.md)). 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](https://docs.witbitz.chat/docs/the-double-blind.md) (incl. Sealed Spaces) and
[the verified room § lifecycle](https://docs.witbitz.chat/docs/room-link-auth.md).
