that's not true for most clients, though (AFAICT, only riot works with itself).
I might even say that the situation is better/more sustainable in XMPP where more diverse implementations of the encryption protocol are available, with all mainstream clients supporting it: https://omemo.top/
Riot doesn't exist anymore. It's been Element for a while now
How so?
We have OMEMO now, key exchange is paranoia-level secure.
Currently, verification seems to work on a session basis and not just per user, which makes it very tedious to have everything verified e.g. a group chat. If it is not almost impossible given peoples sessions change with time.
Add a new session in the browser -> meet every contact to verify their sessions with your new browser session? Doesn't seem very practical, and reminds me of the old times in [matrix].
This opens room for MITM attacks
Also you don't have to meet with everyone to verify new keys, you can just use a known good key for that. Essentially, if you want 100% security by comparing keys in a meetup, you can do that once and then use that known good channel to verify every new key.
In reality, cryptonerds will be happy to verify every single new key, everyone else will never bother to even open the key signature view and I will get a confused call should it be opened by accident.
> This opens room for MITM attacks
Yes, in your constructed strawman world xmpp is prone to MITM. In reality it's equally or less prone than its competitors.
The server could keep an append-only log of published keys, and then you could require m-of-n signatures of other published devices/keys to register a new one, in which case no further verification would be verifiable if you already trusted your peer's other keys. In addition, you could introduce peer keys in private rooms automatically and/or employ some form zero-knowledge proofs in public venues.
XEP-0450 Automated Trust Management is a first exploration in this direction. There a lot to explore and I only wished skilled cryptographers spent more time researching these issues on federated networks instead of advancing yet-another-centralized-messenger-of-the-month.
> Also you don't have to meet with everyone to verify new keys, you can just use a known good key for that.
Also known as a keyserver. But you could also employ cryptographic challenges like OTR does, like a shared password to establish the session.