There are far too many closed-source, shady messaging apps out there ran by advertising companies and/or funded by venture capital. Open standards and open-source chat applications do exist, and while I love the concept of stuff like Session and Threema, they lack the ability to evolve without the express consent of a central authority, which defeats the point: not relying on a single point of failure (say, a billionaire).
It’s rusty but by all accounts, the ActivityPub protocol is the future for social networking, and it’s becoming increasingly clear that Matrix is set to succeed IRC and XMPP.
IRC, or Internet Relay Chat, was a chat system where users would connect to a server and chat in a chatroom with other users who were currently online. If you wanted to receive messages while you were away, you had to leave your computer on– mobile was out of the question.
IRCv3 is the latest evolution of IRC, but it has the same shortcomings as the original IRC. The evolution, of course, was Jabber, now known as XMPP, but it has many of the same shortcomings. However, XMPP evolves on IRC in several ways, all laid out in its name: extensibility (the X stands for “extensible”), presence (the first P), and protocol: it’s an open standard for multiple servers to communicate!
Message History
XMPP and IRC have a common issue: most setups do not support message history at all. That means you get no history when you join a room. Your history either gains a hole or disappears entirely if you go offline, like during a system update or a loss of power. Modern messengers have fixed this by storing messages on the server. Matrix does this too, but since it is open-source and self-hostable, you do not need to trust anyone else.
There is XEP-0313 Message Archive Management which attempts to rectify the history situation but it doesn’t appear that many clients support it (we’ll come back to this, by the way).
Devices and Rooms
With IRC you risked publicly exposing your location (via IP address) to anyone in the same room. XMPP doesn’t have that issue. Instead, the protocol works by requiring users to address messages directly to a user’s device. Matrix has a mechanism to do this too but it isn’t bound to a room or any history; direct messages are facilitated in a room.
Matrix’s rooms are the foundation of its experience: rooms hold state and history. Direct messages in Jabber were always addressed to the device that would receive it, which was then responsible for sorting it into a room based on who sent it and where.
Public chats in XMPP are facilitated by XEP-0045 Multi-User Chat, also known as MUCs, which appear like users at a different domain (say, conference.jabber.org or muc.xmpp.org). These suffer the same shortcomings and it may not be immediately clear that you’re in a public room. Additionally, clients have to account for the fact that they may be receiving messages addressed to “someone else,” which may be in fact an MUC.
Clients and Servers
The necessary parts to implement a fully functional XMPP client or server simply aren’t there. It relies on TCP streams, so good luck getting it to work in a browser without a proxy of some kind.
Even without a browser, if someone wanted to write an XMPP client, they’d have to write the TCP sockets, authentication, and every XEP they want or need to have, before even writing the client-specific stuff!
It’s not viable as a hobby project, especially if you want to make a modern chat system on top of it! If all your users’ connections aren’t using your app and your server, key functionality will be spotty or unavailable outright. (Sounds like RCS.)
Matrix, on the other hand, has powerful clients like Element and gorgeous, fully-functional clients like FluffyChat.
Protocol
The X in XMPP has another meaning, too: XML. It’s a powerful, verbose data model that supports everything you’d want it to. It’s highly inefficient, however, and efforts to come up with a compact wire format for XML have never got off the ground.
Those that do exist lack libraries and implementations, so messages end up taking up a lot more bandwidth than if it used JSON like Matrix does, which has wire formats like msgpack available and is quite an effective wire format on its own.
Because Matrix uses protocols and standards like JSON and HTTPS that everything can use, you can make a Matrix client (or server) pretty much anywhere.
Federation
XMPP’s biggest strength over Matrix is how it federates with other servers of the same protocol. Matrix’s federation relies on synchronizing the entire room history across several rooms.
Instead, XMPP directly synchronizes direct messages between two devices, with the server functioning as a relay. Multi-User Chats (I believe) communicate through your own server to the server at the room’s domain. This makes XMPP’s chat faster and more reliable in the short term, which is important for chat.
The sheer size of the matrix.org homeserver makes federation difficult and slow, as that server’s messages process later and slower than they do for small servers.
This leads to severe delays and even crashes when joining a room on matrix.org, and noticeable delays when using bridges (many are hosted at t2bot.io) or when communicating with a room or user on matrix.org from outside that server.
XMPP and IRC are undebatably mature and battle-tested platforms, considering their wide use even if not directly, as XMPP was (is?) the basis for Facebook Messenger and formerly Google Hangouts. The inherent weaknesses of IRC and XMPP made them hard or undesirable to develop for, so Messenger and Hangouts could lock up their open XMPP offerings with no consequence. The open XMPP userbase is so incredibly small that the effort it would take to create or maintain a client (or server) is not worth it. XMPP’s data model and federation system are miles better than Matrix’s, but those very things make it too difficult to develop for and therefore no users to develop for.