A new Protocol for IRC by A.Church

Ashen · Idler Joined: 05 Jan 2004 Posts: 285

You may have seen this already, but A.Church (of IRCServices) has created a new template for a more advanced IRC protocol.

It can be viewed at:
http://achurch.org/irc3/

Yes, it's rather meaty to read, but it does solve lots of existing problems in IRC, such as requirement that servers may not be connected in loops, (allowing this lessens the impact of netsplits) and better scalability.

Comments on this?
It's not been updated in awhile, and may very well not take off as the new protocol would be at least partially incompatible with existing clients / servers - but it does look promising, and I for one would be most interested if someone started writing software based on it.

-Ashen

katsklaw · Guru Joined: 28 Jun 2004 Posts: 1046

he started that way back in 1999 and last updated it: 16 November 2003 .. I don't think it's all that new .. Others have tried to re-invent IRC even had a few software releases and have given up as well.

codemastr · Idler Joined: 05 Feb 2004 Posts: 353

No, it's not new. IRC3 has been an idea for quite a long time. The problem isn't so much that it is impossible to design, it's nearly impossible to adopt.

It's like with email, they realize SMTP is crap. And they want to get rid of it. But can you imagine the results if they just said, "Next week we're getting rid of SMTP"? People barely know how to download the MS security updates, you think they are going to figure out how to update their email clients?

The same thing with IRC. Many of the changes proposed are going to require changes from the clients as well. So the problem is, how do you get all the servers and clients to agree on a new standard, then how do you make sure *everyone* actually upgrades to the new standard? Unlike the upgrades to HTTP and FTP, etc., the changes in IRC3 really wouldn't be backwards compatible in many instances.

katsklaw · Guru Joined: 28 Jun 2004 Posts: 1046

Thankfully IRC isn't as widely used as SMTP. I think that IRC3 would need some form of backwards compatability until the clients have played catch-up .. yet on the other hand, wouldn't be just as easy (if not easier) to simply continue to add features to IRC2?

codemastr · Idler Joined: 05 Feb 2004 Posts: 353

IRC3 isn't about features, it's about the design of the protocol. The biggest change is the removal of the tree based nature of IRC. It instead introduces a cyclic structure. E.g

aquanight · Lurker Joined: 14 Jun 2004 Posts: 118 Location: Boise, ID

codemastr · Idler Joined: 05 Feb 2004 Posts: 353

Yeah, the shortest path algorithm, presumably Dijkstra's Algorithm, does indeed find out that information. But it is an incredibly costly operation, and the result would constantly change. What I mean is, each time you did a /who, the hopcount would have to be recalculated because which path is the shortest might have changed. And by the way, "shortest" path is really a bad name. You take more into account than just distance, such as speed. If I want to go from a -> c, I can go a -> b -> c, or a -> d -> e -> c. The logical assumption is abc is fastest, however, if b is currently being DoSed, adec will actually be the path chosen. This is what IRC3 means when it talks about "weight" of paths. The operation itself is not cheap, it's not very slow, but it's not fast either. Don't get me wrong, it's a brilliant algorithm, and Dijkstra's solution is to my knowledge the best solution available. But, it's also a complex operation.

Anyway, the hop count is just one of many compatibility issues. For example, IRC3 says it is legal to have a space in a nickname. Clearly that will break every client in existence. It recommends that servers don't do this, for compatibility reasons, however it is perfectly allowed. And even worse, you can use the @ and + character in nicknames! In the new protocol it's OK because @ and + are no longer used to identify ops/voice. However, again, compatibility. Clients running the old protocol will misinterpret the /names results. There are many such compatibility issues in the protocol. Also, there are issues with the fact that the protocol doesn't even begin to address the current implemention of IRC. It makes no mention of halfops, ban exceptions, invite exceptions, or any other extensions that have made their way into IRC over the years. Basically, this won't "unify" IRC, it will just create further division.

sliq · Newbie Joined: 02 Jan 2004 Posts: 92 Location: IRC

sounds pretty cool, can't wait till I can /connect to multiple servers while they are already connected... end of netsplits except if a connection completely fails =) cool.

aquanight · Lurker Joined: 14 Jun 2004 Posts: 118 Location: Boise, ID

katsklaw · Guru Joined: 28 Jun 2004 Posts: 1046

mhavok · none Joined: 06 May 2004 Posts: 1

braindigitalis · Idler Joined: 22 Sep 2003 Posts: 443 Location: IRC

PingBad · Guru Joined: 05 Feb 2005 Posts: 1992 Location: New Zealand

It is a promosing protocol, but [as codemastr pointed out] there is no way IRC2 and IRC3 could ever co-exist on a network/server/client

IMO, IRC2 should be kept as the standard for today's networks until it outlives its usefulness (and hopefully IRC3 would have been ironed out to an acceptable standard)
However, how are the new clients going to deal with the new changes like spaces and non-alphanumeric symbols in nicknames since spaces are used as token identifiers between commands and text.

workman161 · none Joined: 28 Jul 2004 Posts: 5

Sounds rediculous, but why not toy around with some kind of XML format like jabber, but built for groups? IMHO, jabber's group chatting pales in comparison to IRC.

The new protocol looks awesome. I really love the sound of loops and border servers.