I've done development in and around IRC since ~2014, and this post is really a long time coming. It summarizes discussions I've had, heated ones too, about the viability of IRC as a mainstream chat platform today, and into the future. As someone who's been accused of "hating IRC" and being "pointlessly pessimistic", this rant is for all the IRC fans out there who don't seem to understand why their favourite platform is fading into irrelevance. There's no shadowy corporate force scheming to take away IRC's popularity. Rather, IRC simply isn't living up to people's expectations of chat platforms in the year 2022. And as a result, I've slowly lost my interest in developing for it.
If you're a fellow developer and feel upset by anything I write here, please don't take it personally. IRC's 30+ years of legacy baggage is not any single person's fault.
In classic IRC, the only people that receive a message are those who were in a channel at the time it was sent - there's no provision for providing history to clients that leave and reconnect. Of course, people found the idea of missing conversations annoying and devised many workarounds:
These are all time-tested options, but require technical knowhow or someone to foot the bill for a paid service. This will be fine for developers and hobbyists, but simply doesn't scale for the general public. Who wants to pay money, or sift through plethoras of free BNC providers, most of which limit your number of simultaneous networks, just to get chat history?
Fortunately, IRCv3 is working on a CHATHISTORY extension. In addition to storing history in memory, some implementations (Ergo, UnrealIRCd) have also added support for persistent on-disk history. I seriously hope these features become more widespread, as they lower much of the barrier of entry for IRC newcomers.
In the meantime, I would like to see larger networks start offering their own in-house bouncers targeting their own networks. One of the biggest headaches for free BNC operators and networks alike is abuse (ban evasion, clones, etc.), and unifying account management with what the networks are already using could help significantly in that respect.
Rich media is a hard problem to solve: storage requirements grow with time, and the problem of abusive / infringing / undesirable content is much worse than with plain text. Modern chat platforms have mostly solved the former via economies of scale (I don't think the latter is really solvable), and indeed, services like Facebook Messenger, Telegram, and Discord make it easy to upload files and send audio / video with built-in previews. IRC on the other hand has... text (and DCC, an even more obscure file transfer protocol that struggles with NAT much like all pure-P2P protocols).
While hosted clients like IRCCloud and The Lounge do allow do allow previews and file uploads, this brings up the same issue as before: the burden of making the feature work is shifted to the client. There's also an issue of discoverability here, because the large majority of clients are not hosted and thus don't have the infrastructure to build these features.
IRC fans love to tout how lightweight IRC is precisely because it skips all of these features. But this points to the crux of the issue: lightweightness and built-in persistence / rich media are fundamentally incompatible - the files and state have to be kept somewhere. It's great that IRC is remarkably lightweight, but when the Internet has by and large grown to expect more features from their chat platforms, what does IRC gain from standing in the opposite corner?
IRC diehards must understand that chat platforms are not successful in a bubble - even if people are joining to interact with communities they're part of, it does not mean they individually love IRC as much as you do. The platform must cater to its users' wishes; otherwise, with enough debate, entire communities will leave altogether. This already happened with both Mozilla and KDE officially moving to Matrix.
Account and channel management on much of IRC today is done through network-operated service bots, such as NickServ and ChanServ. Despite their popularity though, these programs were never developed with a standard UI in mind, and the commands and names of service bots vary widely between networks.
The most popular IRC services packages, Anope and Atheme, account for 85% of ircstats.org's surveyed IRC networks as of 2021-12†. Between these two options, we're lucky to have achieved some amount of convergence in terms of command structure (e.g. /ns identify [account] password, /ns register password email), and server side aliases like /ns becoming a de-facto standard on many IRCds. However, this facade of compatibility breaks down quickly if you start using other features, e.g.:
/ns resetpass nick email on Anope and /ns sendpass on Atheme/ns recover on modern Anope, and /ns ghost on AthemeAll in all, these differing commands add far too much confusion and rote memorization for people that want to use multiple networks. Even if individual networks have sufficient documentation detailing their own features, it'll likely be trial and error that cause individual users to figure out just how different all these implementations are.
IRC has a long history of interoperability, and it's honestly a great feature to aim for. But the current state just doesn't give a complete experience for people wanting to take advantage of it.
† Then, there are network-specific services like Undernet's X and QuakeNet's Q, which are even further apart in terms of the commands they offer.
For the sake what I'll assume was once bandwidth efficiency, IRC's design puts channel privileges, bans, and channel settings into a single flag-based "mode" mechanism. This was part of the initial RFC 1459 spec, and lives on in most* IRC implementations since. Those who know me well might know that I really hate this system, for these reasons:
Modes are hard to explain. No one in the right mind would shoehorn all these features into a single command with a new platform today, because they're fundamentally different ideas†.
Modes are even less standardized than services commands. Even IRCds that support the same feature will often use different mode letters to represent it - some like InspIRCd are practically out of mode letters entirely. For power users, varying meanings for mode letters forces a lot of memorization. For bot and client developers, it's impossible to code for these in a portable way at all - you're basically forced to hardcode mode letters' meanings by IRCd. Although there is an IRCv3 named-modes extension in the works, the cost there is dealing with an extra layer of indirection for servers and clients alike.
Modes are difficult to type and read. Mode characters are case sensitive (yay, mobile keyboards), and argument matching is not obvious when multiple modes get (un)set at once - you'd have to either remember what all the individual modes mean or sort through the pile of text in 005 / RPL_ISUPPORT each time.
* Twitch explicitly doesn't support IRC modes in their implementation. (Hooray? As a side note, it's pretty cool how they're building on top of existing platforms and hiding away much of the underlying complexity.)
† IRC adapts to this by introducing the idea of mode types. Type A modes are lists, where multiple instances of a mode with different arguments can be added and removed. Type B modes have a parameter when both setting and unsetting them. Type C only requires the parameter when setting, but not removing the mode. And type D modes just don't bother with parameters at all. Notice how this blurb doesn't even begin to explain why types B to D have to be different or where they're used - I'll leave that as an exercise to the reader. To a new op who just wants to learn enough to volunteer with a channel, I may as well be explaining nuclear physics!
Another pain point is the myriad of (reasonable) ways to format bans on IRC: *!*@host, *!*ident*@*.someisp.net, *!*@*.blahblah.com, *!*@192.168.1.*, etc. Then there are ban formats that are trivial to bypass, like nick!*@*† or *!ident@*. And then there are vHosts that on some networks are easy to turn off (easy ban evasion), and differing cloak formats that force you to set IP range bans in different ways (see e.g. 111.222.xxx.yyy on charybdis/solanum and aaaaaaaaa.bbbbbbb.cccccccc.ddddddd.IP on UnrealIRCd).
The point here is that there is no single way to set bans properly across all of IRC, and the only way to teach this properly to ops is some combination of examples (specific to each network) and a crash course in DNS + CIDR addressing. Channel management bots, or anything that wants to track users by hostname, are forced to hardcode in different cases for different styles of masks. Most clients, on the other hand, will only give you some general ban style to default to (e.g. in a /ban alias), making you deal with specific cases manually.
I'm not really sure there's a fix to all this. Displayed hostmasks have been a malleable feature for so long, but the resulting complexity feels like a curse for people trying to seriously moderate channels. Extbans help somewhat in this regard, but they're similarly unstandardized between implementations.
† I've seen on multiple occasions people add access list entries for nick!*@* masks or WebIRC gateway IPs, only for their channel to be taken over within the span of hours.
The current state of IRC services and moderation are command-line driven to the core. This is fine for folks with a big screen and keyboard, but awful for people on the go. Fixing a ChanServ access entry or searching the right ban to remove in a list is a painful task on a mobile screen (yes, there have been times where I've actually had to do this). I'd much like to see higher level, GUI-based management interfaces for these sorts of tasks, but it's unlikely they'd ever be feasible unless more of the underlying processes are standardized.
SASL is the de-facto standard for login-on-connect on IRC. I would consider this to be one of IRCv3's greatest successes - it's gained lots of traction and fixes a lot of usability issues with logging in and joining channels on connect. For instance, your current nick is no longer required to the same as your account name, so a connection drop and reconnecting before your ghost connection disappears won't cause your login to stop working. Similarly, clients don't need to manually wait for logins to finish before joining channels that require an account.
But how successful is SASL really? As of 2022-08-16, only half the top 10 networks from netsplit.de providing nick registration services actually advertise SASL as supported. For a specification that came out ten years ago, 50% adoption among the largest networks is really not that impressive. I can't stress how much this matters - Large networks are the face of IRC for much of its user base, and when half the largest networks don't support features that are almost ubiquitous among clients, people will get confused and frustrated. Not only will they be upset by individual networks keeping simple tasks difficult, they'll be left with a worse impression of IRC as a whole.
| netsplit.de Ranking (2022-08-16) | Network name | Services? | SASL CAP advertised? |
|---|---|---|---|
| 1 | Libera.Chat | Y | Y |
| 2 | OFTC | Y | N |
| 3 | IRCnet | N | N/A |
| 4 | EFnet | N | N/A |
| 5 | Undernet | Y | N |
| 6 | freenode | Y | Y |
| 7 | Rizon | Y | Y |
| 8 | Chatzona | Y | N |
| 9 | QuakeNet | Y | N |
| 10 | PuntoChat | Y | Y |
| 11 | GIMPnet | Y | Y |
| 12 | IRC-Hispano | Y | N |
As someone who hangs out in support channels, one of my biggest pet peeves is people pasting 5-10 lines and either getting kicked by flood protection or having their message churn out at a whopping 1 message every 2 seconds (I call this "slow flooding"). Is 5 lines of text really a "flood" when formatted code blocks and uploading large messages as files are ubiquitous among modern chat platforms?! This is a serious frustration for newcomers and veterans alike, and all the channels that say "use a pastebin for long text" are offering an inconvenient, bandaid workaround without even explaining why! Edit 2023-05: Even more egregiously, many clients don't give an indication that multi-line messages will get throttled, leading to an extremely confusing end result where people often don't know that they're flooding text slowly, since messages appear to send immediately on their end.
I've unironically met people who think anything above 3 lines is a "flood", because it "disrupts the rate of conversation" or "makes text difficult to follow". Given that just about every client includes text scrolling, and you'll need to use that anyways to catch up on busy channels, I don't buy this argument at all.
IRC needs to move away from rate limiting defaults stuck in the 1990s, but these are so incredibly ingrained in servers, clients, and even bot frameworks. In one case, I couldn't even let a relay bot send text faster without changing how its IRC library was loaded. We have much more capable connections and devices in 2022 and should be taking advantage of that.
Similarly, the IRC line limit of 512 bytes is awful for delivering any sort of long messages, bots and clients alike. Because this line limit includes the full sender prefix, command name, and target, the amount of text you can send to a channel depends on:
Am I seriously supposed to accept that connecting with IPv6, which tends to have longer hostmasks, somehow gives me less room to send text than using IPv4?
Formatting / wrapping long text on IRC is an awful experience, and combined with message rate limits, this means that you really only have a few options for sending large payloads:
Although IRCv3 is working on a draft/multiline extension for assembling multi-line messages, it feels very much like a workaround. There's still no escape from this sender prefix clutter, and the implementation details look hardly straightforward as a result. Edit 2022-12: if there's one thing I wish IRC could break backwards compatibility with, for the sake of getting with the times, it would be this. Changing some buffer size definitions is not the hardest task compared to many other features I've mentioned here.
There are two related issues here that are really the straw that broke the camel's back for me not wanting to work on IRC anymore.
The first one is fairly subtle: in my almost decade-long adventure here on IRC, I've found that a sizeable portion of IRC admins see all other networks as hostile competition. This comes down to policymaking and generally manifests as rules that target "advertising", "promoting", or I'd honestly say in some cases, even mentioning other IRC networks while on their network (see e.g. GeekShed, Undernet terms). All of this seems incredibly self-serving considering that IRC clients are designed to manage connections to multiple networks at once. For a small network, disputes like this are petty - for a large network, it's an absolute disaster in the long run to intentionally impede discoverability on a platform that is already fading into obscurity.
The second point here is one of my most frustrating encounters personally. For context, one of my larger IRC projects was PyLink, a server-side "puppeting" relay between IRC networks aimed to let small / mid-size networks loosely federate. In the 6 years I've worked on this, I've witnessed two separate IRC indexer services discuss banning networks using the product entirely, because of some excuse that it inflates user counts.
Never mind how this was never a goal - it's a side effect because many IRCds don't let you exclude specific servers from user counts (and there's little incentive for individual network admins to fix this anyways). But this speaks to an appalling double standard when it comes to IRC competition. The Matrix.org bridge creates tens of thousands of client connections for Libera.Chat and OFTC, the two largest networks, and nobody bats an eye. Adding bots to a server to actually inflate user counts is generally trivial - just say they're communities in private channels, and who could ever tell the difference! It truly boggles my mind how people advertising themselves as "IRC search engines" are care more about the numbers of /lusers than people connecting actual communities with bridges.
Most of my work in IRC has been focused on improving the experience of small and medium sized networks. Why? Because small deployments matter. The largest networks, through a mix of broken communication, historical disagreements, or sheer apathy, simply don't move fast enough to improve IRC's usability. Yet it's established communities, word of mouth, and search engines that all keep them as the face of IRC for much of its userbase: these are the networks people will most likely discover first, and use to form opinions of about IRC in general.
On the other hand, smaller deployments are great places to test-drive and solicit feedback for new features, pushing IRC as a whole to be more modern. But these small networks are in a pit of hell when it comes to irrelevance. Not only are you competing against larger networks, but other chat platforms with wider user bases and more features. The network effect works against you, and I don't think it's news to anyone that IRC as a whole doesn't have a reputation for being easy to use. GNOME, in discussing IRC vs. Matrix, cites a lot of the same issues I've mentioned here already: lack of persistence, lack of rich media, and widely differing expectations compared to different platforms.
For me, running a small network has been a failed experiment. Even with a webchat instance or providing hosted bouncers, my attempts to convince folks less familiar with technology to join IRC have at most been that they'll hop on for 30 minutes, disconnect, and basically never come back again. Compared to all the options out there, IRC just doesn't appeal to the masses anymore. While some folks may be OK with that, I find it pretty demoralizing as a hobbyist developer. It pains to know that your work will only benefit an ever shrinking audience. It pains to have to justify to colleagues that know about IRC why you're still working on such a dated piece of technology, and explain to everyone else what IRC even is.
I don't think fixing IRC is something that any single person can do; its fragmentation is just too much. And eight years later, I'm tired of trying. So many new ideas are impossible to implement without kludgy fallbacks that add extra work for everyone involved (see e.g. display names, multiline and its tree of dependent specs). And even popular, ratified specs like SASL aren't widely deployed enough to be universally reliable.
Really, it's just time for me to move on.