1. I find that IRC channels of very popular and big projects, and big channels in general, are not very friendly places. Why is that? I think the intolerance to off-topic discussion has a lot to do with it. First of all, someone constantly nagging about taking elsewhere discussions that have strayed on "off-topic" paths, does not lend to friendly atmosphere. Of course, on a huge channel "off-topic" discussion can hide the "on-topic" matter, so it does have its negative effects. However, I think it is precisely the lack of off-topic discussion that also contributes to the hostility. For, it is the casual "off-topic" interchange that builds community; sticking to just "business" (i.e. busyness), does not.

As an attempted solution, some channels, as they've grown (too big), have forked into #foobar-overflow and such channels for the "off-topic" discussion. I don't think that solves anything; it is a completely new channel that is created, to which new blood seldom wanders, and so you only find a handful of old farts on those channels. Especially to free software projects' channels, people come in "business" and may stay if the environment is friendly. But most have very little reason to wander into "non-business" channels.

Clearly forking channels is not a solution then. Gale in its turn tries to divide discussion into a hierarchy of categories – similar to Usenet groups – by the topic of messages. I find that too unflexible and complicated. Infact, the whole system with its IM-style registration on a particular server seems overly complicated; more on that later.

A possible solution is, however, found in Usenet/NNTP, and something much older than that: IRL social gatherings. The problem with IRC is that all the discussions are mixed together. In IRL gatherings, people who want to partake in a particular discussion, gather together in a cluster, and distance hopefully filters out the worst of the noise from other discussions. In Usenet, and even on Web boards (yuck), different discussions live in different threads. Now, while some Usenet channels and Web boards are populated by on-topic police (who don't even know how to use the killfile), discussions that have strayed off topic, tend to be tolerated more than on big IRC channels. But, IRC as a medium offering instant relief to boredom, is a more natural forum for casual discussions.

Why not add threads to IRC (or its successor) then? Everyone who initiates a new topic of discussion, should start a new thread or sub-channel, the creation of which is notified to all the people on the channel. All the active threads could be listed in an area of the IRC screen, just like a news reader would use part of the screen for the message and part for the thread view. Furthermore, it should be possible to start a thread on multiple channels, or send an existing thread to another channel (if the channel allows that, possibly on the condition and some people partaking in the thread are already on the other channel). People who don't want to see the activity in a particular thread, can choose to not pay attention to it, and even filter it out to not see any indication of its existence.

2. I said above that I don't like the registration on a particular server, characteristic of IM. It does, however, have its advantages. Namely, it is possible for the server to store messages sent to you while you were not logged in. (I don't actually know if the IM services do this… I've never used one.) More nice unrealised possibilities are offered by the email-style user@host address: you could share your email and instant messaging identity. But if the identity is shared, why not send messages by email when offline?

In IRC, there's very little guarantee that an entity using a particular nick is who it was the last time, or you think it should be. Some networks have added registration support to offer some guarantee of that, and to let you keep your nick if you've registered – and constantly nag if you don't. However, I think that is the wrong solution, even with a better implementation. Among other cryptographic niceties of SILC, user identity is cryptographic too. There are no nick collisions, and two people may use the same nick; the client takes care of separating them. To verify that a nick belongs to someone you know, you use his public key.

This key in SILC, however, is specific to the application. Combined with other email integration, it would be nice, if it could be your usual GnuPG key – the nick, however, independent of the email address. Then if someone has your public key, he could query the chat network for you by a token calculated with your public key and verify the result. In case of failure, the client could offer to fire up an email client, or simply post what you write within it. Within the client, the email address itself should of course work for querying, but the network only needs to know a hash table of clients, so that if your public key isn't public knowledge, you don't have to reveal your identity to it, and even in general it does not have to be immediately apparent. Infact, the network does not even have to know the identity system in use, only manage a hash table of tokens that parties at both ends know how to calculate, and provide a channel to send authentication messages.

Of course, in IRC- or SILC-like systems, there are multiple servers in multiple networks, and the server or network to contact for contacting you, is not apparent from your email address, unlike from an IM address. This information could, however, be stored in the GnuPG key, or there could exist servers – or a distributed hash table – for looking up from multiple networks. The advantage over an IM-like setup is, of course, not having to rely on a single server or a service provider – as is the case with the email address, however.

3. I'm annoyed by the growing number of video and flash links on some channels. Even if I were interested in them – which is usually not the case, but not immediately apparent from such "timed" media – I can't be bothered to install all the broken plugins for these, or switching headphones in my cubicle from the mp3 player to the computer. Not that sound has even worked in flash for ages. Thus, in the meanwhile, before an IRC replacement where a thread can be dedicated for this shit is available, I propose extending the NSFW protocol with the OSFML tag – "only suitable for multimedia lamers".