Others are noting clients & servers matter. This isn’t a downside—it’s just that the protocol is flexible & extensible for many types of messaging beyond human2human private conversations, which explains why encryption isn’t a requirement for the clients. With that said any modern client targeting said H2H interaction will have basic forms of encryption like PGP, OTR, & OMEMO which all do the job of E2EE. OMEMO is based on the same ideas that Signal, WhatsApp, Matrix, & so on use so that part is all the same.
A unique feature for XMPP in this space tho is how low-spec & resource-unintensive the servers/clients are—you aren’t chewing up a ton of CPU or RAM, there is no eventual consistency to balloon storage (MAM is enough), clients don’t drain your battery or take literal minutes to sync with servers. Since it is low-cost, it is feasible to self-host XMPP from a residential server (at home on some old hardware for instance) or add it to a multipurpose machine where it doesn’t get in the way of other processes/storage. Some of the other service often mentioned here either you can’t self-host or are quite expensive to run (often by design) which limits the accessibility causing centralization as well as requiring trust in that server you don’t own.
Matrix servers chew up an order of magnitude more CPU/RAM which limits the places you can deploy it. The eventual consistency model makes storage balloon as every message, attachment, metadata must be copied to all nodes in a conversation which is resilient, but wasteful in duplicated content in practices which has historically caused many medium & larger servers to shut down due to the explosive just of storage (similar issues with Mastodon). That same model is why it takes on the order of minutes to just join a room or come back to a client that hasn’t been opened recently. Element X & new servers have to work so damn hard to work around asynchronously than fundamental decision to attempt to hide it from the sluggish UX but behind the scenes still too expensive. & since it is expensive to run in many vectors this causes folks to then move to the biggest servers that can handle the load which means the Matrix network is in actuality a small number of massive servers (most of which managed by Matrix.org) & a small number of tiny hobbyists running nodes of <10 users is practice. With so many users on Matrix.org-controlled instances (& again with eventual consistency), almost all data gets synced to their nodes make subpoenas a breeze.
A healthier network would have many fewer massive centralized nodes, medium-sized nodes, & the resource requirements would be low enough that more folks would be encouraged more often to run their own nodes they control so they aren’t required to trust an unknown serves operator. Meaning “just making an account on any public server” isn’t a great mode of operation for privacy—especially as with Matrix joining a medium-sized server will put them under a lot of strain causing them to throw in the tower & joining the few massive servers further exacerbating the centralization issue.
Copying the UX of Slack/Telegram/Discord in a decentralized manner is a fool’s errand. Keeping the chat history for eternity is already a questionable call over using forums, but trying to distribute that out like a blockchain is so wasteful.
https://lukesmith.xyz/articles/matrix-vs-xmpp/ https://www.freie-messenger.de/en/systemvergleich/xmpp-matrix/ https://www.process-one.net/blog/matrix-and-xmpp-thoughts-on-improving-messaging-protocols-part-1/