I'm curious how E2E encryption (OTR e.g.) could be implemented with a client like this (preferably without having the keys leaked all over the place), it's the only interesting feature I miss from a quick glance.
Unfortunately, this won't improve your security. The client code comes from the server, so you need to trust it anyway. While it is possible to implement OTR or PGP in the client, the server admin could poison the implementation code and leak your private keys.
> The client code comes from the server, so you need to trust it anyway.
Sure, but we have TLS for that. E2E is still needed to cover everything else (e.g., I trust the server now, but I don't want to have plain-text logs on it in case the feds seize it).
OTR also breaks Message Archive Management (MAM) and Carbons - the two features making multi-client operation any useful, and highlighted in the article. And with MAM, there actually are plain-text logs of your conversations on the server.
The call is still open on end-to-end encryption over XMPP when multiple devices (or more than two parties) are involved.
The issues you list (message archive being plain text, key management when multiple recipients are involved, maybe even transparently) don't seem to be XMPP specific.
Is there any chat system out there with end-to-end crypto and reasonable support for multiple devices?
They aren't XMPP specific, but OTR as implemented in e.g. Pidgin goes above and beyond in making them bad – archiving is either plain text or disabled, keys cannot be changed at all (so not even manually syncing them is possible), and session handover doesn't work (there's a session management implemented, but it doesn't do anything except silently eating messages).
