Backup and recovery strategy

[gmaclennan]

I've been thinking through what data is potentially lost when Mapeo is uninstalled from a phone, or a device is lost, and whether it is recoverable by re-installing and re-syncing. Some scattered thoughts to keep somewhere for later:

If a user uninstalls Mapeo from a phone, then all of Mapeo's data on a device is deleted. On Android there is no way to store data in a secure way that is not accessible to other Apps, but persist it across re-installs of the app: https://developer.android.com/training/data-storage. The recommended solution is to use Android backup, which requires cloud access, trusting Google, and the user having a Google account, which we don't want to do.

This is not necessarily a problem - as long as the device has synced with another, installing Mapeo again and syncing should recover all the data. However it could become a problem if we start doing any kind of user/group encryption or access - some data could be left encrypted an unrecoverable.

The information that is lost, and not recovered by a sync, is the private key for writing to the hypercore. As a result Mapeo will create a new hypercore on re-install, and the original hypercore from the device will be left in a "read-only" state. This is probably not an issue as long as no user-specific encryption is being done. Many re-installs would just lead to lots of "orphaned" hypercores.

It could be possible to have a recovery mechanism for the hypercore private key - we could generate it from a 256-bit random number which we could convert to a 24-word mnemonic, which the user could write down. However, this introduces the risk that the user could recover their private key on a new device without actually deleting the first, which could result in writes to the same hypercore by two different devices. This would result in bad things happening (@noffle is this correct?). One workaround would be to generate the hypercore private key from a combination of a random key and the ANDROID_ID, or even just directly hash it from the ANDROID_ID, which would mean that you could only recover the hypercore private key on the same device. However, it might not be necessary to ever recover a hypercore private key - simply creating a new one and leaving the other read-only might be fine in all situations.

Encryption at a project level will allow any device that has access to the project to re-invite others, however, if all devices are lost and only a "blind-peer" backup exists, then the data would be unrecoverable. A paper-key mnemonic would be a good solution for this - a user could use this to recover a project key and regain access to data backed up on a blind-peer.

Encryption at a user/group level will require some kind of backup for a user key, or access to some data may be lost for ever (e.g. data encrypted for a specific user whose key is lost). We probably want this user "identity" to be recoverable and movable between devices, which means that it should probably not use the same key as the hypercore key for user-level encryption, to avoid the risk of duplicate hypercores on different devices.

[hackergrrl]

However, this introduces the risk that the user could recover their private key on a new device without actually deleting the first, which could result in writes to the same hypercore by two different devices. This would result in bad things happening (@noffle is this correct?).

Yes. It might be easier to just have the person start a new feed. Feeds don't carry much identity, so starting a new one should be very low-cost.