Deprecated: Function create_function() is deprecated in /home/Jay2k1/wwwroot/blog.jay2k1.com/www/wp-content/plugins/wp-spamshield/wp-spamshield.php on line 2033
The znc IRC bouncer is a great piece of software. In this post, I’ll explain how to get individual backlog/buffer playback for each client.
Auto Clear Chan Buffer and
Auto Clear Query Buffer options, if checked, make sure that you receive backlog playback only once (instead of every time you connect). This however is not very useful if you use multiple clients and want to see all conversations on all of them, because only the first client to connect will receive the backlog. Leaving said options unchecked is not advisable either, since it will make ZNC send you the same backlog again and again, every time you connect. In both cases, it will only record backlog while no client is connected.
You talk to someone from your computer at work, then you quit that client, go home and connect with your own computer. You will get any message that was sent while you were offline, but you can’t see the conversation you had earlier.
You talk to someone from your computer at work, then you go home without quitting your work client and connect with your own computer. You won’t get any backlog at all.
The ugly solution
Instead of connecting all your clients to your ZNC user, you create an additional ZNC user for every client, so you have your main user plus one for each client. You then connect all additional ZNC users to the main user and all IRC clients to their respective ZNC user.
Say your name is John Doe, and you have three clients: xchat, irssi and mIRC. The connection diagram would look like this:
_________________________________________________ / \ | ZNC | | via 127.0.0.1 | xchat ------> user "johndoe_xchat"----------\ | | v | irssi ------> user "johndoe_irssi"---> user "johndoe_main" ---> IRC | ^ | mIRC -------> user "johndoe_mIRC"-----------/ | | | \_________________________________________________/
This illustration was taken from the ZNC wiki.
Setting up the accounts like this will make each ‘client user’ store its own backlog. You can also configure the number of lines (the ‘buffer size’) per client, even on a per-channel basis, which might be useful if one of your clients is running on a smartphone. The disadvantage of this method is obvious – you need to set up multiple users. It’s kind of a hack to achieve the desired outcome.
The new solution
As of znc 1.6, clients can have a
client identifier and there is a module called clientbuffer that makes use of it. With client identifiers, ZNC becomes aware which client you are using to connect to it, hence it can distinguish between your clients, and said module keeps a separate playback buffer for each client.
To see how to use it, you should read the wiki page. Basically, after installing and loading the module, you need to add identifiers to your clients by putting them in the password field:
or in the username field:
Then you need to make the module aware of the clients you want to use it with by issuing the AddClient command:
/msg *clientbuffer AddClient <identifier>
You also need to disable the
Auto Clear Chan Buffer and
Auto Clear Query Buffer options, otherwise ZNC will clear the buffers as soon as any client connects.
This feels like the ‘right’ way to do it, but it has some disadvantages as well: You can’t specify individual buffer sizes
and – at least in my experience – it sometimes fails to clear the last message of a query so it is being sent again and again every time you connect (see this issue). This is somewhat annoying, but I chose to live with it rather than going the multi-user way or having only partial logs on all clients. There is now a patch that fixes this bug, so now the clientbuffer module is really the best option. Get the module from here.
As you can see, none of the three possible ways are perfect, but now you know what options you have available. I hope someone will add a per-client buffer size setting
and fix the query bug some day – it would make the plugin pretty much perfect and even ready to be made an internal module in my opinion.