New Services: Nicknames and Accounts

We’ve noticed a lot of people who are confused (and rightly so!) about the new nickname system – particularly the way that nickname grouping has changed. Hopefully this blog post will clear some of it up.

Nicknames and Accounts

freenode now uses a system of ownership that is different to the old nicknames system. Now, when you register a nickname for the first time, that nickname becomes the primary nickname on your account (which has the same name). An example:

User1 vists Freenode for the first time. She registers by using the command:

/msg NickServ REGISTER myshinypass [email protected]

User1 now has an account. freenode services have automatically assigned the nickname User1 to the account User1. User1 is now happy.

So, nicknames are now assigned to your account. But what does this actually mean, practically?

Identification

When you identify:

 /msg NickServ IDENTIFY <password>

freenode services will try and identify you to your account.  It does this by taking your nickname, and looking it up in the database – to find the account associated with it. Let’s go back to User1 for a little demonstration:

User1 returns to freenode. She identifies using the command:

  /msg NickServ IDENTIFY myshinypass

freenode services finds an account (User1) with the same nickname as her (User1), and so identifies her succesfully.

But what happens when you try and identify with a different nickname?

User1 connects to freenode, but her client decides to connect with the nickname User12. She tries to identify using the command:

  /msg NickServ IDENTIFY myshinypass

freenode services tries to look up an account called User12 (as this is her current nickname). This nickname is unregistered, and so does not have an account associated with it. The identification fails, and she is not logged in.

With the new accounts system, there is a command that allows you to identify to your account from any nickname!

User1 connects to freenode, but her client decides to connect with the nickname User12. She can identify using the command:

/msg NickServ IDENTIFY User1 myshinypass

freenode services will now look for an account named User1, and log her into that. Since she already registered this, the identification succeeds.

However, this isn’t ideal, as she is now logged in, but is using an unregistered nickname. She may want to consider GROUPing the nickname.

Grouping

With the new system, GROUP basically means to add another nickname to your account. User1 is fed up of being connected as User12 and using an unregistered nickname, so she has decided to GROUP the nickname to her existing account.

There are two ways to go about this:

User1 connects to freenode, but her client decides to connect with the nickname User12. She can identify using the command:

/msg NickServ IDENTIFY User1 myshinypass

freenode services will now look for an account named User1, and log her into that. Since she already registered this, the identification succeeds. She can now GROUP the nickname (User12) to her account (User1) by typing:

/msg NickServ GROUP

The command takes the current nickname, and adds it to the currently logged in account. She can now, in the future, identify using the command:

/msg NickServ IDENTIFY myshinypass

when connected as User12.

Or, she can do this:

User1 connects to freenode. She identifies using the command:

  /msg NickServ IDENTIFY myshinypass

freenode services finds an account (User1) with the same nickname as her (User1), and so identifies her succesfully. She can now change her nickname:

/nick User12

And GROUP her new nickname, as freenode services does not log her out of her account when she changes nickname.

/msg NickServ GROUP

The command takes the current nickname, and adds it to the currently logged in account. She can now, in the future, identify using the command:

/msg NickServ IDENTIFY myshinypass

when connected as User12.

Conclusion

So, to wrap up, freenode now allows you to register an account, to which you add nicknames as explained above. That’s not an easy concept to grasp if you are used to the old system, and if you have any questions, feel free to drop into #freenode and ask away!

Services Migration

The time has come for freenode to migrate from our old, legacy services package to a much newer, actively maintained package known as Atheme, developed by the Atheme Project. Although we, with the help of the Atheme developers, have tried to make the migration process as painless as possible, there are still a few interface differences that you will need to be aware of. This guide, prepared by tomaw, will attempt to walk you through the main changes, grouped by service.

NickServ

  • NickServ will now require a valid, verified email address to register new nicks. Because of this the registration command has changed to
    /msg NickServ REGISTER <password> <email address>

    You will the receive a confirmation email with instructions on how to confirm your account registration. Accounts that have been migrated from theia that did not have an email address set will find that their address is set to ‘nomail’. These users should set an email address as soon as possible.

  • New NickServ accounts that are registered but not confirmed will be automatically dropped after 24 hours.
  • What was Nick Linking has now been replaced with Nick Grouping. This means that you have just one account (including one password, one email address etc.) but potentially multiple Nicks associated with that account. For more information please issue the following command:
    /msg NickServ HELP GROUP

    Migrated accounts will have the password associated to the master nick, but will have the first valid email address found when searching all linked nicks.

  • SET UNFILTERED has been removed and the global block on messages from users that have not identified to NickServ has been removed. This was only ever intended to be a temporary measure to combat spam and we’re hopeful that we can deal with those events in different, less intrusive ways. UMODE +E remains an alternative for any users who wish to block such messages.
  • SET GSM, PHONE, and the like have been removed and replaced with a SET PROPERTY feature. For more information, see:
    /msg NickServ HELP SET PROPERTY
  • INFO will no long return a list of channels where you have access. Instead use:
    /msg NickServ LISTCHANS
  • A new SET ENFORCE feature replaces the un-used SET KILL feature. For details, see
    /msg NickServ HELP SET ENFORCE

ChanServ

  • Channel access is now controlled by a series of flags, rather than levels. This will allow channel owners and Group Contacts to better control the access they grant users, and to see more clearly what access those users will have. Channel Access now also includes a powerful templating system, making it easier to manage large and complicated access lists. For more information on these features, please see:
    /msg ChanServ HELP FLAGS
    /msg ChanServ HELP TEMPLATE
    /msg ChanServ HELP ACCESS
  • Channel access can now be manipulated using two different commands.
    /msg ChanServ ACCESS #channel

    behaves similarly to our previous services, but the standard Atheme command is to use

    /msg ChanServ FLAGS

    Note that viewing FLAGS requires you to have flag +A on the channel in question, but ACCESS does not. This can be useful if you’re trying to locate channel operators.

  • ChanServ can no longer be used to OP or VOICE multiple users, though it is still possibly to OP/VOICE individual users:
    /msg ChanServ OP #channel nick
  • A new RECOVER command is now available, which can be used by the founder to regain control of a channel which has been “taken over”.
  • Channel passwords are no longer used for registration as all channel access is control by the access flags.
  • LIST *pattern* has been replaced by a new service called ALIS. See below for details.

ALIS

  • ALIS provides a more useful channel list facility than what was previously available. It will list matching channels, but will filter out channels that are not currently in use. Its use is similar to the functionality that was previously built into ChanServ:
    /msg ALIS LIST #freenode-*

MemoServ

  • Memos can now be replied to and forwarded to other users
  • Optional email forwarding to your registered email address. To enable this feature, issue the following command:
    /msg NickServ SET EMAILMEMOS ON

Hopefully that covers most of the differences that you will come across during day to day life on freenode. Of course, if you have any questions, suggestions or comments, please feel free to drop by #freenode, email support (at) freenode (dot) net or message a member of staff.