The longversion.

In a Livara chat, the message body and any media are sealed on your device and opened only on the recipient's device. The server moves a box it cannot open.

Each device holds P-256 and ML-KEM-768 private material that never leaves it. The 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. Attachments receive a separate random file key before upload, carried inside the encrypted conversation instead of being exposed to the server.

The server only relays the encrypted ciphertext to deliver it to your devices, keeping your conversations completely private.

All direct chats and private group conversations are fully end-to-end encrypted on your device. Only public broadcast channels are open by design.

Direct message text, edits, captions, voice notes, and attachments are encrypted on your client device using the hybrid post-quantum LVR1 ratchet. If keys are missing or invalid, sending fails closed rather than silently downgrading to plaintext.

Livara 0.9.52 provides LGS1 sender-key end-to-end encryption for private groups. Each member creates a cryptographic sender chain and encrypts text, media, and attachments directly on their device. Whenever members join or leave, keys are automatically rotated to maintain forward secrecy and privacy.

Direct calls and 2–6-person Android group rooms use WebRTC DTLS-SRTP encrypted peer media with pairwise-sealed signaling for audio, video, and screen sharing. Broadcast channels remain public and server-readable by design for broadcast publishing.

Retired server-stored identity history copies for new encrypted messages.

Retired server-stored identity history copies for new encrypted messages.

Encrypted message history is now retained only in the device's encrypted local storage.

Secure accounts can no longer downgrade while encrypted conversations still exist.

Includes a verified incremental patch from the previous Android build.

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.