Capacités

Introduction

Ok, il est temps d’expliquer le fonctionnement du système de capacités. Pour la plupart des bots IRC (y compris certains que j’ai moi-même écrits avant celui), « ce qu’un-e utilisateur-trice peut faire » peut être défini de deux façons différentes. Pour les bots très simples, chacun-e a un « niveau » et les commandes vérifies si le niveau d’un-e utilisateur-trice est assez élevé pour effectuer telle ou telle opération. Pour les bots légèrement plus évolués, les utilisateurs-trices ont une liste de « flags » (drapeaux, étiquettes) dont la signifie est intégrée au bot, qui vérifie que la personne qui veut effectuer une opération les a. Les deux méthodes sont, à mon avis, assez arbitraires, et forcent les utilisateurs-trices et développeurs-euses à être inutilement forcé-es à utiliser des constructions peu expressives.

Ce bot est différent. Chaque utilisateur-trice a un ensemble de « capacités », qui est consulté à chaque fois qu’iel envoie une commande au bot. Les commandes, plutôt que de vérifier qu’iel a un niveau de 100, ou vérifier qu’iel a le flag « o », sont capables de vérifier qu’iel a la capacité « owner ». Pour le moment, une telle différence ne semble pas révolutionnaire, mais on peut déjà constater que cette méthode est plus explicite, et plus facile pour les personnes qui s’en servent et développent pour comprendre ce qu’il se passe vraiment.

Capacité utilisateur-trice

Que permettent donc les capacités de faire ?

Si c’était tout, eh bien, le système de capacités serait cool, mais peu de gens diraient génial. Mais il est génial ! Plusieurs choses arrivent derrière le décors pour que ça soit génial, et ce sont des choses qui n’arrivent pas avec les bots qui utilisent des niveaux numériques ou des flags d’un seul caractère. Premièrement, quand quelqu’un envoie une commande au bot, le dispatcher de commande vérifie qu’iel n’a pas l’« anticapacité » pour cete commande. Une anticapacité est une capacité qui, plutôt que de dire ce que quelqu’un peut faire, dit ce que cette personne ne peut pas faire. Elle est formée simplement en ajoutant un tirer (« - ») au début du nom de la capacité : « rot13 » est une capacité, « -rot13 » est une anticapacité.

Bref, quand quelqu’un envoie une commande au bot, par exemple « calc » ou « help », le bot vérifie d’apport qu’iel n’a pas les anticapacités « -calc » ou « -help » avant même de songer à lui réponse. Donc les commandes peuvent être activées ou désactivées pour chaque personne, permettant un contrôle fin, qui n’est pas souvent (voire jamais) possible avec d’autres bots. Cela peut être raffiné encore plus en limitant les (anti)capacités à une commande d’un plugin en particulier, ou à tout un plugin. Par exemple, la commande rot13 est dans le plugin Filter. Si quelqu’un devrait pouvoir utilisr la commande rot13 d’un autre plugin, mais pas celle du plugin Format, iel aurait seulement besoin de recevoir l’anticapacité « -Format.rot13 ». Similairement, si quelqu’un doit se faire bannir du plugin Filter, il suffit de lui donner l’anticapacité « -Filter ».

Channel Capabilities

What if #linux wants completely different capabilities from #windows?

But that’s not all! The capabilities system also supports channel capabilities, which are capabilities that only apply to a specific channel; they’re of the form “#channel,capability”. Whenever a user issues a command to the bot in a channel, the command dispatcher also checks to make sure the user doesn’t have the anticapability for that command in that channel, and if the user does, the bot won’t respond to the user in the channel. Thus now, in addition to having the ability to turn individual commands on or off for an individual user, we can now turn commands on or off for an individual user on an individual channel!

So when a user “foo” sends a command “bar” to the bot on channel “#baz”, first the bot checks to see if the user has the anticapability for the command by itself, “-bar”. If so, it errors right then and there, telling the user that he lacks the “bar” capability. If the user doesn’t have that anticapability, then the bot checks to see if the user issued the command over a channel, and if so, checks to see if the user has the antichannelcapability for that command, “#baz,-bar”. If so, again, it tells the user that they lack the “bar” capability. If neither of these anticapabilities are present, then the bot just responds to the user like normal.

Default Capabilities

So what capabilities am I dealing with already?

There are several default capabilities the bot uses. The most important of these is the “owner” capability. This capability allows the person having it to use any command. It’s best to keep this capability reserved to people who actually have access to the shell the bot is running on. It’s so important, in fact, that the bot will not allow you to add it with a command–you’ll have you edit the users file directly to give it to someone.

There is also the “admin” capability for non-owners that are highly trusted to administer the bot appropriately. They can do things such as change the bot’s nick, cause the bot to ignore a given user, make the bot join or part channels, etc. They generally cannot do administration related to channels, which is reserved for people with the next capability.

People who are to administer channels with the bot should have the “#channel,op” capability–whatever channel they are to administrate, they should have that channel capability for “op”. For example, since I want inkedmn to be an administrator in #supybot, I’ll give them the “#supybot,op” capability. This is in addition to their “admin” capability, since the “admin” capability doesn’t give the person having it control over channels. “#channel,op” is used for such things as giving/receiving ops, kickbanning people, lobotomizing the bot, ignoring users in the channel, and managing the channel capabilities. The “#channel,op” capability is also basically the equivalent of the “owner” capability for capabilities involving #channel–basically anyone with the #channel,op capability is considered to have all positive capabilities and no negative capabilities for #channel.

One other globally important capability exists: “trusted”. This is a command that basically says « This user can be trusted not to try and crash the bot. » It allows users to call commands like “icalc” in the “Math” plugin, which can cause the bot to begin a calculation that could potentially never return (a calculation like “10**10**10**10”). Another command that requires the “trusted” capability is the “re” command in the “Utilities” plugin, which (due to the regular expression implementation in Python (and any other language that uses NFA regular expressions, like Perl or Ruby or Lua or …) which can allow a regular expression to take exponential time to process). Consider what would happen if someone gave the bot the command “re [format join «  » s/./ [dict go] /] [dict go]” It would basically replace every character in the output of “dict go” (14,896 characters!) with the entire output of “dict go”, resulting in 221MB of memory allocated! And that’s not even the worst example!

Managing capabilities

Capacité utilisateur-trice

User capabilities are controlled with the admin capability <add|remove> and channel capability <add|remove>. Their difference is that the first one is only restricted to those who have the admin capability.

To make user1 admin, I would run:

admin capability add user1 admin

If the bot joins on a channel where there should be ops who should’t have power over any other channel, I would run:

channel capability add #channel user2 op

Note that admins cannot give anyone capability which they don’t have by themselves first, so user1 couldn’t use channel capability add unless they were made #channel,op first. The command:

admin capability add user2 #channel,op

has the same effect as channel capability add, but it requires user to have the admin capability in addition to #channel,op.

If there is abusive user who shouldn’t have op capability but still does for one reason or another, I could run either:

channel capability add user3 -op

or:

channel capability remove user3 op

Anticapabilities are checked before normal capabilities so the first command would work even if user3 still had the op capability. Removing capability which isn’t given to user or channel adds anti-capability automatically.

User capabilities can be viewed with user capabilities command.

Channel

Channel capabilities affect everyone on the current channel including unidentified users. They are controlled with the channel capability <set|unset> commands.

If I wanted to make everyone on the channel able to voice themselves or get automatically voiced by the AutoMode plugin, I would start by unsetting the default anticapability and setting the capability.:

channel capability unset -voice
channel capability set voice

Now anyone on the channel can voice themselves or if AutoMode plugin is configured to voice voiced people, the will automatically get voiced on join.

If there was unwanted plugin or plugin which output was causing spam, Games for example, I could add anticapability for it and prevent the whole plugin from being used.:

channel capability set -Games

Note that I didn’t specify any separate command after Games.

Default

Default capabilities affect everyone whether they are identified or not. They are controlled by the owner defaultcapability <add|remove> command and they arecommonly used for preventing users from adding/removing akas, using Unix Progstats which disabling is asked about in supybot-wizard or registering to the bot using anticapabilities.:

defaultcapability add -aka.add
defaultcapability add -aka.remove
defaultcapability add -user.register
defaultcapability add -unix.progstats

To undo this I would simply do the opposite.:

defaultcapability remove -aka.add
defaultcapability remove -aka.remove
defaultcapability remove -user.register
defaultcapability remove -unix.progstats

Defaultcapabilities can be restored with two commands from the First is only in Limnoria at the time of writing:

config setdefault capabilities
config capabilities [config default capabilities]

Final Word

From a programmer’s perspective, capabilties are flexible and easy to use. Any command can check if a user has any capability, even ones not thought of when the bot was originally written. Plugins can easily add their own capabilities–it’s as easy as just checking for a capability and documenting somewhere that a user needs that capability to do something.

From an user’s perspective, capabilities remove a lot of the mystery and esotery of bot control, in addition to giving a bot owner absolutely finegrained control over what users are allowed to do with the bot. Additionally, defaults can be set by the bot owner for both individual channels and for the bot as a whole, letting an end-user set the policy they want the bot to follow for users that haven’t yet registered in their user database. It’s really a revolution!