The whole issue with XMPP is that yes, in theory you could do e2ee accross multiple servers and devices but only if all the servers support the right extensions and the clients support them properly.
This is not a problem with XMPP, but any open ecosystem. There's no way to force third-party developers to implement stuff, especially when they are open-source volunteers working in their free time.
XMPP does have this feature parity issue, though there is a good selection of modern active XMPP clients across platforms with important features like end-to-end encryption and calls. But you're right - there's no way to stop people trying to use clients like Pidgin, which have been essentially frozen in time for a decade.
Matrix is newer, so has less diversity, and lots of resources to put into the Element clients. However there certainly is exactly the same problem growing in the Matrix ecosystem too - there are many features supported by Element that are not (yet?) implemented in popular alternative clients such as FluffyChat.
The best you can do is ensure that when two clients communicate without the same set of features, that you degrade gracefully and securely (e.g. the worst case I can imagine would be E2EE that silently becomes unencrypted if not supported by your contact - thankfully that's not how it's done) to the best common feature set between the two.
In Matrix you "can't" select between multiple extensions.
The protocol defines one way of doing things, so either you have that feature or you don't have it.
There is no choice between two ways of doing things.
Yes I know, since Matrix there is now an extension that defines a selection of extensions to try to overcome this
That just means that some servers may have it built in (all of the maintained ones that I'm aware of do), but that you can still claim compliance if you support a general plugin system and delegate your multi-user chat implementation to an external plugin (because of the way it's designed it doesn't necessarily have to live on the same server or in process with the XMPP server). That seems like a fine implementation detail to mention and not a problem…
You can say that..but it was a problem. It was not trivial, despite what the spec says or what is claimed now. If it was, more people would have used it.
The whole issue with XMPP is that users are brainwashed to demand e2ee even without fully understanding what it means and what unavoidable downsides in UX true e2ee brings.
Most users would have the same level of security as with e2ee by simply running their own server. E2ee mostly helps against service owner you don't trust, so just be your own service owner and have nicely syncing history and server side search.
For single-user XMPP servers, this is true, but on the other hand, not everyone is able to run their own server.
I will say, that even though I kind of like the architecture of XMPP better, the Matrix people have put in tremendous amounts of work to overcome the UX problems with e2ee, in particular the multidevice problem (where I have a laptop and a phone logged into the same account and try to participate in the same encrypted conversation from both).
I totally agree, though I run my own Matrix server and still find value in e2ee because I don't really trust AWS (or maybe my ability to secure AWS).
I suppose I could run the service on a machine in my house, but that's not going to be good for uptime, the NAT screws things up, etc. Plus, even that could be hacked if I fuck something up.
If you run a legal operation, you don't have to worry about hosting company admins logging into your database. That can be done only on police inquiry.
On photos/documents, you are in a tiniest of minorities: ~99% of all smartphone users store photos in unencrypted cloud services like Google Photos and use Google Docs and MS Office 365.
(But but chats are surely the holy cow and must be encrypted - strictly demand those same users, paradoxically)
And no modern server stores passwords in plain text, and keys are not stored on servers at all.
> ...but only if all the servers support the right extensions...
That is only for OMEMO (OpenPGP and OTR require nothing of the server) and you can easily check a potential server for the things that OMEMO depends on by doing a normal server compliance check here:
XMPP does have this feature parity issue, though there is a good selection of modern active XMPP clients across platforms with important features like end-to-end encryption and calls. But you're right - there's no way to stop people trying to use clients like Pidgin, which have been essentially frozen in time for a decade.
Matrix is newer, so has less diversity, and lots of resources to put into the Element clients. However there certainly is exactly the same problem growing in the Matrix ecosystem too - there are many features supported by Element that are not (yet?) implemented in popular alternative clients such as FluffyChat.
The best you can do is ensure that when two clients communicate without the same set of features, that you degrade gracefully and securely (e.g. the worst case I can imagine would be E2EE that silently becomes unencrypted if not supported by your contact - thankfully that's not how it's done) to the best common feature set between the two.