Why IRC Sucks
Recently, I’ve been looking into IRC clients again… There are such a wide variety that surely one would fit my needs. Unfortunately, I have a very particular set of requirements, which makes finding one that meets my needs nearly impossible.
What am I looking for, you ask? Here I’ll list what I’m looking for, in no particular priority:
- Robustness. IRC is a complex protocol, not least because everyone violates the original RFC1 in different, sometimes divergant, ways. Unfortunately, this means that most IRC clients just implement the commonalities and leave it to the users to learn their preferred networks’ eccentricities.
- User extensibility. The vast majority of IRC clients support a very basic level of extensibility (mostly just creating new commands out of a mixture of existing ones). This is great if you don’t care about implementing support for new bits of IRC that the client doesn’t already support, or adding features which the client doesn’t already have. The downside is that you can’t take advantage of emerging standards like charybdis/atheme IRC services’ IRC authentication layer (aka CAP SASL). In particular, I’d prefer Python or Perl, rather than some kludgy wannabe language whose parser can’t handle tabs2.
- Accessibility. Only a few IRC clients are usable solely with a keyboard. All of them are text-only, to the best of my knowledge. While this doesn’t really bother me, they also all fail at Unicode in one way or another or have other issues.
- Intuitivity. I absolutely despise interfaces where you are required to read documentation in order to even use the things (which is one of the reasons I won’t play Dwarf Fortress). It’s fine to expose advanced functionality that way, but if I have to look up how to add a server to my server list, You’re Doing It Wrong™.
- Theming. Theming, in particular, is something I have yet to see any client get right. irssi’s can be broken quite easily without rhyme or reason. XChat’s is rather context-poor (as is Conspire’s). And nearly everyone else is limited strictly to message-oriented colouring.
- Comprehensive ignore/highlight systems. The only IRC clients that even remotely get this right are irssi and Circle, and even there Circle wins because it provides a rules-based system for affecting message flow.
- Use ISUPPORT, people. I can’t stress this enough. ISUPPORT (numeric 005) exists to allow IRC clients to better support server-specific features. Unfortunately, most IRC clients disregard large chunks of it, particularly when it affects client features (like irssi’s /names theming support).
- Logging. No, logging only what you’re going to display is not appropriate; I may want to log activity I don’t want to see in the IRC client itself. Likewise, I might want to see things in my client that I don’t want to log. The key here is fine-grained control over both the logging functionality and what gets displayed.
...And lest you think none of this applies to bots, bots fail on points 1, 2, 4, 6, and 7 too. (Point 8 also kind of applies, since I’d rather have errors be in a separate log file from everything else.)