> That requires re-encoding all transmitted data with a single password and is potentially vulnerable to brute-force attacks. Encryption used in signal, etc relies on double ratchet mechanism that continuously regenerates keys as they move along. This way one compromised key will not allow to decode the rest of the messages.
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.