Operate
Running an encrypted application in production — what you can measure without plaintext, what rotates on its own, what fails silently, and what a security reviewer will ask for.
Operators cannot inspect plaintext when an encrypted system fails. Adding plaintext to diagnostics creates the vulnerability that end-to-end encryption prevents.
Everything in this section follows from that constraint. Read the checklist first to identify missing work. Then read the pages that cover each result.
The order these build in
-
Production readiness checklist: the concrete decisions and wiring an encrypted application needs before it carries real user data. Start here: it is the fastest way to discover which of the pages below you actually need.
-
Error handling and retries: review the full error taxonomy and retry rules. Learn how to recover a session without damaging ratchet state. Retrying the wrong error class can make a recoverable problem permanent.
-
Testing encrypted flows: test a system without reading its contents. Cover the failure paths that teams often miss. Two clients and the in-memory relay give CI an end-to-end assertion without infrastructure.
-
Observability without plaintext: identify safe measurements and prohibited data. Learn why adding plaintext to diagnostics creates a vulnerability.
-
Key rotation: the five rotation cadences, their exact default intervals, and which ones the SDK handles automatically. Prekey exhaustion is the failure here, and it is silent until someone cannot message your user.
-
Deletion and device revocation: define deletion in an encrypted system. Identify the lifecycle operations that revoke access instead of hiding it.
-
Protocol and version upgrades: understand how upgrades affect persisted sessions. Define who owns version negotiation across devices that upgrade at different times.
-
Security review checklist: prepare the evidence that a platform or security team requests. This includes the protocol profile, boundaries, dependency posture, and audit status. The checklist assigns the remaining questions to your team or the SDK.
Then
If a review turns up a gap in the application architecture rather than in operations, the page that owns it is in Build.
Security and protocol policy states spec revision pins, post-quantum defaults, and audit status without softening: it is the page to hand a reviewer directly.