How it works

History backup & multi-device

Your chat history lives on your device. Two optional paths let it follow you to a new one — one device-to-device, one an encrypted server backup with a clearly-labelled tradeoff.

By default the server keeps no copy of your messages. If you want a safety net, you can turn on an encrypted backup: the server stores scrambled bytes it can never read. Or, with both devices present, you can hand your history straight from the old phone to the new one, with a short code on both screens to make sure no one’s in the middle.

Two mechanisms. Server backup (opt-in, off by default): each message is re-encrypted under history_key = HKDF(master_seed, "privex_history_v1") and uploaded to history_blobs (LOGGED, so it survives a restart) — opaque to the server. Device transfer: an ephemeral X25519 channel with a 6-digit SAS carries history directly; linked_devices lives only in local IndexedDB (the server keeps no linked-device table).

Two ways history moves
durable server backup vs. direct device transfer
Figure. Backup is the one feature that trades a little forward secrecy for recoverability — which is exactly why it’s off by default and clearly warned in the UI.

What the server learns

Server can observe

  • Backup owner, blob ids, ciphertext sizes, count, and timestamps.
  • Rendezvous events during an active device-link.

Server cannot learn

  • Message plaintext or the backup key.
  • A durable linked-device registry (it lives on the device).
  • Device labels, unless sent inside an active protocol.
The tradeoff, stated plainly While backup is on, the server holds your encrypted history. If your password and a device were both compromised, backed-up messages could be exposed. High-threat users should leave it off — the default.