Jump to Navigation

The Ideal IRC Client

I’ve been poking around on IRC for over a decade, and I’ve used over a dozen clients in that period: irssi, xchat, mIRC, ircII, EPIC4, EPIC5, IceChat, pjIRC, Mibbit, QWebIRC/Iris, ChatZilla, xIRCon (both the worthless X-based one and the Windows one), BitchX, Konversation… the list goes on. In all that time, the only client I’ve consistently gone back to is irssi, and only because I consider it to be the least-bad of an eminently bad lot. Rather than try to document the problems, however, I want to discuss what I actually want in a client.

First and foremost, I want extensibility which follows the guiding principles set out for the languages in which they are implemented. I don’t want to write Python that feels like it was written by a C programmer, for instance. I do, however, want a robust API; I should not have to send anything through the client’s command parser.

Secondarily, I want a proper filtering engine. Most of the scripts I write for myself, rather than my bot, should never have needed to be scripts. Additionally, the scripts I do write for my bot shouldn’t need to manually check e.g. the ignore list before processing. In fact, a proper filtering engine means that all of my bot’s functionality could be implemented as filter actions, with obvious consequences.

Nonwithstanding the above, I also want a minimalistic user experience. The less I need to configure my client, the better. Take lessons from Chrome: the only options it has are ones it must have; I should not have to, for instance, know the intimate details of the servers on which I communicate. If theming, rather than colour scheming, is a thing, I should be presented with a selection which includes accessibility-oriented themes (e.g. a high-contrast light-on-dark theme).

Most importantly, IRC clients must implement the base extensions enumerated by the Atheme.org IRCv3 working group, preferably in ways which are opaque to the user. I do not, for instance, want to know how my client authenticates me to services (unless I’m interested in the security aspects), only that it does so and prefers secure mechanisms over insecure ones.