zenircbot.md

Handling multiple bots in a single redis instance

This is meant to be the basis for a discussion on this topic. It will cover some of the background as well as the ideas I currently have for handling this.

Background

Commonly people as about how to run ZenIRCBot against multiple IRC servers, as well as running multiple bots in the same instance of redis. My original thoughts on this were to make it so the bot could instantiate the underlying IRC lib once for each IRC server, then pass along what server the message came from in the protocol. Requiring all clients to reply with the server they want their message to go to as well.

I found this to be a less savory method due to the need to manage multiple connections within the same bot. Pinging the server for each of them and making sure they are still alive.

Redis key prefixing

This at first feels like a very clean solution. The problem comes when you need to let the client services know what the prefix is. You can point them at the bot's config, which works alright for services that are long running. Services that are started from other applications or run other servers will need to include the prefix in their individual config or be hardcoded.

Backwards Compatibility

This doesn't require a protocol change, so the messages can still come through as version 1. But older services wont know to look for prefix so they wont be able to communicate with the bot. This requires the bot to listen/publish on the original channels as well which is a debugging nightmare, or just drop support for all of them.

Bot names

This takes a note from the polyserver thought I had above. But is also inspired by Justin Abrahms while talking to him on our way to hack together. The idea is instead of a server field to the envelope, adding in a bot field. So when the bot receives a message from IRC, it will include its own name. And when a service replies, it will also include the bot it wants to say the message.

Services could be configured to whitelist/blacklist bots, or just reply to all messages that come in. Bot name could be auto generated from server name + nick, or could be defined in the config.

Backwards Compatibility

This would require an iteration of the protocol version, but because channel names stay the same, there can be a path for handling version 1 messages.

My gut instinct says that if you have version 1 services running all bots would attempt to act on the messages. This means if you are only running one bot then you can put off upgrading your services, but if you want to move to multiple bots then you will also need to upgrade your services to be version 2.

Preference

I am leaning very hard toward the bot name idea. This would allow someone to implement a polyserver bot, as well having a more sane backwards compatibility story.

justinabrahms
I vote for multiple bots running against the same instance with a server name in the payload they deliver.
justinabrahms
ie: one bot for multiple networks is an implementation detail, and isn't inherent to the problem of "how do I get services to respond to multiple incoming messages"
justinabrahms
multi-server incoming messages, even
justinabrahms
bots know the network they're listening on, so can filter message coming back appropriately.
Wraithan
justinabrahms: server name means you can't run two bots against the same server
Wraithan
which is why you use a botname or other thing like that
justinabrahms
The benefit of that being that you get different names?
justinabrahms
I don't see a ton of value in that, but *shrug*
Wraithan
I run 4 bots on freenode
ryana
scripted bot theater!
justinabrahms
why separate bots?
Wraithan
justinabrahms: different naming and in some cases different services
Wraithan
ZenWraithBot can always have fluffy stuff added to it, but zenrtdbot is mostly srsbsn
Wraithan
as two examples
justinabrahms
hmm
ryana
Wraithan: I don't have a whole lot of useful input for this subject. I think aaronpk would though, but he's offline until next week sometime I think
justinabrahms
so you want a bot that listens for particular services, I suppose.
justinabrahms
I don't think services should be aware of the publisher at all.
justinabrahms
eg: which bot sent the message.
Wraithan
I think they shouldn't care if they don't want to, but some already have to know what channels they care about
justinabrahms
mmkay. I suppose difference of design choice. I think your goals are to make the bot dumb and services smart.
Wraithan
I have services that specifically work in certain channels, I feel like that isn't uncommon
justinabrahms
I'd prefer the opposite, as I'm likely to write more services than bots.
Wraithan
I don't want to have to take down the bot to change what services it is listening for
justinabrahms
I'd have to think more about it, I think, but I dislike the notion of having the services be so stateful.
justinabrahms
as above, I'm more likely to write a bunch of services, whereas I'll have comparatively few bots.

having a bot_id field in the json messages being passed over pub/sub seems like a good approach. existing services would still work (though possibly in a confusing manner with multiple bots), and the door is open for analysis across all bot activity, such as messages per second, through a single choke point.