End-to-end encryption does not require a messenger to avoid central storage. A server can store encrypted messages for synchronization without holding the secrets needed to read their content.
The difficult part of multi-device messaging is deciding which devices are authorized, which keys they receive and whether they can access older history. Those decisions matter more than whether the system uses a database.
Four separate operations often called “sync”
| Operation | What it needs to accomplish |
|---|---|
| Delivering new messages | Get protected content to currently authorized devices |
| Linking a new device | Establish that the account owner approves the new endpoint |
| Transferring history | Give the new device access to selected past content and its decryption material |
| Recovering identity | Restore or replace identity keys without necessarily restoring message history |
A product can support one operation without supporting all four. Signing in successfully does not prove that old chat history is recoverable.
How encrypted delivery can support several devices
One approach maintains separate sessions for each device. Signal's Sesame specification describes session management in an asynchronous, multi-device setting, including devices being added or removed and messages arriving out of order.
That is a documented design example, not a universal requirement. Other systems may encrypt content once and distribute protected content keys, use group mechanisms or combine approaches. “E2EE requires a full duplicate payload per device” is too broad.
Whichever design is chosen, adding a decryption-capable device adds an endpoint that needs protection. A neglected laptop can expose plaintext it receives even if the server never sees that plaintext.
Stored ciphertext still has privacy and retention implications
Encrypted storage is not the same as no storage. Providers may retain delivery information, device records, timestamps, membership or encrypted message history. The details vary and should be stated explicitly.
Livara's security documentation says its relay stores ciphertext and operational data for synchronization and reconnect recovery. It describes routing, membership, timestamps, delivery state and other records. This should not be characterized as an undocumented transient queue that necessarily disappears as soon as every device receives a message.
Content confidentiality and metadata retention therefore need separate questions. Ask what is retained, for how long, and what deletion or account removal changes; do not invent a retention period when none has been verified.
What Livara's v7 recovery actually restores
Livara describes v7 as an encrypted identity backup, sealed before upload under a random 256-bit recovery key. The documented payload includes identity key material, and the format authenticates its suite, identity epoch and generation.
The same page states that it restores identity, not chat history. A recovery phrase should therefore not be presented as a guarantee that a new device can display every old conversation.
Before replacing or erasing a device, verify the current history-transfer and backup options actually available to you. Keep any recovery material private. Do not send a recovery phrase to a support account or paste it into an unverified website.
Forward secrecy does not erase an authorized device's inbox
A ratchet can limit what a later key compromise reveals about earlier encrypted traffic when its assumptions hold and obsolete secrets are deleted. It cannot conceal plaintext that an endpoint already stored, or stop malware that remains active from reading new messages.
Likewise, post-compromise security requires an appropriate fresh update after the attacker loses access. It is not a promise that any old tablet becomes harmless whenever a message counter advances.
A safer device-change checklist
- Inventory your linked devices before adding another one.
- Use the application's documented linking and verification flow, not a QR code sent by a stranger.
- Check what history the new device receives with a harmless test conversation.
- Confirm the recovery material and any separate history backup before erasing the old device.
- Revoke devices you no longer control and check whether peers receive an identity-change notice.
- Review local downloads, notifications and operating-system backups on each endpoint.
The Livara threat model explicitly includes endpoint and recipient limitations. Those limitations remain relevant on every screen. A useful multi-device promise explains device authorization, stored data and recovery scope separately.
