How Livara works: The long version.

01 · e2ee

What end-to-end encryption actually means here

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. Recovery backups are encrypted on the device before upload. Direct chats establish LVR1 using classical and post-quantum contributions, then advance sending and receiving chains as messages are exchanged.

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.

For protected message delivery, the server relays encrypted content and handles routing metadata. Public channels and optional AI processing have different data-access rules; see the threat model and privacy policy.

02 · coverage

How end-to-end encryption protects your chats

Direct chats and compatible private groups use end-to-end encryption on your device. Public channels are readable; older incompatible groups are outside this coverage.

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.2 provides LGS1 sender-key encryption for compatible private groups. Each member creates a sender chain and encrypts text, media and attachments on their device. Keys change with group membership; the threat model explains the remaining trust in the server-controlled member list.

Direct and group calls support end-to-end encrypted audio, video and screen sharing. Optional server recording uses transport encryption instead of E2EE while REC is active. Public broadcast channels remain server-readable.

03 · release

Release notes for Livara 0.1.68

Historical release notes. For the current Android build and checksum, use the Download page.

Historical release notes. For the current Android build and checksum, use the Download page.

Persian simple-mode composer displays AI.

AI API features require Livara AI Pro.

04 · recovery

What happens when you lose the device

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.

05 · sync

Why a live connection still needs a ledger

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.

A live connection is only part of reliable messaging. The important question is how the app detects and recovers changes missed during a disconnection.

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.