Keeping tabs on channel bans

The channel ban, initiated with a mode change of +b, is perhaps one of the most recognised and well known features of IRC, dating back to the origins of the protocol. freenode has implemented a number of features that extend the basic nick!user@host mask format because we believe that the ‘kickban’ is outdated and there are better ways of dealing with disruptions to channel activity. On freenode you will find the quiet, where by replacing +b with +q you can stop a user from speaking in a channel but they can still read the contents of it. It has been found that this creates a more positive atmosphere in the channel that means better discussion can take place. There is also the realname ban, used via +d.

There is however a downside to the ease of banning users on freenode from channels and that is that it is easy to lose track of bans set in large channels. There is no feature to auto-expire bans in IRC and in a busy channel it doesn’t take long for a large list to build up. With multiple operators in a channel things can very quickly become confused and no-one seems to know why ban x was set and whether or not the user should now be unbanned. This leads to unhappy users and a channel that misses out on potential positive discussion. In addition, channels have a limit of fifty bans set at any one time and bans end up being shed arbitarily in order to set a new set for a new threat. This can lead to obvious problems.

This issue is made worse by the fact that +e, +I and +d lists also share the fifty slot limit. This means that if a channel has a large list of ban exceptions or invite exceptions, the number of bans that can be set in a channel is severely limited. In order to avoid having these problems in your channel, we encourage you to take care that bans are being set only when necessary (as bans are generally a Bad Thing) and also to take responsibility for your bans. By this I mean that when a ban no longer makes sense it should be removed.

It is recognised that in some channels these limits may be problematic regardless of how tidy the channel is kept and our server does have the ability to increase the limit. This can be granted by freenode staff but is done so on a case by case basis, and not frequently — doing so indiscriminately would not only encourage channel operators to overfill their banlists, but could eventually cause resource and performance issues on the servers — freenode currently has around 16000 channels active, so increasing the memory consumed by each banlist would have a dramatic effect. Channels that have a lot of stale bans are unlikely to be granted this flag. Keep tabs on your bans for a happier channel with happier users, and clear out your channel lists to speed things up for everyone!

I would also like to take this opportunity to mention that if you are organising a conference or other event that will have many users connected to freenode at once or if you are a company or other establishment with many freenode users you can now request a larger connection limit by e-mailing your request, details and reasoning to ilines AT // NOSPAM \\ freenode DOT net. Conferences and large networks of users provide a substantial part of freenode’s active community and we always seek to accomodate those who are involved in this.

A very brief mention of upcoming changes..

As you are probably aware we are in the process of rehauling the IRCd and Services software running on freenode. While hyperion and theia have served us well for a significant amount of time they are also starting to struggle under the weight of our rapid growth (we recently hit 43,000 users, which is a number we hadn’t anticipated — that’s 15,000 more users than we had a year ago).

We are of course pleased that our numbers are growing and that more and more people and projects are finding a use for freenode; it’s a fantastic feeling to be able to give something back to the wider FOSS community.

Services wise, we’re currently testing new services on testnet and are close to letting you all loose over there for wider testing before we introduce the new services to the production network. Now, there will be a few changes, and while most of them won’t be noticeable, I felt it was a good idea to remind you of a couple of things.

If as many people as possible can follow the above advice I’d be grateful — it would make the migration a lot easier for us, as well as for our users.

Expirations and e-mails aside, we’ve had a lot of feedback from projects and users who would like to see some changes to the services package — among other things a web-based frontend to services has been mentioned over and over again, particulary for project management. Group contacts would like a way to manage their project namespace, set project related cloaks, and the like. We are looking into OpenID and how to help users and projects which want to more easily integrate, for example, bugzilla and similar with their IRC infrastructure. We’re also trialling a new procedure for verifying group contact forms that may help to reduce the backlog somewhat; over the next few weeks we’ll be trying it out with a portion of the current queue.

In addition to everything I’ve mentioned, we’ve heard some really great ideas and suggestions for further improvement originating from our users, so I thought I’d ask you all what you would put on your wishlist. What can freenode do to better serve the communities? How can we improve irc as a communication and development tool for your project? For your users? I’d love to hear any ideas you may have and would love it if you dropped me a line to ideasATfreenodeDOTnet

Before I wrap up, I’d like to apologise for the instability of the network over the past few days. We have been under a pretty heavy DDoS attack, though hopefully it has all settled down by now. I’d like to thank our fantastic sponsors for the swift manner in which they dealt with things their end, for their continued support and for pulling together to ensure that we have the data required to pass on to the relevant authorities.

It’s pretty rare for us to be on the recieving end of an attack like that, and I sincerely hope it will turn out to be an isolated incident.

Thank you!

Today saw the (hopefully temporary) resignation of one of our senior staffers; Andy Lindeman (alindeman). Andy has been an important part of freenode staff, both as an excellent part of the strong group of user facing staff and as a part of our infrastructure team. It’s sad to see him go, and we hope that he will find the time to rejoin our ranks at some point in the future, but as most of us can relate, being a college student you often find yourself with new and other priorities, be it studies or the social aspects of spending a few years away studying.

On behalf of freenode staff and the PDPC board I would like to thank Andy for the time and effort he has put in volunteering for us over the years and wish him all the best for the future. And when you finish your degree, do come back! :)