Learn

Use this section before you integrate end-to-end encryption. It explains whether the architecture fits your product and what the change will cost.

Nothing here is specific to this SDK. It is the model every Signal Protocol implementation obeys. Use it to evaluate this project's claims. Limits and metadata and the threat model support that evaluation. These pages identify product promises that the implementation cannot support.

The order these build in

1. E2EE is not TLS: the distinction the rest of the section rests on. If your encryption terminates at your server, none of what follows applies to you. Start here even if you are certain you already know it, because the difference is not about strength. It is about who holds what.

2. How E2EE changes your architecture: understand the structural consequence. A server-authoritative CRUD application becomes device-authoritative. The required client-side logic defines the project size.

3. Keys, identity, and sessions: the vocabulary. The composite identity tuple, the four lifetimes of key material, and what a session actually is. Every later page assumes these terms.

4. Local-first and offline-first: learn why the design requires the local store and makes the relay optional. This page explains the design choice. It also identifies unresolved local-first problems.

5. Limits and metadata: the exhaustive, cited inventory of what remains visible to whoever runs the relay. Encryption is not anonymity, and the gap between those two is where most user-facing claims break.

6. Threat model: review the adversaries that the implementation does and does not resist. Check the post-quantum policy, specification pins, and audit status.

Then

If you decide to build, Start creates an encrypted round trip in six lines. Choosing adapters defines the first architectural constraint.

If you are still evaluating and want the exact surface rather than the model, go straight to Reference.