How this works under the hood.
Every privacy-bearing capability is anchored to a public design record. The page below describes each capability + the architecture that enforces it.
01 The shape of the system
Mobile + web clients hold the keys. A Cloudflare Workers gateway routes ciphertext to a confidential-compute TEE running an open-weight LLM (Llama-class, currently served via Phala Cloud on TDX + Confidential GPU). The Worker is a confidential gateway, not an enclave — Cloudflare sees only ciphertext for conversation content. The TEE is the trust boundary users verify, not the Worker.
02 End-to-end encryption
Conversation bodies, transcripts, and recaps are ciphertext in our R2 storage; metadata-only rows live in D1. Per-conversation keys are derived from a libsignal-style on-device Ed25519 / X25519 identity keypair sealed in the OS keystore (iOS WhenUnlockedThisDeviceOnly; Android setUserAuthenticationRequired(true) with a 5-minute validity window). The server never holds a user private key.
03 Attested confidential inference
Before sending plaintext, the client fetches the inference TEE's signed attestation receipt (dstack-v1 format) and verifies the measurement matches a published policy at /.well-known/attestation-policy.json. On mismatch the client refuses to send — there is no silent fallback to a non-attested LLM. Closed frontier models (GPT / Claude / Gemini-class) are explicitly excluded from the inference path because they cannot be deployed in a customer-verifiable TEE.
04 Voice calls
LiveKit-mediated rooms with mandatory E2EE Insertable Streams and a load-bearing application-layer cipher layered on top. The client probes for Insertable Streams availability at room-join time and refuses to start the call if the platform API is unavailable. The SFU sees opaque RTP frames, never decoded audio.
Verified end-to-end. We boot the OSS LiveKit server, drive a real call through both the cipher and the SFU, and assert that none of the frames the SFU receives decode as audio. Two complementary checks run side-by-side: the cipher's own output sampled before it hits the network, and the bytes the SFU actually reads after transport-level decrypt. If either path lets an intelligible audio frame through, the test fails.
05 Audio understanding
Every audio path on every plan rides to the same place: a TEE-hosted audio-native multimodal model. Audio is encrypted on-device against the attested enclave's public key and decrypted only inside enclave memory; the model (Qwen2.5-Audio-7B-Instruct primary, Phi-4-multimodal configured fallback) returns transcript + structured analysis (speaker turns, sentiment, prosodic notes) encrypted to the client's session key. The company sees ciphertext, the cloud provider sees ciphertext, the audio enclave is the only thing that ever sees plaintext.
Offline behaviour: when the TEE path is unreachable (attestation failure, no network), the client buffers the audio locally (encrypted-at-rest on the device) and uploads it to the TEE the moment connectivity returns. The transcript shows up in the conversation once the deferred upload completes. The local buffer never transcribes — there is no on-device speech-to-text path that could produce a non-TEE transcript. Cloud STT vendors (Deepgram, AssemblyAI, OpenAI Whisper, etc.) are not in the inference path: they cannot run in a customer-attestable TEE, and the architecture commits to "the company can never even theoretically see a non-multimodal transcript."
06 Sharing
A per-resource wrap model: each shareable artefact carries a per-resource symmetric key wrapped to each recipient's identity key. Revoking a share rotates the wrap and removes the recipient's wrapped copy — the recipient's device loses the key. There is no "we promise to delete" handshake; the cryptography enforces it.
07 Recovery
Three options, user-selected at User creation (no skip path, no default-accept): passphrase, paired device, or both. The recovery blob is OPRF-hardened against offline brute force using an SVR2-style protocol; an attacker who steals the encrypted blob cannot mount an offline dictionary attack. Passphrases require zxcvbn ≥ 5. No magic-link recovery path that would leak the user's identity to whoever runs the SMTP relay.
08 Audit log
Every privacy-bearing action writes one INSERT-only row to a per-user hash-chained log. The chain head signs to the user's identity key at user-determined intervals, producing tamper-evident checkpoints. A server that rewrote history would produce a hash-chain break the client detects on next sync.
09 Encrypted export
One binary format (tt-backup/v1, extension .ttbk) covers GDPR portability, the self-delete-with-export path, and future device-transfer. Protobuf-framed stream encrypted under a user-held key with XChaCha20-Poly1305 chunked at 1 MiB; signed by the user's identity key; size-padded to a 1.05× bucket curve to bound the size-correlation signal. Offline-readable by an open tool.
10 Device pairing
New devices pair via X3DH with a user-verified short authentication string (SAS). The Worker is the relay, not part of the trust chain — a malicious relay cannot substitute its own key without producing a visible SAS mismatch. Every pairing flow on the site goes through this primitive.
11 Cost cap
Inference is quota-gated at the gateway: per-User + per-Account Durable Objects enforce request and spend ceilings, with a global spend-cliff that halts all inference if hit. Quota-hit produces a clear user-facing message; the system fails closed rather than running up a surprise bill on the user or the company.
12 Push notifications
APNs / FCM never see Private Data. Every push payload is a generic envelope plus opaque ciphertext drawn from a small catalogue of kinds; the client decrypts on receipt. iOS uses an NSE; Android uses FCM data-only.
13 Identity vs. account
Two distinct authentication tiers: the Account session (Better Auth — email / Google OAuth / Apple Sign-In / phone OTP) authorises billing + account ops; the User identity key authorises Private Data access. The Account session alone is insufficient to read Private Data; operations that touch it perform an on-device signature or decryption with the keystore-sealed identity key. Every User is their own Account-Owner by default; Account-removal of a User starts a 180-day claim window rather than deleting Private Data.