@Signal devs: any reason that the only two options for backup are now "locally" (flexible, but only solves for some use-cases) or "to Signal's special servers" (not flexible; might be legally impossible for many users to enable)?

Because it seems to me that, for much of Signal's (often paranoid) audience, they'd much rather use one of the backup/sync providers they've already verified trust of, than have to additionally trust some new backup service provider.

And it also seems to me that, now that Signal has the architecture to support this, it'd be pretty easy to add additional backup-sync providers.

E.g. in the codebase for the iOS Signal client, you could implement a provider that does incremental backup sync against iCloud (i.e. CloudKit for messages + iCloud Drive for attachments) — allowing the user to use their (perhaps already paid-tier) iCloud account storage.

Same with Android and Google Drive (though Google Drive doesn't have an equivalent to CloudKit, so this might be fiddly; to get good amortized write costs, you might have to e.g. buffer row-like writes in a local replication journal, and then flush them through bulk local key inserts in a locally-partial-fetch-cached set of LevelDB files, where the updated files in the set then get flushed as single whole-file overwrites to GDrive.)

---

Note that in all cases, Signal could/should still fully encrypt this data before pushing it to the provider; the backup wouldn't be expected to be "legible" to the user.

But where, with backups synced to Signal's servers, users need to trust that Signal's E2E backups encryption works perfectly to be able to believe that Signal themselves can't then have access to your backed-up data; it's much less scary to sync to literally any other provider, who won't specifically know that they've got chat data on their hands / won't have any potential to (perhaps after a bad acquisition by a PE firm) begin thinking of themselves as a "data company" who would love to have "chat data" as an asset.

Perhaps they will?

> Our future plans include letting you save a secure backup archive to the location of your choosing

I'm confused, what's stopping you from using one of the backup services you already have on the file after it's done? Since Signal would backup to a file in your phone? Couldn't you just point your service to it and automatically sync every day for example?

Note that in all cases, Signal could/should still fully encrypt this data before pushing it to the provider; the backup wouldn't be expected to be "legible" to the user.

That seems like an unhelpful limitation for a lot of people. For me - and as far as I know literally everyone I communicate with using Signal - the reason to use it is the E2EE for the messages. Once we have the messages or media on our own devices we're fine with having control over them ourselves. By all means also provide an option to create a secured archive for those who want it. But as long as the data can only be read using a specific app on a specific device then whatever you're creating isn't really a backup for a lot of practical purposes.

> Because it seems to me that, for much of Signal's (often paranoid) audience, they'd much rather use one of the backup/sync providers they've already verified trust of, than have to additionally trust some new backup service provider.

I wonder if those folks are the ones actually asking for backups. Personally I couldn’t give a shit about my messages from more than a week ago and part of that has to do with privacy. People concerned with privacy might also be more likely to have disappearing messages on which is the exact opposite of a backup. I honestly wonder who this is for exactly. From reading other threads, are people using this as their primary media backup basically?

The signal org does some sketchy things. Like for example, why won't they release all of their infra automation backend code. There's no reason this and all the other tiny bits should be kept a secret!

Did you read the article?