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.
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:
- Standardized7 end-to-end encryption8. XEP-0384: OMEMO Encryption, XEP-0364: Current Off-the-Record Messaging Usage, XEP-0373: OpenPGP for XMPP.
- Mobile Push9. XEP-0357: Push Notifications
- Yes, technically, IRC has some support for message formatting in form of color, weight and slant control characters. ↩
- This enables realtime replication of messages aimed at one client onto other clients. ↩
- Stored server-side and retrievable incrementally. ↩
- Useful for catching up on offline discussions. ↩
- Despite occasional quirks, I highly recommend Biboumi as a featureful, yet sane and no-frills, IRC gateway component. ↩
- 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. ↩
- Apparently, there’s a way to use OTR with IRC using Pidgin.- ↩
- 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. ↩
- 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. ↩
–
via blog.vucica.net
I used the IRC years ago to talk with OpenWrt devs and that wasn't really convenient in Pidgin. But I know that the IRC has a good ecosystem of commands and bots which is probably not that is so fancy in the XMPP world. Also as far I understood the IRC should consume less bandwidth which may be important on a phone or bad internet but also eats less RAM and simpler to implement a client.
I installed the Prosody on my router to make a family chat but now I also interested in the ngIRCd which is even smaller.
The XMPP is better but I just want to check how it works. Sadly, both Prosody and the ngIRCd are outdated in the OpenWrt repo.
I see that the IRC has Direct Client-to-Client connections to send files as the ICQ and Skype had long time ago
https://modern.ircdocs.horse/dcc
This is a good feature if users can talk or transfer files directly and offload the server. This is also may be better for a privacy but now your ISP can collect metadata with whom you are talking now. Similarly the WebRTC/Jingle working.
In the XMPP there is XEP-0174: Serverless Messaging that also allows to talk directly but it has a focus on local network with Bonjour/Zeroconf discovery. It supported only by the Pidgin as a separate protocol.
But generally speaking nothing can stop you to talk directly over the Internet by just an IP directly without servers. I'll try to work in this direction.
But basically protocols aren't that important as a good client. The XMPP maybe is the most powerful but it looks like many XEPs newer even were implemented and it's unclear how they were added because during an implementation you'll find many questions for not described things.
The Conversations clients is… OK. But for a desktop or web clients are yet bellow usable.
Some thoughts, mostly about IRC as-it-was (there are a bunch of optional features/extension/capabilities in IRCv3 I am not necessarily familiar with, and people can correct me if I am missing a widely-available one), and without referring even to IRC RFCs:
* Classic IRC may consume less bandwidth, but this is at the cost of a lot of features: live presence updates (away/busy, statuses), persistence of media sharing (images, videos, …), history sync
* It is very nice to have simpler clients — by the time you get XMPP to do things correctly, it'll be quite large indeed — but if the protocol does not consistently specify the features, is it a fair comparison in the first place?
* You mention DCC "as the IRQ and Skype had long time ago" — however, IRC has had DCC since early-to-mid 90s, way before Skype existed, and before ICQ existed. You don't really want that: these days, you are typically beyond a NAT gateway (such as a consumer router, or your ISP might be doing it), so unless your IRC client both discovers your public IP and uses uPNP to forward a port to your actual client machine inside your LAN, it won't work. (Technically, you can statically forward a port and have your client advertise that. That's not good end-user experience.)
* IRC's DCC is not good for privacy: it's not encrypted, so your ISP will not collect just the metadata. There's apparently secure DCC, but there's no validation of TLS so a motivated ISP can intercept SDCC traffic without software being able to automatically detect it.
* WebRTC/Jingle will use direct connections (based on ICE candidates discovered), but it doesn't have to: if your provider is willing to sink the costs of tunneling the traffic (and that's expensive), a TURN server (such as coturn) can be set up, and candidates can be prevented from functioning.
* WebRTC/Jingle will generally be encrypted, and per above, DCC generally won't be.
* In WebRTC/Jingle, TURN kicks in if ICE candidate IPs won't work. But you generally want them to work. You don't want to be tunneled as this increases latency, and costs your provider in traffic — mainly group calls are unavoidable, as meshing the calls rather than doing hub+spoke increases traffic for every participant in the call massively, so the groupcall provider _has_ to invest not just in traffic, but with large enough calls sometimes also in compute, to recompress audio/video.
* What are the addresses advertised in ICE candidates? These will be a variety of IPs and ports that a machine advertises as knowing it's reachable through. Why do you want to advertise multiple IPs and ports you might be reachable at? NAT punching. WebRTC implementations can punch through most NATs using by sending and receiving UDP packets in a careful way. Public addresses that are to be advertised as ICE candidates can be discovered via STUN (these are cheap to run, more than TURN).
* All in all: 90s is the last time when DCC worked fine for an average user. Classic IRC DCC (which seems to be what you linked to) is truly direct-client-connection: your machine needs to be reachable on your public IP, and it needs to exchange it over CTCP messages. The doc you linked talks about reverse DCC, which (I'd expect) only helps if one side has a publicly routable IP that can be announced.
Speaking of DCC not making sense: IRC has another interesting and fun-to-implement relic that's a sign of the times (the 90s): the server is verifying your 'username'/identity by doing a dialback to your identd on a well-known port. It connects back to the IP you connected from, and shares the source port for the TCP connection that was established, and then trusts the information it receives back. This, of course, either requires the identd daemon to run on the same machine, or building complex infrastructure which, when you establish an outgoing connection to IRC, registers both your machine's source port and your identity. That is: similar information you need to store in NAT tables. Likely not worth it.
XEP-0174 is nice for LAN where you carefully configure routers to route traffic across broadcast domains etc, and where mDNS (zeroconf/bonjour or otherwise) are functional. But you lose OMEMO encryption, message history sync and a lot more. (OMEMO wants to store data in your account's PEP store, to announce the keys. It might be doable over serverless XMPP, but is it worth it without other sources of verifiable identity?) Anything that's a service offered by your server's domain JID (or services browsable under it) will be gone.
Regarding usability of desktop clients: Dino and Gajim are perfectly usable. Some features I like are dropping over time, but that's fine. Converse.js is mostly usable on the web, there may be others. The largest gap is on iOS.
Your experience will be limited by what Pidgin implements and by "install Prosody on my router" approach. What is critical for you to have a good experience is that an installed server is modern, and carefully configured with a set of important XEPs. You want to have functioning push, you want HTTP file upload (you seriously do want that, and not XMPP's classic implementation of peer to peer file sends), you want to have a MUC subdomain with MAM (chat history), you want to have correctly set up certs.
And — this may be controversial — you _may_ want to disable e2e encryption with OMEMO. OMEMO is nowadays the default in Dino, Conversations, Gajim (I think). It may be the default in Monal, Siskin, etc. If it's the default, why switch it off? XMPP clients do not have a way to negotiate how to synchronize keys, and I haven't seen a way to declare the name of a client ("this omemo key is my Nexus 6P, this one is iPhone 14, this one is Dino at work, …"). Not exchanging the keys, and not archiving the old keys, means the encrypted messages from 2 years ago are likely not decryptable by anything you run today. And clients don't generally let you easily export-import the keys in a manual way, so it's hard to maintain operational hygiene when it comes to preserving access to old chats. I'd even like to revoke the keys to stop future messages encrypted for the key. This is not exposed well. That's not good.
So if I run my own server (and I do) and other people I want to chat to connect to my server (and they do), I have no use for E2E encryption: TLS + on-disk encryption serverside is doing enough for me.
If you set up the server carefully, you'll mostly be fine, and have a really good experience.
IRC is old-school and good if you want to enforce people to send short, text messages in 1:1 chats. You may want that. That is a legitimate way to build a community.
But for typical chat situations? The only alternative I would consider for self-hosting is Matrix, which has its own list of flaws and massive complexities inherent in the protocol design.