> So – to make sure that I understand it correctly – in that case you’d fetch a new PreKey from the recipient for each message?

Actually, it wouldn’t – thinking it through further, it would effectively generate a random message key (a single use megolm session) for each new message. This session key would then be shared over Olm, and so use the normal Double Ratchet of a combination of hash ratchet and 3DH to encrypt the keyshare. So in practice it would just fall back to being as good/bad as normal Olm/OMEMO. The problem is that each new message would require the new megolm key to be shared over the full mesh (potentially also with a 3DH handshake too), which is much heavier than Megolm’s default behaviour of relying on the session being relatively longlived, and only having to share new Megolm session details every 100 msgs.

> It would be really *really* nice to have bridgeable e2ee using MLS, although that’ll probably be hard due to different message formatting inside the payload.

The way to do this might be to tunnel the MLS payloads inside the XMPP or Matrix (or SMTP etc) framing – more like OTR. It means that all the metadata would be unencrypted of course, but at least the plaintext payloads could get through intact. In practice this would be Hard with MLS though, which requires a centralised application server to keep track of which devices are currently in the conversation, which is of course bad news for decentralised or bridged conversations.