dgl.cx

Introducing RedisIRCd

The recent freenode shenanigans made me think about IRC a bit again. The thing that got me into IRC many years ago is how easy it is to understand. There's a simple text protocol, if you get it a bit wrong you'll probably find it works anyway. This simplicity got me into writing bots, then an IRC client and countless other things.

However a downside of IRC is the IRC servers themselves are all fairly big complex beasts, mostly because people abuse it and the servers need a multitude of ways to deal with that. (I've written some of the defenses.) There's a quick fix for this though: run your own private IRC server.

As I said, IRC is simple, but one downside is a bot needs to stay connected, else it will annoy everyone as it can be seen connecting and disconnecting[1]. This means it's hard to write a bot in a shell script. There are many workarounds for this, e.g. irccat.

All this led to a thought: Redis has pubsub, can we just bridge that to IRC? Initially I was thinking of writing a bot; basically yet another implementation of irccat. Then the thought extended, what about a private server combined with the idea of a bot? What if we write a custom IRC server that happens to bridge to Redis? We get very easy setup without needing bots, and things like flood limits (again, IRC servers protecting themselves from abuse) won't be a problem[2].

So redisircd was born.

How does this look?

Like that!

In the same way that irccat can use nc in shell pipelines, it's possible to do many things with redis-cli to publish whatever you want to redis, and therefore IRC, for example:

tail -F some-log | grep --line-buffered ERROR | xargs -d '\n' -n1 redis-cli publish log

And then maybe something like this ends up on IRC:

<log> ERROR: Frobinator overloaded

There's some slightly more complete examples in the source tree.

There's also JSON support for systems that already use Redis pubsub and would benefit from having some way to introspect part of the system.

For me the nice part of this it is "decentralised", in that I can easily run my own server on the same machine as my IRC client. There's no TLS and there might not be, ever, see Remembering the LAN for some thoughts along similar lines.

I'm not sure how this will evolve but hopefully at least the idea is useful to someone.

[1]: There's actually a neat fix for this, set a channel mode -n and things outside the channel can message into it. But of course that can be abused too.

[2]: Yes; it's easy to configure most IRCds to ignore flood limits, but it's yet another detail to setup.