E2EE Design Plan

Perhaps I am missing something, but I have a question about how encryption key management would work in practice. To keep things simple, let's ignore group chats and focus on two users exchanging messages. Fluxer is at least partly intended to work as a web application, so users don't necessarily have to install anything locally. But browsers can't really be relied on as a secure or permanent place to store data. Ignoring forward secrecy for the moment, this seems to create a problem: regardless of whether messages are encrypted asymmetrically or symmetrically, the necessary keys must exist somewhere so that messages can be decrypted later. With asymmetric encryption, users need access to their private keys. With symmetric encryption, they need access to the shared key. If browser storage is cleared or a device is lost, those keys would disappear unless they have been backed up somewhere. This is where I start to get confused. I know it has been suggested that when a new device is added, it can obtain the required encryption material from an existing trusted device. However, what happens if a user loses all of their devices or clears all local data? Is the expectation simply that they lose access to their messages, or do server instances retain enough information to allow recovery of the decryption keys? If server instances do retain recovery information, that information would obviously need to be encrypted before being uploaded. However, at that point it feels as though the federation is collectively storing all of the information required to recover access to the user's messages, just in a more complicated form. How is that fundamentally different from storing an encrypted zip file of the user's messages in cloud storage? Related to that, how would the master key be generated in the first place? If a user authenticates using a WebAuthn passkey or another identity provider, those mechanisms prove identity, but I don't see how they could be used to make some sort of "master key".