german version german version

irc2.10's new !channels

A user-friendly explanation by Kaspar 'Kasi' Landsberg
Slightly completed by Mario 'BitKoenig' Holbe


The following explanation assumes that you are at least a bit familiar with the Internet Relay Chat (IRC) and that terms like "channels", "nicks", "servers" and "clients" are known to you.


The new IRC server version irc2.10 (mainly used on IRCNet) introduces a new type of channels to IRC: unique, uncollidable channels marked "!channels". To explain what exactly that means, let us examine the situation on IRC before irc2.10 became reality:

The Past

As you know, a channel does only exist when at least one person is on it. And as you know too, an existing channel is known on all servers connected to a specific net, which means that you can join that channel on every connected server of a net and you will see there the same user(s) (if the channel had existed before your join of course). But what happened when some server split temporarily away from the net (ie. that for a certain amount of time, the server is not connected to the other servers anymore)?

Well, roughly, this is what happened on the server which splitted away and was then alone: All channels on it were "destroyed" (they became nonexistent) except those on which was at least one user who was on the server which split away. Respectively the same happened on the other side of the net (where the rest of the servers were). But if, before the split, there were users on the same channel coming from both sides (ie. partly from the server that will split away and partly from the other side), then, after the split, you had two channels with exactly the same name but with different users (and maybe different modes) on both sides. Keeping this situation in mind, here's what happened when both sides of the net (until then separated) reconnected to each other, forming again a single, non-separated IRC net:

Since you had different states for the same channel on both sides, the state of the concerned channel had to be "resynchronized", ie. that on both sides had to be created the same state of the channel (same users, same modes). This was done by the concerned servers. What you usually saw then was one server opping other users ("server-ops") or setting other modes ("server-modes"). This also usually happens on so called "channel takeovers", which you probably have already encountered on IRC. Those "channel takeovers" were an obvious problem of the former channel design, since channels were collidable in the way described above. Thus was the situation in the past, before the IRC server version irc2.10 became reality. Now, let's examine how things look like with the new server version.

The Present

A new channel type
The latest IRC server version irc2.10 gives us "uncollidable channels" by introducing an additional channel type -- ID-channels ("!channels") -- to IRC. An ID-channel (from now on only called "!channel" in contrast to "#channel") is nothing more than a channel with a unique ID. The channels that you know and regularly use have the form: #channel_name. The new !channels have the form: !<ID>channel_short_name, where <ID> is a unique ID chosen by the IRC server, like "abd23" and "channel_short_name" is the channel name chosen by you, the user or respectively, the creator of the channel. An example of some !channel could be: !abd23France, where "!" is the prefix present in all !channels, "abd23" is the channel ID and "France" is the short name. The channel ID has always the same length, which makes it easier to distinguish the short name from the ID.

Since each !channel has a unique ID, it's "impossible" to have identical !channels and they are not collidable. Here are the basic rules which you have to keep in mind when using the new !channels:

Now that you know the basic rules concerning !channels, let's examine the respective commands (especially the JOIN command) for the use of those channels. A basic rule applies to the entire command section:

It may be possible that your current IRC client does not support (yet) (entirely) the new !channels. So if some of the following commands don't work for you or make your client look weird, then it's probably your client's "fault".

This being said, here we go with a list of basic commands in relation to our new !channels:

A new user mode
Along with the new !channels was also introduced a new user mode, which is closely related to the !channels. This new user mode is automatically assigned to everyone who creates a new !channel and it makes him the "!channel creator" for each !channel he has created. The sign of this new mode is "+O" (don't confuse this with the already existing user mode "+o" which all channel operators have). The server gives you the "+O" user mode for each !channel you created. So if you create the !channel "foo", then you will automatically get the user mode "+o" (channel operator -- as usual) and also the user mode "+O" (!channel creator) for the !channel "!<ID>foo".

Here are the characteristics of the new !channel creator mode (+O):

A new channel mode
Along with the !channels comes also a new !channel mode, the "reop" channel mode, whose sign is "r". Only a !channel creator can add or remove it. It can be set via the MODE command, just like any other already existing channel mode (s, i, m, etc.). Its purpose is to avoid opless !channels. Since !channels are unique and cannot be collided, it's impossible to get "server-ops" on them by a !channel collision (contrary to normal #channels) once they become opless.

So if a !channel should not risk to stay opless forever once it becomes opless, its !channel creator has to set the "r" mode on it. If this mode is set and the !channel becomes and stays opless for a while, then the server will reop automatically and randomly some (or all) users on it. The randomness of the reopping routine is programmed in a way that it won't increase your chance to get reopped if you let lots of clones/bots/friends, for example, join the !channel.

The Future

The main problem of IRCNet -- nick collisions -- is still not addressed but will be solved in the next major IRC server version. An interesting proposal to that problem comes from Piotr "Beeth" Kucharski and can be found here.

Besides that, the whole IRC server software needs to be rewritten... :-)