Chat/Moderation Bot Interface Discussion

[Hazard]

Ok if I were to build an ops bot, would it be smart to include any kind of interface? Or would it be best to leave it plain and simple. The reason I'm asking is I'm not really sure if the interface can interfere with the bots operation in any way (i.e. speed or stability.) Any input will be appreciated. Programmers with experience in this field is who I am looking to hear from so if you aren't one please don't interfere in the thread.

!~!HaZaRD!~!

[Soul Taker]

My moderation bot has no intereface, it just sits in the tray and logs various things, such as errors and commands.  It's worked fine for many months.  However, I have seen moderation bots with minute interfaces that seem to do just as well.

[TheMinistered]

It does take precious time to draw/redraw that GUI...

[Grok]

A program often has conflicting objectives.  This is why we write requirements before starting design.  An ops bot most important job is to moderate the channel.  When making design decisions be sure to weigh your choice against that primary job.

You do need an interface, but it doesn't have to be graphical.  The interface is defined as that set of functionality for which the bots abilities are manipulated.  Thus, a bot like Ops [vL]'s ZeroBot, one interface is the BNCS users talking in the channel, or whispering commands directly.

ZeroBot doesn't talk much, hardly at all.  It's not important for keeping the channel moderated.  If you're designing an ops bot, I'd suggest doing the same.  If you let the bot respond to triggers, it can be flooded.  If you have it greet people entering the channel, again it can be flooded.  We've found it is best to have the bot simply ignore all unauthorized commands or interaction.

[Kp]

An interface of some kind if nice to have, even on an ops bot - at least during debugging.  Being able to have it dump out internal state information to the console as it performs operations is a quick way to see what's going wrong without halting it in a debugger.  However, unless you  plan on using it to chat (I would recommend against this), make the interface: 1) simple (i.e. console only) and 2) removable.  Then dismiss the console whenever you're not watching it for debug output.  If you're careful with how you do your output routine, it can do almost no work when the console is not present, thus providing a minimal speed hit.  If you really care about speed, compile the console out when you don't need it!

[Skywing]

I'd recommend adding the capability to run your program as a Windows NT service; those can be set to auto start when nobody's logged on and continue running in the background despite user logons and logouts - something which is just perfect for an automated channel moderator program.

[Hazard]

Would it improve the ability of the bot for moderation purposes to ignore all users not on the access list?

!~!HaZaRD!~!

[Kp]

Would it improve the ability of the bot for moderation purposes to ignore all users not on the access list?

!~!HaZaRD!~!

However, probably the answer is yes.  Generating any reaction to non-authorized users (other than banning users marked for autoban) makes the bot more susceptible to abuse.  If you really want it to respond to random users, I recommend an internal ruleset that prohibits such responses more often than once every few minutes.

[Hazard]

Can we get past the daunting task I know this whole thing is going to take a lot of work. Kp can you elaborate on this topic you were discussing? I see no reason to have my bot relate to users not in the database (those you lable as "random users") I was considering adding in commands that require no access to access but do you think this would be unwise?

[Edit] By the way thanks guys for the lessons of simplicity as it relates to relativity

!~HaZaRD!~!

[Hazard]

Tnx Grok my first Toast But my question still stands. Is it feesible to add commands that require no access to the bot yet still be a stable ops operator? Or might it be wiser to require to have for instance the Safelist flag/access number in order to access those commands?

[Edit] I am of course aiming for a very stable and effective channel moderation bot and this is one of the big problems I've come up with while planning what I want to do.

!~!HaZaRD!~!

[Soul Taker]

Maybe give some examples of what the purpose of the accessless commands is, since I can't think of any reason to have them at all.

[Hazard]

You know like finding the botmaster or the trigger. For convinence purposes.

!~!HaZaRD!~!

[Kp]

What happens when Mass(1)Bot through Mass(30)Bot join and your ops bot tries to say hello to all of them, or respond to them doing ".version" or whatever?  You get seriously backed up trying to handle a lot of junk traffic from someone who's just trying to screw up your client.  An attentive bot operator could clear the outbound queue to stop that, but what if it happens while all the bot's authorized operators are away and/or not paying attention?  That can be mostly mitigated if your bot has rules about not responding to unauthorized users more than once every few minutes, but it'd still be irritating to have the bot's queue getting tied up (even briefly) by disruptive people.  Depending on how inclined you are to give out minor levels of access, you could to that instead.

As an interesting aside, the bncs naming rules (which gave rise to so-called "illegals") actually help out bots to some degree.  For instance, you could set "[vL]*" to some pattern and know that only pre-existing [vL] accounts can match that, since no one can make an account that starts with [ anymore.  Of course, such wouldn't catch all [vL] since some prefer to have the tag at the end (or arrived after the rules changed).  Similar logic can be applied to any other clan which was around before the change.

Since Zerobot doesn't permit changing the trigger, we've had no need of a "?trigger" type command.  Further, we have a specific attribute which grants access to the query commands so you can look up operator/master/whatever.  By doing so, we allow members (and theoretically nonmembers,  though we almost never do that) to query the database without just making it world-readable.

[Hazard]

Thanks Kp excellent point on the massload idea. Also thanks for that reminder on the bncs naming regulations that I have to make sure to take that under consideration.

!~!HaZaRD!~!

[c0ol]

IMO the best way to do this is to keep all commands restricted, my bot has ?trigger but it requires access to the trigger command.  Also you really need to consider a priority queue, where some messages take precidence over others.  on 01 bans/ignores/designates are on the highest priority, then greetings and other junk is on a diffrent priority that is limited in size, so you can only have 3 messages queued up.