Home

Things XMPP can do that IRC can't

8 years ago 27 Feb 18 15:26 +0000 by

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:

  1. Per-person presence.
  2. Multi-line messages.
  3. Rich-text messages. 1 XEP-0071: XHTML-IM
  4. Avatars. XEP-0084: User Avatar, XEP-0153: vCard-based Avatars and more.
  5. Offline messages.
  6. Multiple concurrent logins with same credentials. Gets superpowers with XEP-0280: Message Carbons2 and XEP-0313: Message Archive Management.
  7. Cross-“domain”, nearly-trustless s2s federation.

Easy to set up server-side; sufficiently widely supported on mobile and desktop:

  1. Rich status updates. Particularly with extensions based on XEP-0163: Personal Eventing Protocol such as XEP-0118: User Tune or XEP-0080: User Location.
  2. Personal chat history.3 XEP-0313: Message Archive Management
  3. Chatroom history. 4 XEP-0313: Message Archive Management
  4. Chatroom backlog. Built into the multi-user chat specification.
  5. Per-chatroom nickname.
  6. 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.
  7. Session resumption. XEP-0198: Stream Management.
  8. 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:

  1. Microblogging. XEP-0277
  2. Integrated VVoIP. XEP-0166: Jingle-based XEP-0167: Jingle RTP Sessions.

A story

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.

Closing remarks

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.

Updates

2018-02-27 16:30

The following were brought up on Twitter:

  1. Yes, technically, IRC has some support for message formatting in form of color, weight and slant control characters.
  2. This enables realtime replication of messages aimed at one client onto other clients.
  3. Stored server-side and retrievable incrementally.
  4. Useful for catching up on offline discussions.
  5. Despite occasional quirks, I highly recommend Biboumi as a featureful, yet sane and no-frills, IRC gateway component.
  6. I had a very lengthy text here. tl;dr: XML’s namespacing eases extensibility and makes me tolerate XML’s verbosity. And HTTP-based protocols are good and acceptable, but also a sign of a modern-day “I have a hammer, every problem looks like a nail” attitude.
  7. Apparently, there’s a way to use OTR with IRC using Pidgin.-
  8. E2E interferes with my interest in keeping various devices in sync using MAM, without having to keep their encryption keys in sync. Instead I hope the system hosting my XMPP server is secure enough, and rarely use E2E. I perhaps shouldn’t, but I do.
  9. Mobile push is important on platforms that don’t allow for long-running applications maintaining background connections out of energy concerns, and therefore require UI notifications to go through their systems. Notifications, out of necessity, have to go through client developer’s infrastructure, so they partially defeat the point of self-hosting.
(non-amp)