New servers

Hi all,

Over the past couple of months we’ve been fortunate enough to be able to add a couple of new servers to freenode’s rotation. Namely, lindbohm (IPv6: denis) and hubbard, sponsored by Stockholm University and Carnegie Mellon University Computer Club, respectively. Thanks to all of our sponsors for keeping the network online.

If you’re interested in sponsoring a server for freenode, take please take a look at our website to see what the process entails and don’t hesitate to ask me (Martinp23) or christel for any further information at all.

Thanks for using freenode! :)

Help us test ircd-seven!

As many of you will have noticed, our current IRC server software, hyperion, has been showing its age for some time now. Expectations for its eventual replacement are nothing if not high — hyperion contains a great many features not found elsewhere, most of which are fairly unique to the way in which freenode operates, so anything that wants to take over from it must provide all of these, in a more robust, maintainable and future-proof package.

Charybdis looks like a good start — it’s a modern, modular IRC daemon supporting many of hyperion’s strange features, and built on top of ircd-ratbox, which gives it a good heritage of stability and scalability. ircd-ratbox is perhaps best known for powering the majority of EFNet, which seems to make it an excellent base on which to build.

However, neither ratbox nor Charybdis implements freenode’s more unique features, such as ban-forwarding or hidden IRC operators. So, some work is needed.

Enter ircd-seven. Seven is based on Charybdis, with the features freenode needs added in. Channel operators and network operators alike should recognise most of the useful, and heretofore unique, features of hyperion, without many of the bugs and oddities that have become an unfortunate fact of life.

Development and internal testing of seven has been ongoing for some time, and we’re now ready to open up testing to a wider audience. The test network is currently running on, port 9002 for normal connections or 9003 for SSL connections. This is a new server, sharing no code with the current software, so all aspects of it need thorough testing, both that it works, and behaves in a way consistent with how most people want to use it — this last aspect is particularly difficult to do in small-scale private testing.

ircd-seven is designed to be capable of everything hyperion is, but not necessarily as a drop-in replacement. Some functionality is still available in a different form, or with a different interface. The most notable differences for users are summarised below:

SSL support
seven supports SSL, for client and server connections. Users connecting via SSL will get user mode +Z to denote this.

Channel bans and quiets
Channel mode +q (quiet) is now sent as a separate mode — hyperion’s translation of +q foo to +b %foo is gone. Extended ban types are supported for all ban-like modes (+bqeI). These extended masks begin with $, followed by an optional ~, to negate the match, and a single letter denoting the type of match to do. For example:

  • +b $r:Lee* will ban any client whose realname (gecos) field begins ‘Lee’. This is equivalent to hyperion’s +d mode.
  • +I $a:spb will set an invite exception for any client logged in to services as spb.
  • +q $~a will prevent any user not logged in to services from speaking. This is roughly equivalent to hyperion’s mode +R.

Forward channels for bans are now delimited with $ instead of hyperion’s !, and can be used with extended ban masks as well. Setting and unsetting of bans via the hyperion syntax (nick!user@host!#channel) is supported — it will be translated to nick!user@host$#channel.

Identified status
There is no user mode +e. The IRCd keeps track of the account name of every user who is identified to services, and uses this to determine whether a user is identified or not. The ‘is identified to services’ line in WHOIS output is no longer present; there is, however, a line containing the account name if the user is logged in.

Identifying on connect
Using a NickServ password as a server password still works as it does in hyperion. However, there are two new mechanisms:

  • You can specify : in the server password field, to log in to a specific account. This removes the requirement to connect using a nickname that is grouped to your services account.
  • seven supports SASL authentication, to log in to services during the connection process. This requires client support; a script for Irssi to do so is located here. Conspire supports this natively. Other clients, as far as I’m aware, do not.

Username prefixes
The n= and i= prefixes are not used; instead ~ is prefixed to a non-identd username, as in most other daemons.

The identify-msg capability is still present, but the way to enable it has changed — it is now part of the same CAP mechanism that is used to control SASL and multi-prefix capabilities. A script for irssi that understands both hyperion’s and seven’s identify-msg capability is available here. Conspire will also support this natively once w00t remembers to apply the patch.

[Maintenance] Downtime warning — lem, orwell

Hi all,

Tomorrow evening, November 3rd 2008, at 22:00GMT we will be undertaking some routine maintenance on two of our client servers, lem and orwell, both servers have already been taken out of rotation. The downtime window is set to one (1) hour, but we anticipate that the upgrades will take less time. At time of posting we have approximately 2,000 users across the two servers, and while we will urge users to connect to a different server prior to the upgrades we realise that not everyone will be able to act on the notice in time and as such we expect to see some disturbances on the network at the time of the upgrade.

Thank you for using freenode!

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?


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.


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.


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 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


  • 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 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-*


  • 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.

Communicating with the irc Community

For most of my professional career, I worked in the international arena. I’m not sure why I have always enjoyed that so much – perhaps as a result of having lived overseas for a portion of my life. There are, as a result, a lot of things that I take for granted in dealing with others, and I’ve recently become more aware that others often don’t think or don’t realize there is a bit of an art to dealing with folks from other cultures, countries, backgrounds and who speak other languages. On irc, there are so many different people, languages, cultures, it’s important to realize the need to do things a bit differently than we normally would, even though many of the traditional issues that arise when you’re face-to-face don’t exist.

The most obvious example is, even though the vast majority of us communicate on irc in English, a good number speak a different native language. This can cause all sorts of interesting (and sometimes humorous) miscommunications. Regardless of your native language, below is listed a few things that might help you to communicate more clearly with others.

To avoid causing miscommunication:

  • try speaking in full, clear, concise sentences. Due to the nature of irc and the speed with which some time, it’s often tempting to write quickly, abbreviating, using acronyms and partial sentences. However, this can be, and is often, confusing to a non-native speaker.
  • realize that “geek speak” is confusing enough for less technical native speakers and can be impossible to decipher for non-native speakers (even if they are technically inclined)
  • remember that not all irc clients use the same commands. This is especially important if providing assistance to another user. For example, some clients will accept “/cs” for “/msg chanserv”; some will not.

To avoid misunderstanding others:

  • if you don’t understand another person, ask them to state what they said in another way. Often if they repeat themselves with different words, formatting, etc., you can decipher what they want/need/said.
  • assume the best possible meaning. Sometimes someone will say something, that might seem harsh or offensive – realize that it may be that the person simply doesn’t know the words (or syntax) to state what he/she means.
  • look at the context. By looking at the channel you are in, or the topic that was discussed when the other person started speaking, you might be able to glean what the person intended.

Finally, there are a lot of resources on freenode – many people are more than willing to translate when necessary. Ask what language the person speaks, and then try to find another who speaks the language. If all else fails, come to #freenode and ask for help or message a staffer (“/stats p” lists all staffers on duty).

The fact is, irc is a fantastic way to get to know other people and to learn more about other cultures – and at a great price! I challenge and encourage each of you to up your level of communication.

Silence is Golden: Handling trolls and spammers

The Issue

Over the last few months, it’s occurred to me that many people aren’t quite sure how to react when a spammer or troll joins their channel. There is always a tendency to react, to do whatever is necessary to get someone’s attention to kick the spammer or troll. As a channel op, many of us face challenges in that even if we know how best to react, our peers on the channel tend to get riled up anyway. The result? The troll or spammer has done significant damage to the channel – disrupting “business” or conversations, changing the focus of discussions, etc.

First it’s important to understand what motivates most trolls/spammers. Simple: attention. They want your attention – whether it’s “good” or “bad” attention is unimportant. They simply want to change your focus from your customary topics to one thing: the spammer/troll. Consequently, reactions to trolls and spammers (other than a simple kick/ban, as may be necessary) tend to do one thing – encourage the troll/spammer to continue his/her behavior.

So what is to be done? There are really two groups of people to address at this point – channel operators (people who have the ability to kick/ban someone from the channel) and channel users. Since users vastly outnumber operators, I’ll address them first.

Channel Users

As a user of freenode, let me first say thanks! freenode is unique because of its users! We appreciate all of you and rarely get a chance to say so. So how can you help freenode and your favorite channels deal with the issue of spammers and trolls? The key is your reaction (or better, lack of a reaction). Since trolls and spammers are seeking to disrupt business and get your focus on them, the best thing you can do is NOT respond to them. Do not respond to their spam. Simple? It seems to be so – and in theory it is. In practice, it can be a bit harder – especially when a spamming or trolling attack is going on. Think “Catalyst“.

Here are a few ideas of how you might be able to express your frustration or communicate necessary information without encouraging the trolling or spamming behavior:

  • Take conversations to a private forum, channel or a private query message. This is true even if you’re trying to get the attention of someone who might be able to kick/ban the troll/spammer. Your lack of reaction on the channel is quite boring to the troll or spammer and will only make them lose interest more quickly.
  • Don’t discuss the situation for hours after the situation occurred. Many trolls have “legitimate” or alternate identities and will sit on a channel, not disrupting things, but watching the carnage they caused.
  • There are many ways for channel operators to address the issue of a troll or spammer, including changing the channel modes. If your favorite channel has suddenly gone +m (moderated) or to some other mode you’re not familiar with, don’t make a big deal of it. Ask one of the operators in a private message if you simply can’t stand to not know what happened. But again, keep it off the channel.

Channel Operators

As a channel operator, you have a tougher job when your channel is attacked by trolls or spammers. You have a responsibility to the channel to block/stop/end the attack, as well as keeping everyone else calm! Remember to catalyse throughout the process. Take heart – a little forward thinking will help a lot!

Dealing with the Troll or Spammer

There are a number of ways to deal with trolls and spammers. Of course, you have kick, ban and remove available to you. But you also have the ability to set some channel modes:

  • +r requires people to be identified with NickServ to join
  • +R requires people to be identified with NickServ to talk
  • +m moderates a channel, requiring +v to talk
  • +q is similar to a ban in that it won’t allow you to talk or to change nicks, but you are free to join the channel
  • +z will make ops (+o) able to see what a person that is neither +v nor +o says in a channel that is +m

Dealing with the Channel’s Reactions

First, remain calm. You set the tone for your users. If you get upset or excited, they will too. Secondly, you can help a lot by educating your users before any attacks occur. Let them know how trolls/spammers work and what they are seeking. Provide them with a clear understanding of what they should do and who they should contact in the event of an attack. Inevitably, people will react to some degree. Use the attack as an opportunity to educate – but do it in private; you want to keep reactions off channel and you also are more likely to be successful, avoiding embarassment by discussing the issue privately.

[Scheduled Maintenance] IRCD upgrade.

In order to upgrade our ircd code to fix various bugs and security issues, it has become necessary to restart a large portion of freenode network.

This morning, between 6:00 and 7:00AM UTC, we will be restarting numerous servers, including our network hubs. Approximately 35% of the network will be disconnected and the rest will notice significant fragmentation. We have planned the upgrades well in advance and with hope, the affected servers will only be down for a few minutes, at which point the network will return to normal operation.

We have already sent notices to users on the affected servers (i.e., those that will shunt clients). A list is also below. You may find which server you’re on by a WHOIS command on yourself (i.e., /whois nick)


Additionally, servers used for tor connections will shunt users.

We apologize for the inconvenience, and thank you for using freenode. Further questions can be directed to [email protected]

[Downtime] Unexpected downtime.

We would like to apologise to those of our users affected by the network downtime earlier tooday, November 2nd 2006. The network went down unexpectedly after one of our staffers accidentally found a bug in the IRCD code.
I’d also like to take this opportunity to suggest that you keep your eyes on this webpage as we will shortly be announcing some exciting changes and bringing you some great news!
Thank you for using freenode and have a great day.

Questions can as always be directed to [email protected], or feel free to /msg christel or LoRez on IRC.