Maz's calendar. [IRC user data storage planning]

In Maz's calendar this year is a year of bot writer's block. :D

Well well well. Before anyone kills me for mentioning IRC bot, let me explain. I have a friend who has been keeping up a few websites during his life. Usually community driven sites, where people do "know" each others. With "know" I mean that they really have an internet community, exchange thoughts, play games and so on.

His newest project is an old pen and paper style RPG, but at this time it is being played on IRC.

I have written a few IRC bot scripts (trivia/anagram games, stats collection etc).

Now I decided to start a new hobby project, yet another IRC bot :) But this time I thought I'll create a more generic bot engine, which can be easily extended by adding C callbacks to it. And actually possibility to call some php scripts on web server.

The main goal for me is to create a engine for others to use. But I would also like to do a favour to my friend, and make a bot he could utilize in his IRC RPG. But I encountered the same problem as always with bots. How to do reliable user identification, without giving users extra burden of registering to a bot / giving passwords etc (I assume there is no reliable way, I guess I need to make it configurable if password based user identification is used, or if some other method like hostmasks is preferred)?

Another question is: How to store the user information?

Somehow I just cannot do any kind of decision in this matter. So if someone has done something similar, or has thought of making something like this, could you give me some fresh ideas?

Oh, and if someone became utterly curious, I do have my work in svn repository, at here:
Revision 67: /

bugtracker here:
Teotilcan Bugtracker

and also online project management (using dotproject) - but I doubt anyone is interested in seeing that :D

And if someone for some godforsaken reason does inspect the stuff in there, drop me a note about bugs etc :)


But my idea was not to advertice the project, I was asking if anyone has ideas about how to keep track of users between IRC sessions?

Okay.

I devoted some more thinking time to this matter. Let me elaborate it a lil more.

In my friends RPG case, the IRC server is quite closed one. All players are expected to have their nicks registered, and when the bot connects to server/channel, it can perform whois query to everyone online. There will be a string telling if user is registered. Similarly, after a new person joins to a channel where bot is online, it can do a whois again (after a certain timeout so user has time to send the passwd to server). So basically user management and identification can be based on this information.

This however is not the usual case on regular servers. Besides I doubt any RFC specifies this nick registration, even less is it standardized. So in generic engine this is not suitable.

Other two methods I can think of are
1. password which is registered to bot. This is quite reliable (although creating a sniffer is not hard, and plain text passwords are thus quite unsafe). I doubt anyone would really want to obtain such a password. But sending passwords to bot is a pain. So this is somewhat uncomfortable.

2. Host mask / nick based identification is even less reliable, besides many people have dynamic IPs, meaning that many digits of the hostname/ip address should be masked off. This is not reliable at all, but it does not require user to do any password sendings etc.

More I ponder about this, more certain I am that all of these options should be supported, and user should have power to choose used option from configuration files.

Since my bot engine will be based on callbacks user can register to match some event on server/channel, I should also make it possible for user to disable user data handling from bot totally, and let user to create his/her own user management.

When I look these as requirements, I'll start seeing a total mess in implementation.

At the moment I have following idea/implementation.

There is config files which specify following things (amongst other)
Events triggering call of a callback function are in one text file as follows:

Code:

---

UniqueIdNumber                callbackEventType                Originator(chan/user)                [triggerstring]        [Chan/Privmsg/Dcc]

---

UniqueIdNumber is id which is used to bind an event and registered callback together.
callbackEventType is type of the triggering event, join/part/text string
Originator is channel or user(s). (Here is one problematic spot)
triggerstring is used with text events, If user who is in originator list sends text string matching to this, then event is triggered.
Chan/Privmsg/Dcc is location where text event can be detected.

Now. The originator.
I thought I'll use ; separated list of possible originators, and * as wildcard. So it could be something like #chan1;#chan2;nick1@hostmask1;nick2@hostmask2...

This approach would naturally work with nick@hostmask based identification. It would also work with registered nick based identification. But password based identification is somewhat harder to do in this manner... So I am a bit buzzled. Any ideas? (Well, solving a problem is half of the coding, right? Hence I feel this forum is appropriate place :) And when bugfixing and maintenance is 80% of the work, there's not much time left for implementation :D )

Okay. Let's assume I would postpone passwd based identification. Lets think of the implementation for a lil while.

If user of bot has not decided to build his own user management, then user identification should be done before callbacks are called. But since which user can trigger an action depends on the event in question, event should be evaluated before user management. So the place for this checking is quite clear.

So what information do we need about our precious user?
Nick and hostmask naturally. If user is registered or not. And from which channel/server did this command came from. Is there anything else? Somehow I do really have a code writer's block here.

Oh, I guess it might help you to answer, if I explained how this thing is aimed to work:

1. read events (and some other configs from config files).
2. register user callbacks (bind them with read events based on ID)
3. connect to server(s) and join channel(s)
4. listen incoming data, parse it into parts as IRC protocol specifies: <prefix><command><params>
5. Check if there's matching event
6. check if originating user has power to execute callback <this is my current problem>
7. execute callback.

I am also a bit uncertain how to handle connections to multible servers/channels. I am a bit tempted to end up multithreading here, but I hope I can survive without doing that. In my experience multithreading tends to cause more problems than it solves. (Ok, I have given up so much, that callbacks will be executed in own threads. I do not want to halt whole bot if user registers a slow callback ).

So here are my basic ideas. All suggestions are welcome!
Especially all tips on how to solve the user identification problem in not so messy way.