Request using IPFS
I'm requesting the feature to use IPFS as a method of back up & sync our contacts and chat sessions/logs between devices & instances.
The main issue with account backups is forward secrecy. Briar's transport protocol uses key rotation for forward secrecy. The protocol is obfuscated so it's indistinguishable from random, and it only uses symmetric crypto, which should make it post-quantum forward secret (meaning that traffic captured now can't be decrypted in the future with a quantum computer).
If you make a backup of your encryption keys then they're no longer destroyed by key rotation, so you lose forward secrecy. The solution is to back up authentication keys rather than encryption keys, then establish fresh encryption keys after restoring the backup. But establishing fresh encryption keys involves a plaintext handshake and asymmetric crypto, so you lose obfuscation and post-quantum forward secrecy.
I'm fairly confident that djb and friends will eventually come up with a post-quantum forward secret key agreement mechanism that's indistinguishable from random, so I'm basically sitting on this problem until that happens. :-)
The main issue with multi-device support is handling the UX when the user moves between devices. For example, Alice invites Bob to a forum. Bob receives the invitation on his phone and accepts it. Later, Bob's phone runs out of battery and he signs into Briar on his laptop. Various weird things can happen at this stage, which wouldn't happen in a client-server app:
- If Alice is offline, her invitation doesn't show up on Bob's laptop, and neither does the forum. This is understandable for technical people like us, whose mental model says something like, "The invitation is a piece of data that's copied between devices. It exists on Alice's phone and Bob's phone, but they're both offline so it can't be copied to Bob's laptop right now. Nothing is broken, it will show up eventually." But if you don't have an elaborate mental model of how the app works, this behaviour just looks broken.
- If Alice is online, her invitation shows up on Bob's laptop. Bob's laptop thinks this is a new invitation that he can respond to. That's weird for Bob, because he's already responded on his phone. Maybe this is a different invitation? If he was using a client-server app, his laptop would know which messages he'd read and responded to.
- If Bob responds to the "new" invitation, it's weird for Alice - she'll get two responses to the same invitation (possibly different responses, if Bob thinks the "new" invitation is redundant). She can't even reliably tell which one Bob sent first, because clocks are inaccurate and messages may not be received in the order they were sent.
Storing data in IPFS (or any other online storage) would help a lot with these UX issues, if Bob's phone can upload all its changes before it shuts down, and Bob's laptop can quickly discover whether there are changes to download when it starts up. (It doesn't need to download all the changes instantly - it just needs to know whether it's up to date.) But if Bob uses either of his devices while it's offline, or the laptop takes a while to discover the changes uploaded by the phone, then the UX weirdness reappears.
UX problems like this are starting to get some mainstream attention thanks to the trend for "offline first" web apps, so I hope we'll start to see some design patterns that we can use to manage the weirdness. Again, I'm happy to sit on this problem for a while and see what solutions other people come up with, since we have plenty to work on in the short and medium term. :-)
Just to reiterate: I agree that these are important problems, and that IPFS might be useful in solving them. But they're both multi-faceted problems, and where to store the data is only one facet.