Some context: For the past month I have been using Delta Chat extensively while traveling abroad with my family. This is our first experience with Delta Chat and I am very impressed. We are using it across multiple device OSs (Android, iOS iPad and iPhone, Linux) and highly dynamic networks. We have used it to call each other, video chat, share live locations to rendezvous, and share photos and important files during our activities. As someone who has been experimenting with and contributing to FOSS decentralized messaging platforms for 15+ years, this praise comes from significant experience with this ecosystem. I’ll lavish more praise in another post 
.
Two fundamental challenges for serverless apps like Delta Chat are seamless transition between user devices and disaster recovery. Consider the following scenario:
Alice creates a Delta Chat account on her phone using a single random relay after being invited by her nerdy partner. She doesn’t change any defaults settings or think about anything but getting through the steps so she can send and receive messages. After two months she has added her tablet as a second device and has several important group chats and direct messages with friends and family. She relies on it daily and expects her data to be available. She even installed Delta Chat on her kid’s iPad so they can chit chat when she’s at work without worrying about privacy policies and terms of service.
She has never considered actively enabling backups because all of the rest of her apps are automatically backed up to iCloud (or whatever Apple/Google/EvilCorp does; she does not particularly care). Even if she did think about making a manual backup of her Delta Chat data, a file export would be an alien concept because she does not think in terms of “files” on her mobile devices: She has “apps”, and any data she has lives “in” those apps, transferrable only via a Share button (if one exists and then only to the apps listed).
One day, she loses both devices when her luggage is lost irrevocably by the airlines. After paying lots of money to replace her phone, she logs in with her Apple ID and all her apps are magically restored along with their data. Except for Delta Chat, which doesn’t even remember who she is. She is distraught when she discovers that data is as lost as her luggage. She never uses Delta Chat again.
My idea is to add an optional service to relays that stores backups of messages for users who activate the feature. The messages are already e2ee, so the only trust involved would be in the integrity and availability of the backups when needed. In addition to the messages, the user identity itself would be part of the backup, recoverable by knowing the server address and the key generated upon initialization known only to the user. Backup depth, storage limits, and other configuration options would need to be designed.
This could be an opportunity to ethically monetize the relay network and grow the ecosystem, because obviously backups require storage and that costs money. There would be a financial incentive for people to run relays that host backups, and the competition would keep prices low, especially since there is no vendor lock-in effect to distort the market. Supporting S3 natively as the default storage backend would be best to make it as turn-key to deploy and as cheap to operate as possible. Restic could be considered as the core component of the backup engine.
Another possibility would be to implement peer-based backups, where a user requests that certain contacts serve as backup hosts with the option (even encouragement) to reciprocate. Messages would then be stored on their selected contact’s devices, encrypted of course so that again, the trust is only in future availability. This scheme is technically more challenging to implement because the information needed to restore data must be included in the decryption key that the user would be required to store in their password manager; there would be no server to remember for them. Clearly this is more fragile in terms of recovery due to potentially intermittent connectivity to the storage peers, but possibly more robust in terms of actual storage, because the data could be sharded and stored using an erasure encoding across the target contact devices. Lots of fun technical details to puzzle over here.
Mostly I’m having fun brainstorming at the moment, and I am interested to hear the perspective of Delta Chat experts and learn more about the application in the process.