Livara 0.2 · adversary by adversary
A threat model that only lists strengths is a brochure. This one names the relevant adversaries, says exactly what each gets, and then prints the list of things Livara does not claim.
01 · Six people who might want your messages
Some get more than you might hope. They are listed anyway, in the same type size as the rest.
Can see that you connect to Livara and observe traffic timing and volume. TLS and message encryption protect content within their stated boundaries; they do not make your connection anonymous.
Network metadata remains visibleDuring protected message delivery, the service receives ciphertext and handles routing metadata. Public channels are readable. This description does not cover separate AI processing or a compromised device or client.
Ciphertext and routing metadataCannot restore your encryption keys — the encrypted key backup requires your recovery phrase.
Recovery phrase requiredCan access content available on the unlocked device. A passcode or biometrics helps protect a locked device; message encryption does not prevent access once the device is unlocked.
Unlocked-device access is not preventedLVR1 combines ML-KEM-768 and P-256 in a design intended to resist quantum decryption attacks. This is a design goal, not an independent audit or protection against compromised devices and clients.
Designed for post-quantum resistanceA checksum detects a mismatch against a trusted digest. If an attacker can replace both the APK and the displayed digest, matching hashes alone cannot establish authenticity.
A trusted digest is required02 · The coverage line
This table describes message delivery. For separate AI processing, check the controls and privacy policy for the client you use. The security page explains the encryption and compatibility boundaries in more detail.
| What it is | Direct 1:1 | Compatible private groups | Channels |
|---|---|---|---|
| Message text | Sealed on your device | End-to-end sealed (LGS1) | Public broadcast channels |
| Text edits | Sealed on your device | End-to-end sealed (LGS1) | Public broadcast channels |
| Photos, video, files, captions | Encrypted before upload | Encrypted before upload | Public broadcast channels |
| Who you talked to | Routing metadata only | Routing metadata only | Public broadcast channels |
| When you talked | Delivery timestamps only | Delivery timestamps only | Public broadcast channels |
| Your password | Never leaves your device | Never leaves your device | Never leaves your device |
| Your private keys | Never uploaded unencrypted | Never uploaded unencrypted | Never uploaded unencrypted |
03 · Architecture and boundaries
The exact edge of how the end-to-end encryption, key management and privacy model work — the same facts, without the adjectives.
Direct messages and compatible private-group content are encrypted end-to-end on user devices. The delivery service stores ciphertext and operational metadata. Older incompatible groups remain visibly outside E2EE; separate AI processing is described in the privacy policy.
Broadcast channels are designed for public distribution and are readable by design. Private groups and direct chats are strictly separated from public channels.
Group calls use end-to-end encryption for audio, video and screen sharing. Optional server recording switches to transport encryption while a visible REC indicator is on.
Cryptographic keys reside securely on your device. A passcode or biometrics helps protect a locked device; malware, an unlocked device, or a recipient can still expose plaintext.
Your identity backup is encrypted on your device before upload. Restoring it requires your recovery phrase. The backup restores identity, not chat history or ratchet sessions.
The Proof Lab lets you compute an APK hash and try local examples of key agreement, encryption and tamper rejection. It does not run or independently audit the complete LVR1 or LGS1 protocols.
Questions
Direct messages and compatible private-group content are encrypted end-to-end on user devices. The delivery service stores ciphertext and operational metadata. Older incompatible groups remain visibly outside E2EE; separate AI processing is described in the privacy policy.
Broadcast channels are designed for public distribution and are readable by design. Private groups and direct chats are strictly separated from public channels.
Group calls use end-to-end encryption for audio, video and screen sharing. Optional server recording switches to transport encryption while a visible REC indicator is on.
Cryptographic keys reside securely on your device. A passcode or biometrics helps protect a locked device; malware, an unlocked device, or a recipient can still expose plaintext.
Your identity backup is encrypted on your device before upload. Restoring it requires your recovery phrase. The backup restores identity, not chat history or ratchet sessions.
The Proof Lab demonstrates an APK hash check and selected cryptographic components. It is not a complete application or protocol audit. The custom protocols have not undergone an independent security audit.
Do not take this page on faith either
Hash the APK, run the handshake, corrupt a byte and watch the authentication reject it. All of it offline, in your own browser, before you install anything.
