Hacker News new | comments | show | ask | jobs | submit login

If you try to work IRC up to be a real, true XMPP replacement, you'll be complaining about how hard it sucks in no time.

I doubt that.

The parts that actually somewhat work in XMPP would be fairly straightforward to add to IRC (mostly related to persistence and identity). From there the question is where you'd want to take it, not what idiocies XMPP fell for. I.e. the task would be to do it right, not to imitate a broken protocol.

Just compare http://www.ietf.org/rfc/rfc1459.txt to http://xmpp.org/protocols - where the latter isn't even the full story.

And then tell me with a straight face the complexity is "inherent to the problem". No. It's not.

IRC handles very similar problems to XMPP already (and then some that XMPP doesn't have) and the specification, in its entirety, is only 3643 lines long. Extending that for distributed, message-persisting operation would not bring it anywhere near the insanity of XMPP.

Naturally that's an academic exercise, nobody would actually re-shape IRC into an IM system that way. However, when cherry-picking concepts for a new protocol then IRC should be high on the list, and XMPP rather low.

I challenge you to write a functional irc client based solely on the rfc. IRC is a fractured protocol where the real spec is in the source code of the implementations out there.

I challenge you to write a functional irc client based solely on the rfc.

I've actually written IRC bots mostly from the top of my head.

The protocol and semantics are really simple.

Type this into a console near you:

   nc irc.freenode.org 6667
   USER foo bar batz boo
   NICK test345
   JOIN #testchannel
   PRIVMSG #testchannel hello world
   PRIVMSG test345 hello self
Yes, that's all it takes for a minimal, functional client. (just remember to type PONG every once in a while)

I'm not sure what you mean by fractured. Like every protocol it has a few rough edges, but those are nowhere near the semantic nightmare that I witnessed when trying to dabble with XMPP (which admittedly was more than a year ago).

I remember attempting to write an IRC bot a while back and finding that RFC severely lacking when it came to connecting to whatever irc network I had chosen to test it against. The problem was that the handshake to join the server was different in the RFC than what the server was expecting. This sentiment was mirrored by others I consulted with over IRC that were devs on the epic3 irc client. So, while writing a IRC bot may be simple, I would imagine that writing a client isn't. The protocol itself was the same (in the "COMMAND args" sense), but the conventions differed.

Let me tackle this from a different angle:

How long did it take you bring your client into a reliably working state? And have you tried to do the same with a XMPP client for comparison?

As said, I didn't mean to claim IRC is perfect - nothing is.

But if you think the differences that IRC networks have introduced are problematic then I invite you to try and build a most basic jabber client.

It's a lot easier to write a functional IRC client by glancing at the RFC and banging on a piece of code until it mostly works. For example, http://lists.canonical.org/pipermail/kragen-hacks/2008-Febru... was written that way. Given that the only protocol message it has special handling for is PING, though, I'm pretty sure you could have written it based solely on the RFC.

However, I think it's a big mistake to claim IRC "scales amazingly well". The biggest IRC network today has tens of thousands of users (at the moment, freenode has 64000, undernet has 58000, and EFNet is down in the 32000 range) and the IRC networks are constantly suffering from breakdowns from overcapacity. Compare this to Skype, Facebook, or Gmail, with tens of millions of concurrent users.

Speaking as someone who spent a long time working on Undernet trying to make IRC work. The RFC is poorly specified (eg ~ and ^ are missed from the case equivalent list). IRC scales poorly (the protocol relies heavily on global state). IRC doesn't do UTF-8, or in fact, any sane character set (see the case mapping mentioned above). Client's ignore the parsing rules (eg the : marking multiword last arguments) and kludge around them. Each network went off and did their own thing, fragmenting the protocol space, and then declared themselves as being the One True IRC Protocol. IRC puts a lot of trust in all the server admins on the network, making it difficult to federate, and so on.

IRC was a great protocol in the 1980's, it's been dead for a while, just there are no good replacements.

Yes, IRC has warts, I didn't mean to declare it as the end of all things.

The point I was trying to make is that IRC would be a more sane starting point than XMPP. Even despite all the shortcomings you mentioned and some more that you didn't. And even despite it being a strictly centralized design that would require more server-side changes than XMPP to turn it into a distributed system.

I'll lean out of the window and even claim you could make a distributed IRCd backwards compatible to existing IRC clients, as far as the core business of presence/state, chat and group-chat are concerned.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact