OpenE2EE

Build

The application architecture above the protocol, ordered by the sequence the decisions actually arrive in — from device registration through to the recovery policy you cannot avoid choosing.

The SDK owns the cryptography. This section is about everything the SDK deliberately does not own, which is most of what makes an encrypted application work.

The ordering below is not arbitrary and it is not alphabetical: each page settles a decision the next one assumes. Read in sequence the first time. Later, come back to whichever page names the problem you have.

The order these build in

  1. Device registration and lifecycle: learn how a user becomes a set of devices and who allocates device IDs. Everything else addresses a device, so this comes first.

  2. Local encrypted storage: understand the only required adapter and the one place private keys exist. The vault and store serve different purposes. Do not blur them.

  3. Relay and prekey infrastructure: learn what a relay must do and what it never needs. Review the exact prekey batch sizes, thresholds, and rotation intervals. A relay has correctness obligations that are not obvious.

  4. Convex relay integration: if Convex is your backend, review the adapter and the artifact in each table. Skip this page if you do not use Convex.

  5. Encrypted attachments and object storage: understand the two encryption layers for large payloads. Learn how the missing Web Crypto streaming API shapes attachment memory behaviour.

  6. Offline send, receive, and reconciliation: handle out-of-order and skipped messages. Learn what the subscription APIs cover and which offline tasks remain yours.

  7. Multi-device: link a second device and understand the difference between provisioning and transfer. Learn why a new device cannot read earlier messages. Teams often discover that limit late, which increases costs.

  8. Groups: compare the two group APIs, what each solves, and why member removal must rotate keys.

  9. Identity changes and safety numbers: generate safety numbers and handle identity-key change errors. Design a verification flow that users can complete. This work connects the protocol to the user interface.

  10. Recovery, backup, and migration: answer the "lost device" question with three named threat-model profiles. No profile is the correct default. This page comes last because it depends on every earlier decision. If you omit the choice, you select the first profile.

Then

Operate covers production operation: rotation, revocation, observability without plaintext, and failure modes that fail silently.

For exact surfaces rather than architecture, Reference has the client API, the adapter contracts, and the error taxonomy.

On this page