Security model and boundaries

Message bodies and attachments are encrypted on the endpoint with AES-256-GCM. Signing keys are created through WebCrypto and remain non-exportable. Exchange keys are preferably persisted as non-exportable CryptoKey objects; iOS/WebKit uses a documented JWK fallback while persistent CryptoKey handles remain unreliable.

Conversation keys are wrapped separately for each authorised device using ECDH and HKDF. In the version-3 path, session establishment combines X25519 with ML-KEM-1024; the server transports key material and ciphertext but should not hold a content key.

Profile images are outside this E2EE claim: retrieval requires authentication and storage is protected at rest, but the service can read the images. An existing communication relationship is not required when an exact account identifier is resolved.

• X25519 + ML-KEM-1024 for hybrid PQXDH in version 3
• Versioned key envelopes per device
• Encrypted message editing
• Local decryption into short-lived file URLs

Since 6 September 2026, the controlled version-3 path has been active in production. For capable devices, it establishes sessions through hybrid PQXDH with X25519 and ML-KEM-1024; the derived secret becomes only the root key of the following Double Ratchet. Signed and one-time prekeys plus a per-device-pair guard prevent silent fallback after the pair has used version 3.

The current protection is deliberately bounded: the post-quantum component covers new session establishment, not a continuously post-quantum ratchet. Conversations containing devices that are not yet capable use a documented, versioned compatibility path. The architecture is inspired by publicly documented Signal protocol principles but is independently implemented, not Signal-compatible and not libsignal.

The public record names the architecture, algorithms, rollout boundary and known limitations. Detailed protocol mappings, test vectors, mutation evidence and implementation material remain controlled review documents and are made available only within an expressly agreed confidential review or audit scope. Restricted access does not replace independent security evidence.

On 9 September 2026, the current state was re-run with 308 mapped counter-tests, 19 real-browser runs and 189 browser checks. Multi-device, concurrency, downgrade, recovery, revocation, timestamp and schema-to-migration paths were green within the executable scope.

After the metadata work, message rows no longer store senderId; signed authorship is inside encrypted content. Direct-chat pair values are HMAC-derived, key envelopes use opaque recipient marks, and reactions, favourites and mentions use conversation-scoped member references. New read state uses the membership sequence rather than creating receipt rows, while legacy rows age out under the 30-day retention window.

Opaque membership references are bound to cryptographic possession proofs. In the current source/test state, the client reconstructs the identifier directory from encrypted account state on cold start and counts the proof only after one was actually sent. History transfers there use one computed opaque target mark and skip older unmarked envelopes rather than guessing their destination. The live signed runtime still requires a separate app release and migration for these changes.

Affected timestamps are reduced to minute granularity. Realtime output is limited to the explicitly defined contract fields; local drafts, interface preferences and safety verification are account-scoped and covered by the revocation and cleanup path.

This is metadata minimisation, not metadata absence. The running service still requires limited account, relationship, device, timing, media-type and ciphertext-size information for authorisation and routing. The membership table currently retains an account identifier and the primary display name remains stored in the account row; temporary invitation paths and legacy receipts have separate removal and retention boundaries.

• Routing relationships and conversation memberships in the running service
• Time, membership read sequence and approximate activity
• Attachment media type and ciphertext size
• Controlled compatibility paths for records not yet fully provisioned
• IP and security records according to the operating policy

Safety numbers expose key changes. An optional strict mode can block sending to unverified devices.

Voluntary verification protects only when people compare the number over an independent channel and respond to warnings.