Tag Archives: irc

My IRC proxy setup

IRC (Internet Relay Chat) is a pretty important communication medium for a lot of Open Source projects nowadays. While email is universal and lives forever, IRC is the equivalent of the hallway chat you’d have with a coworker to bounce ideas around. IRC has the advantage of being a reasonably simple and open (and old) protocol, so writing things that interface with it is about as easy as email clients. But, it has a pretty substantial drawback: you only get messages when you are connected to the channels in question.

Again, because it’s an open protocol this is actually a solvable problem, have a piece of software on an always on system somewhere that remains connected for you. There are 2 schools of thinking here:

  • Run a text IRC client in screen or tmux on a system, and reconnect to the terminal session when you come in. WeeChat falls into this camp.
  • Run an irc proxy on a server, and have your IRC client connect to the proxy which replays all the traffic since the last time you were connected. Bip, ZNC, and a bunch of others fall into this camp.

I’m in Camp #2, because I find my reading comprehension of fixed width fonts is far less than variable width ones. So I need my IRC client to be in a variable width font, which means console solutions aren’t going to help me.


ZNC is my current proxy of choice. I’ve tried a few others, and dumped them for reasons I don’t entirely remember at this point. So ZNC it is.

I have a long standing VPS with Linode to host a few community websites. For something like ZNC you don’t need much horse power and could use cloud instances anywhere. If you are running debian or ubuntu in this cloud instance: apt-get install znc gets you rolling.

Run ZNC from the command line and you’ll get something like this:

znc fail

That’s because first time up it needs to create a base configuration. Fortunately it’s pretty straight forward what that needs to be.

znc –makeconf takes you through a pretty interactive configuration screen to build a base configuration. The defaults are mostly fine. The only thing to keep in mind is what port you make ZNC listen on, as you’ll have to remember to punch that port open on the firewall/security group for your cloud instance.

I also find the default of 50 lines of scrollback to be massively insufficient. I usually bounce that to 5000 or 10000.

Now connect your client to the server and off you go. If you have other issues with basic ZNC configuration, I’d suggest checking out the project website.

ZNC as a service

The one place ZNC kind of falls down is that out of the box (at least on ubuntu) it doesn’t have init scripts. Part of this is because the configuration file is very user specific, and as we say by the interactive mode, is designed around asking you a bunch of questions. That means if your cloud instance reboots, your ZNC doesn’t come back.

I fixed this particular shortcoming with Monit. Monit is a program that monitors other programs on your system and starts or restarts them if they have faulted out. You can apt-get install it on debian/ubuntu.

Here is my base znc monit script:

znc monit

Because znc doesn’t do pid files right, this just matches on a process name. It has a start command which includes the user / group for running this, and a stop command, and some out of bounds criteria. All in a nice little dsl.

All that above will get you a basic ZNC server running, surviving cloud instance reboots, and make sure you never miss a minute of IRC.

But… what if we want to go further.


The idea for this comes from Dan Smith, so full credit where it is due.

If you regularly connect to IRC from more than one computer, but only have 1 ZNC proxy setup, the issue is the scrollback gets replayed to the first computer that connects to the proxy. So jumping between computers to have conversations ends up being a very fragmented experience.

ZNC presents as just an IRC Server to your client. So you can layer ZNC on top of ZNC to create independent scrollback buffers for every client device. My setup looks something like this:


Which means that all devices have all the context for IRC, but I’m only presented as a single user on the freenode network.

Going down this path requires a bit more effort, which is why I’ve got the whole thing automated with puppet: znc-puppet.tar. You’ll probably need to do a little bit of futzing with it to make it work for your puppet managed servers (you do puppet all your systems, right?), but hopefully this provides a good starting point.

IRC on Mobile

Honestly, the Android IRC experience is… lacking. Most of the applications out there that do IRC on Android provide an experience which is very much a desktop experience, which works poorly on a small phone.

Monty Taylor pointed me at IRCCloud which is a service that provides a lot of the same offline connectivity as the ZNC stack provides. They have a webui, and an android app, which actually provides a really great mobile experience. So if Mobile is a primary end point for you, it’s probably worth checking out.

IRC optimizations for the Desktop

In the one last thing category, I should share the last piece of glue that I created.

I work from home, with a dedicated home office in the house. Most days I’m working on my desktop. I like to have IRC make sounds when my nick hits, mostly so that I have some awareness that someone wants to talk to me. I rarely flip to IRC at that time, it just registers as a “will get to it later” so I can largely keep my concentration wherever I’m at.

That being said, OpenStack is a 24hr a day project. People ping me in the middle of the night. And if I’m not at my computer, I don’t want it making noise. Ideally I’d even like them to see me as ‘away’ in IRC.

Fortunately, most desktop software in Linux integrates with a common messaging bus: dbus. The screensaver in Ubuntu emits a signal on lock and unlock. So I created a custom script that mutes audio on screen lock, unmutes it on screen unlock, as well as sends ‘AWAY’ and ‘BACK’ commands to xchat for those state transitions.

You can find the script as a gist.

So… this was probably a lot to take in. However, hopefully getting an idea of what an advanced IRC workflow looks like will give folks ideas. As always, I’m interested in hearing about other things people have done. Please leave a comment if you’ve got an interesting productivity hack around IRC.

Staying connected while you are away, using an IRC Proxy

Internet Relay Chat (IRC) has been around for just about ever.  In the 90s it was used for chat rooms and warez sites mostly.  For the past decade it’s become one of the key pillars of communication for the Open Source Community.  It has the advantage that the client and server are free and open, and there is an inherent redundancy system built in.

One of the challenges of IRC, over say email, is that you need to be online to see the discussion.  On a really global project this is a problem, because of the pesky fact that daytime is determined by facing the Sun, and living on an orb, only 1/2 the earth gets to do that at a time.  Life would be so much simpler if the flat earthers were actually right.  But there is a way to stay connected, even when you are not, which is using an IRC proxy.

Using an IRC Proxy

The get started you will need a Linux machine, that you can run code on, that is always on.  It doesn’t need to be on your network, but you need shell access.  If you are a Linux geek level 4 or higher, this is probably not an issue.  You probably either have a Linode or a home server that’s always on.  If not… well sorry… your journey ends here.  There is not, as of yet, a cloud service to provide this for you.  Please come back once you level up.

The next step is the actual IRC proxy.  IRC is a simple enough protocol, which goes over clear text, that many people have written a man in the middle server for it.  You connect the proxy to the IRC server as you, then you point your IRC client at the proxy.  When you are connected to the proxy, everything works as normal.  Your messages are sent back and forth in real time.  When you disconnect from the proxy, the proxy keeps you logged into irc and logs everything that goes on.  The moment you reconnect to the proxy all those messages are replayed to your client.  You now have a full offline ability.

My favorite IRC Proxy

There are many out there.  A few years back I spent some time trying to get one that I didn’t hate, and I landed on miau.  I’ve even packaged it for ubuntu, so if you are on that platform, it should be easy to install.  Once installed, read the same miaurc on configuration, it’s really well documented, and should be easy enough to get rolling.

Although miau supports a password to connect to it, I don’t really trust running another service connected to the internet that just has a password in clear text.  My solution here is to have miau only listen to localhost (, and ssh proxy to the machine.  Pick a port (like 4098) on your local machine and have that forwarded whenever you connect to that server.  In linux this would look like the following in you .ssh/config.

Host your.server.name.com
LocalForward 4098 localhost:4098

The have your IRC client (like XChat) connect to localhost:4098.  This will mean that you will only be connect to IRC when you have an ssh link to your proxy server.  It works quite well, and is about as secure as you’ll get.

Why bother?

If you made it this far, you probably already know why.  When development conversations happen at 4am your time on IRC, you are probably never going to participate directly.  But, having access to the conversation when you connect in the morning is a very good thing, and I’ve walked people through this setup enough times in the past, writing it down for posterity seemed like a good thing.