For a long time, freenode has utilised a Group Registration system to give groups (such as companies and open source projects) the ability to manage channels in the primary namespace (ie, channels beginning with a single “#”) and to give contributors to their projects cloaks. Perhaps more importantly, the system allows groups to retain control of their identity on freenode. It is because of this aspect of Group Registration that filing a Group Registration Form (GRF) has been necessary for projects to acquire primary channels which have been already registered. For the same reason, we ask those who register new primary channels to file a form.
A great number of fantastic projects use freenode. Only a small subset of staff are able to handle GRFs, and in combination with the large volume of forms filed we have developed a significant backlog. We realise that because of this backlog, certain groups are unable to claim channels on freenode which should rightfully be theirs. While we appreciate that many projects have been waiting months or years for a form to be processed, we must consider GRFs filed in order to obtain channel ownership for a legitimate project to be a priority – if you’re in the former position and not the latter, I hope you can see why.
At this stage, we are hoping to move through these priority requests in the coming weeks (and, depending on volume, months), before moving on to other requests. If you are a prospective group contact who has filed a GRF form before and you fall into the priority group (to be clear: you are in the priority group only if you need the GRF to be processed in order for you to gain access to the #group or #project channel on freenode), please email us at grfprocess at freenode dot net. The email should contain your IRC nick and your group’s name – no other personal information should be sent. We will soon be in touch regarding “next steps”.
If you want to help us to provide a top class service to groups, please consider getting involved with development of our new Group Management System (GMS).
Finally, a quick word of gratitude to those who have been waiting for GRFs to be filed for a long period of time. Thank you for your patience – we will move on to processing your requests as soon as we are able, and will let you know when via this blog and network wallops. Thanks for choosing freenode
For many years now, freenode has offered projects and userbases on the network the option of registering themselves as “Groups”. Each of these groups has one or more designated people as their “Group Contacts”, who are the point of contact for freenode-staff<=>group liasion, and are thus able to contact staff to request that cloaks be set, or to request assistance in administering channels.
We now have several hundred registered groups on freenode, and many more groups for which registration requests have been submitted. There is a rather large backlog of these requests, but this will reduce dramatically once GMS has been completed, tested, and deployed (on which note, if you think you can give some time to help code it, get in touch!). An aim of the groups policy is to foster good relationships between groups and staff.
This is where the Groups Advisory Board (GAB) comes in – immediately, for approved GCs! This is a way in which we would like to give groups a role in influencing the direction that freenode, and the PDPC, will follow in the future with regards to group and project related policy. The GAB is completely optional and brings with it no committment. It is open to all group contacts who would like to be members. The GAB is effectively a consultation forum where staff can get feedback from groups. As well as improptu discussions on IRC, discussions will take place on a mailing list and occasional, optional IRC meetings will be arranged. If you’re interested in giving your group a greater voice in the management of freenode, speak to staff in #freenode, or drop an email to support NOSPAM at freenode.net, and we’ll sign you up to the freenode-groups mailing list and invite you to #freenode-gab.
With our change of ircd to the all new ircd-seven, we are trialling a new method of allowing users to connect to the network via Tor. This method brings a number of changes:
- The only Tor hidden service is: the new p4fsi4ockecnea7l.onion.
- You will need to have a registered and verified NickServ account to connect using Tor. Beyond this, no further steps are necessary.
- You will need to use a SASL mechanism to identify to the server.
We have collected together scripts for irssi and mirc, while Conspire supports SASL natively. Scripts may be available for other clients in addition.
Download and install this script (cap_sasl.pl) and, after loading it, configure it using
/sasl set <network> <username> <password> <mechanism>
Supported mechanisms are PLAIN and DH-BLOWFISH.
A mirc script is available, taken from a forum post by Kyle Travaglini. You can retrieve the source here.
Instructions (adapted from that forum):
- Place SASL.dll and sasl.mrc into your $mircdir.
- Load sasl.mrc into your remotes.
- Press F2 and configure the network, before connecting as usual.
If you have any problems, either pop into #freenode from a non-torified connection or drop an email to support AT freenode.net.
This method of connecting to freenode using Tor supersedes all previous methods, including Tor-GPG. We hope that this method of connecting via Tor will help to make it somewhat more accessible to you!
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!
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.
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.