This keeps popping up. I’m sure there’s a better article than this one. There’s a few things that I happen to value, even if I do use and like IRC as well.
So: what are some of the things XMPP can do that IRC can’t?
Widespread across all clients/servers:
- Per-person presence.
- Multi-line messages.
- Rich-text messages. 1 XEP-0071: XHTML-IM
- Avatars. XEP-0084: User Avatar, XEP-0153: vCard-based Avatars and more.
- Offline messages.
- Multiple concurrent logins with same credentials. Gets superpowers with XEP-0280: Message Carbons2 and XEP-0313: Message Archive Management.
- Cross-“domain”, nearly-trustless s2s federation.
Easy to set up server-side; sufficiently widely supported on mobile and desktop:
- Rich status updates. Particularly with extensions based on XEP-0163: Personal Eventing Protocol such as XEP-0118: User Tune or XEP-0080: User Location.
- Personal chat history.3 XEP-0313: Message Archive Management
- Chatroom history. 4 XEP-0313: Message Archive Management
- Chatroom backlog. Built into the multi-user chat specification.
- Per-chatroom nickname.
- Integrated HTTP file upload file sharing. Peer to peer with XEP-0234: Jingle File Transfer similar to IRC’s DCC, or, for a much better, offline-compatible and multi-client-friendly experience, XEP-0363: HTTP File Upload.
- Session resumption. XEP-0198: Stream Management.
- Standardized HTTP-based transports to support web-based clients. draft-ietf-xmpp-websocket-00, XEP-0124: BOSH, XEP-0206: XMPP over BOSH.
Rarely well supported on mobile, desktop or web:
- Microblogging. XEP-0277
- Integrated VVoIP. XEP-0166: Jingle-based XEP-0167: Jingle RTP Sessions.
Now for a short use case description for something that XMPP allows me, and IRC doesn’t allow trivially…
As a side effect of some design choices in how per-protocol “gateways” operate, it’s trivial for a per-protocol “gateway” to also act as an equivalent of an IRC bouncer. For instance, I am logged into XMPP from multiple devices, and I have configured the gateway 5 to persist connection into some IRC channels. This means that I am effectively logged into IRC from multiple locations, and even if I lose the TCP connection from one of the clients (such as my phone), I won’t be kicked out. Plus Message Archive Management will let me obtain the backlog for the chatroom. Session resumption also means that, as far as the IRC component is aware, I will not have lost the connection anyway in most of the cases.
I am simply “available” in chatrooms, and particularly in IRC. And if I am not, I can catch up without referring to an external chatroom log service. Nor do I have to have a persistently-running IRC client in a tmux session, or an IRC bouncer; the IRC component connected to my self-hosted server is acting as a bouncer. If I were using a bouncer instead of a persistent client (enabling multiple connections and enabling logging), I would still easily lose some of the IRC history, as it would be trivial for me to see only the immediate backlog of ~20 messages.
Are there other protocols offering openness, self-hosting, federation, presence, extensibility (which allows for a bunch of features quoted above)? Probably. None of them attracted me6. Despite low use of XMPP, other such protocols are used even less.
Can IRC be extended? Sure. How long before clients such as Irsii, Hexchat and mIRC are updated? If they are not, how long before they are pried from people’s hands? How long would it take for various IRC daemons to be updated? How long before daemon deployments are updated to support multiline messages?
Finally, if I am mistaken, and IRC has a capability I don’t know about or an upcoming protocol revision is supposed to provide a capability, leave a comment.
The following were brought up on Twitter: