This section describes what a bot maintainer can do with users. Adding, deleting, changing, fixing so that they are treated correctly by the bot and to the benefit of the channel the bot is visiting.
The vocabulary used here is as follows:
Registered users. They're recognized by the bot when they join and they have different status levels, flags and privileges.
Persons joined in the channel.
Registered users have a set of data stored that is connected to the particular user. That data include:
No user is recognized until he or she is added. There is only one single command that adds users: USERADD, and you can only add the user once. If the user is on-channel when you add him/her, the bot will try to inform the newly added user.
The simplest and most commonly used format of this command is
If the guest foobar should get added as a level 20 users, we just enter
USERADD <nick> <level> [email]
To do the same, but include the user's email address too
USERADD foobar 20
In some situations, we want to alter details in the data that is about to get stored for the user. Then we can specify a few options that does it for us. For example, if foobar isn't joined when we want to add him, the bot can't possibly know what hostpattern to add for the user and we have to specify that manually. Then we could do it like
USERADD foobar 20 firstname.lastname@example.org
(Specifying the hostpattern can be useful even if the user is joined if the bot hasn't picked a perfect pattern as viewed with "
USERADD -p foo@*unsigned.int foobar 20
If you want to register the user with a certain nick, which he isn't using when you add him, for example he is using foobar2 instead of foobar, use the -R option like this
Adding a user that is joined, but preventing the bot to inform him, can be done with -Q like
USERADD -r foobar foobar2 20
Of course, all or any of the flags can be combined as in
USERADD -q foobar 20
USERADD -q -n mypasswd -p foo@*unsigned.int -r Newbie foobar 20 email@example.com
You wanted to add a user that is not currently joined without specifying a hostpattern. The bot cannot possibly know how to match the user without that knowledge.
The registered nick has to be unique. Most often this error occurs when the user actually already is added properly, just not matching any of the hostpatterns as he is joined now. If that is the case, add the pattern to the userdata instead (see USERMOD -p).
Despite what you think or what the user says, this user is already added. This may be because this user matches a hostpattern of an already registered user. If that is the case, you should make sure that hostpattern gets narrowed.
The added hostpattern was seriously wrong. A hostpattern should be in one of the two formats
For our imaginary user, normally using the nick foobar, the pattern could be like "
foo*!foo@*unsigned.int" or if you don't want the nick to matter, pick a pattern like "
Users are humans (yes, that's true). They change accounts, they disappear, they show up, they behave, they go bananas or they remain the same. To change any(*) of the registered user's data fields, use the USERMOD command.
The basic syntax of this command is USERMOD
When the user shows up in the channel with a new hostpattern that is not previously added to the user (and thus the user isn't recognized by the bot) you can add a new pattern to the user in a few different ways. Specify the complete new pattern as in
USERMOD foobar 50
or add the currently used pattern to the registered user with that same nick
USERMOD -p foo@*short.int foobar
(this can be done by the user itself by using the IDENT command as described further down) or you can "steal" the pattern from a user in the channel and add that pattern to the registered user. If the user shows up with a nick different to the one that he is registered as (foobar_ in this example), and you want to add the user's current hostpattern to the user's list of patterns, you can use it like
USERMOD -p - foobar
If you added a bad pattern to the user, or if the user has hostpatterns he will without doubt not use anymore, you can delete one from a user like
USERMOD -p foobar_ foobar
or if you have done a "
USERMOD -d foo@*.unsigned.int foobar
SVIEW -A" previously and remember the number of the pattern you want to remove (2 in our example), you can write it like
Further, you can change the email field for the user like
USERMOD -d 2 foobar
You can change the registered nick name like
USERMOD -e firstname.lastname@example.org foobar
To alter the flags of a user, you use the -F option. You should specify the flags to add preceded with a '+' and the flags to remove preceded with a '-'. The existing flags(*2) at this point are
USERMOD -r foobie foobar
Prevent a joined user from getting information about the change by using the -Q option like
USERMOD -f +a-b foobar
Remember that "
USERMOD -q foobar 50
SVIEW -A" is a very good command to use to view any user's data.
(*) Exceptions are the comment field which is set by the user itself with the COMMENT command and the password which can be reset to 'pass' for a specified user with the DEFPASS command.
(*2) There is in fact a 'DELETE' flag too, that is not possible to add nor to remove with the USERMOD command. Read further about the USERDEL command for more info.
Sometimes a registered user quits visiting IRC or just your channel. Instead of keeping the users entry in the database present forever (which could lead to an extensive amount of never-joining users) there is a USERDEL command. Write a command like
to delete the registered user named foobar. If there is a user joined using the registered nick without actually being the user with that nick registered, you can specify that you want this to affect the registered nick's user with
Deleting a user DOES NOT mean that the user will be erased from the userlist immediately. The user will instead get marked with the DELETE flag and if the user isn't changed the following month (meaning that if there is a one month old or older DELETE-flag) the user will no longer get saved in the userfile. Thus, at next restart the user won't exist. This allows the undo option, that can be used in case you change your mind before the user is actually erased
USERDEL -r foobar
Like the other user-commands, this will tell the affected user unless the -Q (quiet) option is used as in
USERDEL -u foobar
USERDEL -q foobar
All registered users have passwords. By default, all initial users have 'pass' as password (can be specified with the 'USERADD -n' command though). Passwords are stored encrypted and cannot be reverse engineered. Passwords are never shown in spylinks or in logfiles. Alas, nobody but the user himself knows what sequence of letters that creates his encrypted password.
A user identifies himself with the
command, or can get the bot to make him chanop at the same time (if the
user has sufficient status) by entering
A new password is set with
"NEWPASS <password>" but of
course the old password has to be entered accordingly first.
All users should set their own passwords as soon as possible. Keeping the default password is considered very insecure! The IDENT command will even reject users that try it with the default password!
DEFPASS is the only command that can change another user's password. It re-installs the default password for the specified user.
NOTE: If the SVIEW output includes the word 'Confirmed', the user has successfully entered his passwords and is considered identified.
The seen data has nothing to do with the userdata. They are two completely different systems and stored users may very well not be found by a seen command and vice versa.
User hostpatterns are tricky business. The hostpatterns listed for a single
The hostpatterns listed for a user are compared against the user regardless
of the ircd-server prefixes (known to this date) like ~, -, + etc. So,
adding a pattern like "
~foo@*unsigned.int" to a user
still matches the user joining as "
as well as "
+email@example.com" and similar.
The hostpattern can optionally contain a nick match too, like if the previous
user always used a nick starting with "
foo", the hostpattern
could be written like "
A user can (if IDENTPROTECT is off) add it's current userdomain pattern to its list of host patterns by using the IDENT command. It is typically used when the user joins from an account not recognized by the bot. The user then enters the command
Another pattern that should not be confused with the hostpatterns is the
userdomain pattern that the bot constructs when a user joins. That pattern is
what the bot considers is a good string to match that particular person. The
userdomain is used i.e when the bot bans the person or if the person is added
to the warnlist. That pattern is also used as default hostpattern in case the
user is added (with USERADD) or get its current pattern added (with "
USERMOD -p -"). This is the pattern that is viewed on the first
line of an sview output.
Some hosts are what we refer to as host-only ISPs (short for Internet Service
Providers). When the bot is about to create a userdomain pattern for a user
from such a host, the machine name will be kept and the username will be '*'
and if the host from the example above was listed as 'hostisp' the userdomain
for a user like "
+firstname.lastname@example.org" would look like
*@static.unsigned.int". The bot will also do its best to
never siteban such a host.
Users that join with a userhost that looks like "
(with only one dot) get a pattern that looks like "
When banning a single user with the BAN command (as in
foobar"), the userdomain pattern of the user will be used when
creating the banpattern. That pattern will also be used in case the user
floods or is abusive in any other sense that makes the bot ban him.
Similarly to bans, the userdomain pattern (see details under Hostpatterns) is used as default warn-pattern when a user is added to the warnlist without specifying the pattern especially.
The comment field of a user is only settable by the user itself with the COMMENT command. The comment is displayed when 'sview'ing the person. It can also get displayed when the user joins, if the SET item named COMMENT is enabled.
The email field of a user is settable by the single user with the SETEMAIL command. The email field of other users is displayable with the EMAIL command. A high level user can change other users' email fields by using the USERMOD -E command.