Exactly, and what is described is not e2ee at all.
> End-to-end encryption (E2EE) is a system of communication where only the communicating users can read the messages. [..] End-to-end encryption is intended to prevent data being read or secretly modified, other than by the true sender and recipient(s). The messages are encrypted by the sender but the third party does not have a means to decrypt them, and stores them encrypted. The recipients retrieve the encrypted data and decrypt it themselves.
Which requirement do you believe is failed by such a system?
This is reasonable, but it's not describing any weakness of encrypted backups. It merely points out that "E2E" isn't the right term to use when there are not two E[nds], but rather only one client and their files.
However, our conversation was about storing chat history. There are two parties to the conversation in that case.
The key property of E2E is that only those parties can read those messages, and nobody else, in particular not the agents running the server. That property is not affected by the existence of backups, as long as those backups are client-side encrypted, because third parties cannot access them.
Therefore, it is possible to have both cloud-stored chat histories and true E2EE. QED.
That's a different, further goalpost - we were talking about E2E encryption, weren't we? I.e. the server should not need to decrypt your data to provide it.
Obviously if you want to be able to recover your history from storage with just a password, that does mean the password is the only protection over that history, tautology. So storing your history should be optional, if you're seriously worried about brute-force attacks on data encrypted at rest (indeed, even WhatsApp makes it optional to have a backup of your data!).
In any case, that doesn't compromise future secrecy - i.e. gaining access to the history still doesn't give you access to future messages.
> Also, downloading blob to client side and decoding it locally can hardly be done fast enough for user to consider it 'instantly'.
Off the top of my head, it doesn't have to be a single blob for all your data. You could split the blob into tiny equal-sized chunks, and then have a separate encrypted index file which stores the information of which chunks hold which chats (plus just enough metadata, e.g. chat titles and last messages, to display your homepage properly). The index file is the only one downloaded on first login, then when you want to open a chat it moves the corresponding chunks to the top of the download list.