Fosscon 2010 Free and Open Source Software Conference.

While talking online is great, meeting in person presents brand new opportunities… and we would like to meet you!

In 4 days (on June 19th, 2010), a number of us as well as members of the community in general will be meeting up for a conference in Rochester, NY, at Rochester Institute of Technology.  We are greatly looking forward to this awesome new opportunity.

Fosscon features 14 talks and 4 workshops. Below are just a few examples.

Free and Open in Education; More than just Software – Charles Profitt

Making the Most of Communities – Bryan Ostergaard

OpenStreetMap – Richard Weait

Linux in Business – Karlie Robinson

Resume Building Workshop with RIT’s Office of Co-Op and Placement

And many others, as well as Bird of a Feather sessions and an exhibition hall full of local users groups and interesting organizations.

We hope to see you there. Visit for more info or to sign up.

Group Registration Form verifications

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

freenode webchat changes

Webchat has always presented an interesting problem, mostly for the staff of various channels as well as the network itself, but indirectly for all our users as well.  All webchat connections come from the IP address of the webchat service.  This results in them having to be handled a little bit differently from other connections.

To begin with, there needs to be a way for network or channel staff to identify individual connections, as well as where they originated from.  The way this has previously been handled is by encoding the IP of the source (the IP someone uses to connect to the webchat) in hexadecimal form in the ident field of the user.  The webchat users are “cloaked” (that is, their real hostname, which would be that of the webchat server, is replaced) with a unique string identifying the connection.  This method allows channel staff to ban or quiet a webchat user via the unique connection string, or via the ident information.

While this works, it’s confusing to many. The unique connection string changes every time a user makes a new connection through webchat. Therefore, we’ve changed how we do the cloaking so IPs are shown in cloaks. This makes it much simpler for channel staff to see what is going on, and who is who. For now, this change only applies to those using the freenode webchat at The effect is to change a cloak of the form “gateway/web/freenode/x-iiqzrxiqfnnglqji” to the form “gateway/web/freenode/ip.“.

We would like to point out that this does not in any way reduce the privacy of users of webchat: it has always been possible for anyone to directly convert the encoded ident string back to an IP address. In addition, the real hostnames of clients have always been visible unencoded in the “whois” output for the user.

In addition, we have made a small but potentially significant change to how the “ident” is shown. This has become necessary so that, with future versions of our ircd, we can properly limit connections per IP address via webchat. For a typical freenode webchat user, the full hostmask previously had the form “~abcdef1@gateway/web/freenode/...“. Many historical webchat bans and quiets are set as “*!~abcdef1@gateway/web/freenode/*“. The change that we are making will break these bans. We have removed the ~ from the ident for all webchat connections (not just freenode’s webchat), giving a full mask of the form “abcdef1@gateway/web/freenode/ip.“.

As such, channel ops are advised to adjust their bans into the form of either “*!abcdef1@gateway/web/freenode/*” or “*!*@gateway/web/freenode/ip.” as soon as possible.

A further result of this change is that those hosts from which a large number of legitimate users connect to freenode through the webchat service may suffer refused connections due to breaching the limits. If you find youself faced by an error of the form “Too many connections”, please email iline at freenode dot net with details of the IP address affected (which can be obtained from, the name of the organisation, and the number of connections expected, so that we can place a limit exemption. Please note that if you have a message of the form “Gateway connections are currently blocked” or “Gateway connections are currently being throttled”, this is a different matter for which an I:line cannot help.

We hope that these changes make connections through the freenode webchat easier to manage for channel ops and more transparent for all users.