End-to-end encryption research

Status: research only. Claire does not currently offer end-to-end encryption or zero-knowledge messaging. This page records the boundary, the work required to change it, and the claims Claire must not make before that work is independently verified.

Current trusted-service boundary#

text

Provider network → hosted mautrix bridge → Synapse → Claire API → database / search / configured AI → Claire client

Claire Cloud normalizes and stores message data so the unified inbox, search, suggestions, promise detection, summaries, and Ask Claire can work. The hosted bridge must also process message content briefly to speak each provider’s protocol. Claire Cloud is therefore a trusted service for messaging and AI today.

What a real E2EE claim would require#

“End-to-end encrypted” is not a synonym for TLS, encrypted disks, encrypted database backups, or double puppeting. It means only the intended endpoint devices hold the keys needed to read the protected content for the specific flow being described.

Protection	Useful?	What it does not prove
TLS and encryption at rest	Yes	A hosted Claire service still receives and can process plaintext.
Matrix end-to-bridge encryption	Yes	It can protect Matrix events from the homeserver, but a hosted bridge still handles provider messages.
Double puppeting	Yes	It improves message identity and delivery behaviour; it is not message encryption.
Client-held keys plus a local connector	Required for a zero-knowledge Claire boundary	It does not change the external provider’s own security model.

Mautrix documents end-to-bridge encryption as a way to hide bridged Matrix events from the homeserver. Its strongest privacy example uses a bridge hosted locally, not as a blanket promise for a hosted bridge. See the official mautrix encryption guide.

Future design questions#

Device identity keys in iOS Keychain, Android Keystore, and desktop secure storage.
A user-held recovery phrase and verified-device flow; Claire must not be able to recover keys unilaterally.
Per-device encryption envelopes, device revocation, key rotation, and offline-device recovery.
A local Claire Connector that receives provider plaintext and encrypts before cloud sync.
Explicit migration and deletion behaviour for existing cloud history, search indexes, embeddings, AI outputs, media, and backups.
On-device AI, or a separate, time-bounded cloud-processing consent for AI features.

Release and claim gates#

Write and externally review a threat model
Cover the app, bridge, Matrix, database, push, recovery, compromised device, lost device, and provider boundaries.
Use audited cryptography, never a custom protocol
Publish protocol/version choices and cross-platform test vectors before any opt-in rollout.
Prove the scoped flow
Test send, receive, media, recovery, revoke, bridge restart, offline devices, logs, telemetry, notifications, and backup deletion.
Publish exact scope before using the words E2EE or zero knowledge

What Claire improves now#

The current roadmap is not blocked on E2EE. Claire can harden its trusted-service model by encrypting existing session material and sensitive caches at rest, keeping content out of logs and operations telemetry, enforcing least-privilege access and audited operations, and making retention and deletion behaviour visible to users.

These controls reduce risk; they do not change Claire Cloud into a zero-knowledge service.