⟵ Back 6 min · 2021-04-01

IRC's Flaws

IRC is quite an ancient protocol, having begun nearly 35 years ago1. As such, it is one of those technologies that evolved to keep up with changing requirements. For the longest time, IRC didn't have features considered necessary by today, such as SASL (aka authentication-without-sending-passwords-to-random-bots) or TLS/SSL support. Features like end-to-end encryption are still not widely used, despite it being 2021.

Like many technologies that evolved (think JavaScript, /bin/bash, etc), newer features were gracelessly duct-taped onto the protocol as they became necessary.


For those who don't know, IRCd services are a hacky way of providing user authentication and channel registration, management, and moderation tooling for a protocol which did not originally have those features. They usually come in the form of a set of bots, most commonly NickServ (for nickname management) and ChanServ (for channel management). They are typically provided by a software package separate from the IRC server implementation -- for example, freenode uses ircd-seven, but uses the Atheme service implementation.

To the best of my knowledge, these services were added instead of a protocol extension to allow existing users access to these features without having to patch clients. They have a few downsides, however.

Inconsistent channel configuration

There are two ways to configure channels:

Aside from the issue of ChanServ existing at all, the main problem is that these two methods often overlap. Instead of sensibly using channel modes for boolean settings (+i for invite-only, +s for secret, +t for "protected-topic", +m for moderated, etc) and ChanServ for options that have a value (access lists, auto-invited users for channels with +i, etc), many channel modes require a value (e.g. +I, +o, +H) while a few ChanServ settings don't. Occasionally, there are multiple ChanServ commands that do more or less the same thing (e.g. ACCESS vs FLAGS).


IRC is a bit infamous for making moderation difficult. Something as simple as banning a serial abuser can be confusing to inexperienced users, and doing the ban incorrectly can lead to the abuser evading it.


There are three types of bans:

The easiest solution is, in my humble opinion, is to force users to authenticate (or create an account) when connecting (or prohibit unregistered users from joining channels or messaging users). In addition to making channel operator's lives easier, it also opens the possibility of allowing multiple connections to use the same nickname (because why the hell should my iPhone's client be forced to use kiedtl|mobile instead of just kiedtl?).


This simple operation varies between server implementations. On freenode (irc-seven), it's done with the +q channel mode (e.g. +q joaquinito!attentiontroll@shadyvpn.someplace), but on InspireCD, it's done with a special ban syntax (something along the lines of +b ~q:nick!user@host) -- +q on InspireCD grants the user founder privileges.

No temporary bans

Another issue related to this is the lack of temporary bans -- bans that are means to be temporary will have to be manually unset when the moderator wants to do so. Some channels work around this by using a bot to automatically set/unset temporary bans.

No moderation log

This is a bit of a non-issue, but it would be nice if channel moderators could view a list of:

  1. the users banned or quieted,
  2. When they were banned,
  3. Who they were banned by,
  4. And the reason they were banned for.

IRC does technically have a "moderation log" detailing the list of banned (or quieted) users, but this info gets screwed up when a netsplit happens (the moderator who banned the user is replaced with the name of one of the servers, for example).


Though IRC's federated (for some value of "federated") nature may be seen as a feature to some, it introduces the issue of netsplits, where the servers disconnect. Abusers may take advantage of this to takeover channels or nicknames, or to join invite-only channels (known as "netsplit-riding"). While servers today have facilities in place to prevent takeovers, none of the servers implementations I've tested can prevent users from joining invite-only channels during netsplits.

There are a multitude of other issues I could mention:

The ones I have listed in detail are, however, what I believe are the most important flaws of IRC. They aren't especially severe, however (some might argue that the lack of E2E by default is an unacceptable defect).


IRC was created by Jarkko Oikarinen in August of 1988.


See https://tildeverse.org, https://tilde.team, https://tilde.town


TOR is usually banned on IRC networks, and is thus not an issue.

Kiëd Llaentenn © 2019-2022 — CC BY-NC-ND 4.0