The longversion.

In a Livara one-to-one chat, the message body and any media are sealed on your device and opened on the other person's. The server moves a box it cannot open.

Each device holds P-256 and ML-KEM-768 private material that never leaves it. The strongest direct-chat mode establishes LVR1 with classical and post-quantum contributions, then advances a one-way sending and receiving chain for every message.

AES-256-GCM seals the content and authenticates its context. Direct attachments get a separate random file key before upload, carried inside the encrypted conversation instead of being exposed to the server.

The server still stores the sealed box, who it is addressed to, and when it was sent. That is how your second device catches up, and it is also the honest edge of the design.

Direct chats and compatible private-group text and media are sealed on devices. Channels, reactions and some control relationships are not fully covered.

Direct message text, edits, captions and attachments are encrypted on the client. Current secure direct chats use the LVR1 ratchet; older supported direct chats retain their explicitly shown encryption level. Missing key material stops the send instead of quietly downgrading it.

Livara 0.9.16 uses LGS1 sender-key E2EE for compatible private-group text, edits and the messages that carry unique attachment keys. New encrypted groups require every member to have current keys; honest membership changes make old sender keys stale and force rotation.

The delivery service still controls and sees group membership, so a compromised server can insert an account before key redistribution. Channels, reactions and some control relationships remain server-readable. Direct calls and 2–6-person Android group rooms use DTLS-SRTP media with pairwise LVR1/LCS1-sealed signaling; call media is not post-quantum.

Calls now survive answering across regional servers, reject duplicate accept frames safely, and keep critical control events responsive during noisy ICE traffic.

A regional accept now tells only other still-ringing devices that the call was answered elsewhere. It never sends the answering device a call-ended frame, so picking up no longer tears down the connection immediately.

Web and Android ignore duplicate encrypted accept frames while the first answer is opening. That prevents a harmless duplicate from being treated as an authenticated replay and converted into a hangup.

The LCS2 signaling handshake keeps one authenticated compatibility copy until both clients prove the newer session is live. A lost in-memory session can recover from that copy, while a genuine authentication failure still fails closed.

Accept, reject, end, resume and rebind events bypass the shared soft socket budget so ICE bursts or another busy tab cannot make an answer disappear. Starting a new call retains its separate abuse limit.

Devices on build 113 install build 114 from a verified incremental patch instead of downloading the complete APK again.

A recovery phrase unlocks an encrypted backup of your agreement, signing and post-quantum identity material. It is not a chat-history backup.

Your P-256 agreement key, P-256 signing key and ML-KEM seed are bundled and sealed on your device with a random 256-bit recovery key, HKDF-SHA-512 and AES-256-GCM, then uploaded already encrypted. A correct password on its own cannot open it.

Backup format v7 authenticates its version, suite, identity epoch and monotonically increasing generation. A returning device can detect an older backup; a brand-new device still needs key transparency to detect a complete server snapshot rollback.

You can compare public-key fingerprints with the person you are talking to, over some other channel, to catch a key that changed when it should not have.

Lose the device and the phrase together and the old direct-chat ciphertext stays closed. No support ticket reverses this. That is the actual price of a server that cannot read your messages.

A live connection only tells you what is happening now. A per-user sequence number repairs whatever you missed while the train was in a tunnel.

Every messenger keeps a connection open; that part is table stakes and not worth a paragraph. The interesting question is what happens the moment it drops.

Every relevant change also advances a contiguous per-user sequence number, so a client that reconnects asks for exactly the range it missed instead of guessing, and instead of re-downloading your whole account.

Clients de-duplicate on stable operation IDs and reconcile against the server's snapshot before moving their saved cursor forward — which is why one thought sent through a bad signal does not become three bubbles.