Conversations: Feature Request: Backup and Restore

Created on 27 Oct 2016  路  16Comments  路  Source: iNPUTmice/Conversations

I think Conversations should offer an easy way to backup and restore chats, since MAM on the server is useless for OMEMO encrypted messages.

Settings similar to those of WhatsApp would be nice, with a manual storage location (using the Storage Access Framework for storing the backup in Google Drive/OneDrive/Owncloud etc(EDIT: And LOCAL of course)) and automatic recurring backups via JobScheduler (based on idle/charging/network condition).

Encrypting the backup should not be that hard either, possibly via OpenKeychain?

I will implement this, in case you guys want it too, but I will probably need some time.

All 16 comments

The Readme has a section on how to backup Conversations.

Yes, but adb or oandbackup are not really that intuitive, are they? My question is mostly, if I properly implemented and documented it, would you merge a PR with this?

AFAIK, you can also export the history to SD card from advanced settings...

Yes, but you can not import it, and having text files is slightly less intuitive than just having it inside the app.

Maybe it is not such a bad idea if only backed up to a file and not to a cloud...

The Storage Access Framework can also be used for local storage, it's like a general file/folder picker for local and cloud storage. So yes, local only should of course be an option.

I didn't realize I only mentioned cloud providers :D

Also, I don't like the idea of backing up to the cloud. ONLY backup to file and restore from file would be OK...

I like the idea of backing up to my cloud :D I host my own server, and I am not paranoid enough, that I would have anything against backing up encrypted copies of my messages to a my server, over an encrypted connection.

That being said, local only should of course be an option. The SAF makes no difference between the Storage Providers, you have to select where you want to save your backup.

But then you can as well upload the file from the Nextcloud app...

Where is the disadvantage of having that automated? If the backup location is the users choice, you have to call some kind of file picker anyway. The SAF is the standard way to do that, why not use it?

You could look into my code at this points

I've implemented a backup/restore function with password encrypted backups. Because I've limited my messenger to have only one account, I'm using this account password for encryption/decryption.

This gives you a whatsapp like backup functionality. The backup jub runs automatically at night, the import is inside the welcome screen.

Feel free to modify this for your needs.

Thanks, that looks kind of like what I'd like to have. There are some things I'd do differently, but like this, I don't have to start from scratch :)

Any progress on this feature? Do you need help?

For a first step, a simple import option for the existing message export would help a lot.

I won't do anything on this, I've since that switched to matrix.org/riot.im, which is just better in most ways. There are some drawbacks (push notifications and a more IRC/Slack like UI), but in general, things like encrypted multi-device history just work bette.r

It pains me to see this closed, as there is a dire need for this.

If Conversations is to be a useful communication tool, history needs to be persistent across reinstalls (and server migrations [1]).

The common advice for this is to self-host, seemingly negating the need for OMEMO, but that leaves the data vulnerable on the server and places the burden on the admin, leaving them vulnerable to legal/extra-legal coercion.

Expecting laypeople to use adb backup (which I've never managed to get to work, which has a _laughable_ reputation in the Android community for never working) and anything that requires root is preposterous. Indeed, requiring another app for backup is, from the lay user's perspective, unfriendly and unusual UX. (This may not be the case on the desktop, but certainly is on Android)

[1] One proposed solution for retaining history across servers was to do the migration on the client-side, which at a cursory glance seems to have the same requirements as the problem of retaining history across reinstalls.

Was this page helpful?
0 / 5 - 0 ratings