Backup & second device
What is backed up, and where
Section titled “What is backed up, and where”The backup is a single encrypted blob in the private app folder of your Google account. TalX can see nothing there but its own folder – none of your other files. Every backup overwrites the previous one.
It contains contacts, chats, groups and – since backup version 3 – the attachment files themselves. Before that only the metadata was included, so after restoring on a new device the attachments would have been empty.
Encryption
Section titled “Encryption”| Step | Method |
|---|---|
| Key from the passphrase | Argon2id, 64 MB memory, 4 passes – the parameters are stored in the file header |
| Encryption | AES-256-GCM, fresh salt and fresh nonce per backup |
| Before encrypting | gzip-packed |
| Second factor when restoring | TOTP from an authenticator app or biometrics – mandatory |
Argon2id is memory-hard: an attacker guessing at the passphrase needs 64 MB of memory per attempt. That makes GPU and ASIC attacks expensive, where a pure compute function would present no obstacle at all.
Older backups remain readable – including those with the earlier parameters and the very old ones using the weaker method. The file header says what to compute with.
Selectable backup contents
Section titled “Selectable backup contents”Two switches, both on by default: photos & videos and voice & video messages. Switched-off types are excluded entirely – neither chat entry nor file – and stay only on the device. The choice applies from the next backup onwards, automatic ones included.
Automatic backup
Section titled “Automatic backup”Selectable: off (default), daily, weekly, monthly. The schedule survives app and device restarts and only runs when an internet connection exists.
It requires one manual backup first. During that, the passphrase and TOTP secret are stored on the device, keystore-encrypted, so the backup can run without input.
The blob in the cloud stays encrypted regardless, and restoring still demands both factors – on this very device too. Without stored credentials the schedule silently skips rather than producing retry storms.
The TOTP secret is reused for every further backup. Previously each manual run generated a new one and thereby silently invalidated the existing authenticator entry.
Memory behaviour
Section titled “Memory behaviour”Backup and restore used to be memory hogs: a backup raised usage by 338 MB, and restoring stacked intermediate stages. Today the content is assembled in a streamed fashion and the restore is applied as a whole – either completely or not at all. An abort halfway through leaves no half data set behind.
A second device of your own
Section titled “A second device of your own”Under Profile → Link another device. The existing device shows a code, the new one scans it; then J-PAKE runs, and only afterwards does the identity travel along with the state, encrypted with the negotiated key.
The state is applied all or nothing. An abort in the middle of the transfer leaves no half state in which some contacts are there and the rest are not.
Limits: both devices have to be Android, and the linking process necessarily exports the private identity key. So only ever tell the code to your own device.