Your keyserver is always online and can handle backups in the background. Crucially, your keyserver also encrypts all of your backups before uploading them to the cloud.
We want to guarantee to users that they can always recover their account as long as they remember their underlying secret. The underlying secret is either an Ethereum wallet or a password associated with a free username.
For this system to work, it's critical that the user has a way to both prove that they have the secret, as well as a way to use the secret to encrypt/decrypt the backup key.
For an Ethereum wallet, we can use a "Message Signing Request" (either ERC191 or ERC712) to prove that the user has the secret. We're still looking into the encryption/decryption story, and it's critical that whatever solution we go for there is supported in mainstream wallets. If there's no good wallet solution, we might be able to use something like IBAKE.
For a username/password, we can use a PAKE to prove that the user has the secret, and a KDF to convert the password into a key that can be used for encryption/decryption.
Your backup is encrypted with a backup key that is kept on your keyserver. That backup key is then encrypted with your secret, and the encrypted backup key is then uploaded to the backup server along with your backups, which are encrypted with that backup key.
Every change to the data on your keyserver is recorded as a transaction. That transaction is then encrypted with your backup key and sent to the backup server as the transaction occurs. Every once in a while the keyserver will run a "compact" operation and re-upload the full encrypted keyserver state, after which the the transaction backup log starts anew.
Recovery is the process you go through if you need to recover your keyserver data, but it's also an easy way to switch keyservers too. You start by authing with our servers, which will return to you the encrypted backup key once they've confirmed your secret (and potentially a second factor). Note that Comm keyservers never transfer the plaintext secret to our backup service, and thus the backup service can never decrypt the backup key, which would be necessary to decrypt the backups themselves.
Once the backup key is decrypted, the keyserver proves to the backup service that it has the backup key, and the backup service then transmits the full encrypted backup (including the most recent compact as way as the transaction log since that compact) to the keyserver.
The backup service can also be thought of as cold storage for your data. Your keyserver device may have limited storage, but with the backup service it only needs to keep a limited subset on its hard drive. Eventually we'll have ways to treat your keyserver storage as a cache, with the backup service tracking out-of-cache objects individually.
If you punt on forward secrecy and just use a simple shared secret to encrypt all messages in a thread, you can have a server in the cloud keep track of the same ciphertext for all members of the thread. This makes it possible for anybody to download history on-demand from a server, but the tradeoff is rarely made. Ultimately we're looking to build a platform that we can argue is more secure than Signal so it's not something we want to compromise on.