Optimizations for IRC Protocol?

epiphani asks: "Over the past few years IRC has grown substantially. With this growth, many issues are arising with bandwidth usage. I've started rewriting the client-side protocol that has remained completely unchanged since the publication of RFC1459. During my conversations with various client authors and coders from the major networks, the suggestion has been made to remove the nickname as the unique namespace, replacing it with an ICQ-like UIN. This would mean the same nickname could appear more than once on a network. This would also apply to channel names, just as EFnet is planning to do in hybrid7, with Vchans. Does anyone have any suggestions to optimization of the current client-side protocol?"

Comments

Why?

[ffsnjb]

What is the advantage of changing the unique identifier from the current nickname to a user ID like ICQ? Is it that hard for people to find unique nicknames? I've had mine on Dal (please, please fix their bandwidth/routing issues, they can't keep servers up for shit) for years. And I really don't like the Vchans idea. #dead is mine; no one else can have it, dammit.

Forgive me if I sound irrational, it is 5:30am EDT...

UIN #

[PharaoH]

A unique identifier would be nice for ops on a channel. Then you could ban based on address, nickname, or unique identifier.
However, for that to work the number would have to be uniquely assigned to you. So much for anonymity, vis-a-vis Pentium III.

The power of EFnet

[fluor2]

I might say EFnet is the biggest network around, where it's normal to use netsplits and similar. If you want to keep a channel, you have to add bots (robots just idling to keep channels and which have userbases of channel users). Some might say this suck, but I say it's really making EFnet dynamic, and more like places in the real world. You need power to keep places, and it's hard to keep your name.

However, if somebody get to your UIN (your idea) they might harass you and you might get to a point where you have to grab a new UIN to have peace. This is not what the IRC should be about, and some users really needs the privacy and relaxement of chatting on IRC.

Making a UIN "layer" makes it hard to chat in channels, if several users have similar nicks. You better try making IRC even more dynamic, introducing random earthquakes (netsplits), and hazardous storms like in the real world.

Re:The power of EFnet

[The-Bus]

Efnet could do well by increasing their max nickname length to something a bit user-friendly. Currently, it is 9 characters. I have been on some IRC servers where the norm is much higher and you chat with people who use nicks like MolotovCocktail. While this is a somewhat stupid solution, even an increase by 2 characters will increase available names ten- or twenty-fold.

Netsplits are certainly interesting but very much a pain in the ass if they happen for too long. How they can be good, I have no idea.

Re:The power of EFnet

[epiphani]

I feel like pointing out a few small issues in this. One, EFnet hasnt been the biggest network around for quite a while. DALnet overtook EFnet over 18 months ago, and regularly breaks 80,000 users online and averages substantially more users at any given time.

Additionally, this "UIN" solution was proposed by EFnet coders, and im not exactly too fond of it.

Re:The power of EFnet

[Dzejwi]

DalNet isn't the biggest network either. With 139 servers and peak of 98644 is the IrcNet.

Re:The power of EFnet

[AndroSyn]

The problem is that the more you increase the length of the nick, you increase the amount of bandwidth you consume on storing excessively long nicks. Not to mention increased memory consumption.

As far as UIDs go. Even if we don't let the user know they even have a UID, that is much better on bandwidth consumption.

I personally think UIDs are a good idea though. Basically unflatten the namespace. Of course UIDs aren't really much good unless you have some way of doing persistant UIDs. Of course their are other issues that would need to be worked out when dealing with non-unique nicks.

Re:The power of EFnet

[Alatar]

Anybody who can't effectively express a nickname in 9 characters has no business chatting. Who the fuck cares if you can have your idiot "IreadTheAnarchistCookBookAndThinkImKewlCauseIcanM akeAGasolineBomb" nickname.

I think EFnet could "do well" by not listening to idiots, and shunting them off to the other, lesser networks where the network admins will give you back your nick when the bad man takes it from you and you can't defend yourself. Sheesh.

Re:The power of EFnet

[mirabilos]

Thats why i dont use ANY of them. openprojects.net is so small that I only had 3 netsplits in the last 1.5 years.

--

Out with the old, in with the new

[pbryant]

How much will a rewrite of the spec gain you? The protocol would have to be backwards compatible with all the existing clients? How would users on old clients feel about all their online buddies being reduced to numbers?

The IRC protocol has done its dash. Its time for something completely different. Something extensible, something that better reports online presense. Check out IMUnified or Jabber.org. Jabber even provides an IRC gateway (converting its native XML based protocol to the IRC protocol).

Re:One thing i'd like

[billcopc]

Of course, eventually the only people with ops will be those 12 yr old lurkers who have just discovered l33t-speak and like to kick just for "kicks"

Re:Dalnet uses compression between servers

[AndroSyn]

ziplinks to save quite a bit on bandwidth usage, but most implementations of them are dirty hacks. Which is why they got ripped out in hybrid7. One of these days somebody, (me?!?) will readd the code to do ziplinks. Of course this is not as necessary with lazylinks. Lazylinks basically kills the need for bursting on server rejoin. The leafs end up keeping state about local users, but remote users it goes to the hub. I don't remember the exact details as I'm not the one who implemented them.

SSL

[crazney]

i'd really like to see a builtin-standardized option for enabling SSL in channels.. so not only can you lock out people, you can also set that channel to SSL only, so peope cant sniff what your talking about..

it would be a BIG plus in terms of corporate discussions (and, possibly the plotting of murders..) ;p

Re:RFC1459 is updated

[epiphani]

If the authors of these RFCs would have at least consulted with any of the [other?] major networks before releasing them, perhaps they would have been implemented. Since they did not, the RFCs you listed are virtually defunct.

Control

[mirabilos]

And who'd manage the namespace?

Don't answer...
I heavily dislike such ideas. And not every continent has 24/7 online times.
Try to get a German DSL-flat. I'll get children earlier...

--

Re:Control

[Vess V.]

That's the point, there would be no namespace conflicts... everyone could have the same name if they wanted.

EFnet [slightly OT]

[AntiNorm]

This would also apply to channel names, just as EFnet is planning to do in hybrid7, with Vchans.

Please tell me EFnet is also planning on fixing their I: lines. It is VERY irritating to have to manually cycle through literally 25+ servers (I had to go through 27 once) just to find one that won't boot you off saying "you are not authorized to use this server."

---
The AOL-Time Warner-Microsoft-Intel-CBS-ABC-NBC-Fox corporation:

Some ideas for the client-side protocol

[Stskeeps]

Well, a good thing would be the understanding of tokens (like P = PRIVMSG, N = NOTICE) by clients, that could save a lot of bandwidth on a lot of servers. Also a standard for tunneling IRC inside SSL could be welcome, many IRC servers support this nowadays. Compression isn't feasible client->server, so that would not be a good thing to be able to. It is generally on server-server that is mostly required.

Also, inclusion of the numeric 005 spefication in a RFC could be welcome (RPL_ISUPPORT) - as it makes clients able to know what is and what is not availiable on a server, and can take precautions to what kind of numerics it may recieve.

About UINs, my belief is that I need noone to be able to fake who I am, and UIN's will increase the stalking that usually happens by people. Doesn't UIN's take away the charm of IRC a bit? - we are not MSN/ICQ/(insertcrappychathere) last time I saw. Nickname problems: Why would we want 300 Gandalfs on same network? About vchans, I mean, Don't you like how #blah is managed? Make #blah+
:P or find another playground.

Generally, IRCd coders should sit down and make up a common standard - not the IRCnet RFC's, but RFC's that basically covers how most IRCds work today.

ICQ-like UIN?

[_outcat_]

Using an ICQ-like UIN would take some getting used to. I am a rather major Undernet junkie (check my bio for details) and my own frequently-visited channels had to make some major adjustments after the big Undernet attacks earlier this year.

For one thing, it's much easier to type a nickname. If we go through a netsplit (big surprise on Undernet :P !) and some op sees the channel with 37 people in it and the channel limit set to 90, they might semi-cluelessly change it to 40. Then people start coming back in from the split, and pretty soon the channel is full. If I were caught in the split and couldn't get into the channel, I want to /msg an op in channel to please raise the limit. I don't want to have to /msg 18 different people on Undernet with the same nick, nor do I want to look up an op's UIN. Something would have to be done to streamline the process, and it would require massive changes in IRC clients.

Previously mentioned on this discussion, however, was mentioned that on ICQ, one can sometimes have one's UIN assailed by harrassants, and all a person can do is get a new UIN for peace. Well, in my experience, the /silence features that Undernet has, at least, are a bit more robust than ICQ's...not only do you not see attackers or irritatants, but they don't even get through the server to you (unlike /ignore--you can still feel the effects of a flood attack.) All you have to know is your harrassant's user@host or even just a pattern in their nick--I used /silence !~??*@* for a while because of floodbots with a broken ident and two-letter semi-random username...

I don't know. I'm just throwing out ideas. It might work, but it would take a lot more getting used to than some people on IRC might like. I wouldn't mind it, personally, but the UIN -- nickname issue would need to go smoothly..

Just my two cents.