Modern IRC Client Protocol | Hacker News Reader

Modern IRC Client Protocol

modern.ircdocs.horse

154 pointsbeefhash45 comments

IRC is IMHO an example of a good text-based protocol design, along with several of the other early Internet application-layer protocols (POP, SMTP, HTTP); usable manually with nothing more than a netcat terminal, but also by more fully-featured clients. Early versions of MSNP had a similar flavour, before Microsoft decided to bloatedly XML-ify and SOAP-ify it.

Also, can we please stop using the word "modern" in everything? It's essentially meaningless. At least the name of the page doesn't have it.

Example: I have a book titled "Modern Welding" on my bookshelf (or, as others have called it, "Modem Welding", which partly explains why it's there...), whose copyright date is 1965.

In regards to your second point, it is a web page rather than a book, and it states that it is intended as a living document.

IRC has changed a lot over the years, and this is an attempt to document the subset of the protocol that is currently being used in most implementations (hence the "modern" title).

MSNP was a neat little protocol. Messages were sent as mime messages. They did have a max message size, but the official client would ignore any headers it didn't know about and any mimetypes it wasn't expecting. This gave third-party clients a lot of ability to extend the protocol. For instance, I hacked in avatar support in Gaim (aka Pidgin) when I was maintaining that support.

MSNP8 is when all the terrible MSNSLP (MSN SLP-Like Protocol) stuff began, with the binary packets. Spent a couple months figuring out the content of those packets... And while avatars were part of the protocol at this point, custom content was no longer as viable. I can understand some of the reasons they wanted to change it, but in the end, I think they ruined a decent (if imperfect) protocol.

>IRC is IMHO an example of a good text-based protocol design

Though it would have been nice if there was an actual text encoding specification. Right now, various networks, especially in Asia, have all kinds of funny encodings going on. Meanwhile in US and European contexts, UTF-8 isn't standardized, so you have to expect other encodings as well.

"Also, can we please stop using the word "modern" in everything?"

I am using a text-based browser and so I do not use the upvote/downvote javascript. Consider this comment an upvote.

The increasingly pervasive attachment of the word "modern" to software descriptions in recent years is confounding. I thought maybe it was annoying only me but apparently not.

Sometimes I have thought it could be a manifestation of cognitive dissonance arising from the realization that in software, in most cases, "there is nothing new under the sun".

Honestly I do not understand where it comes from or what it means. Is it some sort of marketing buzzword?

Can't speak for software but in the case of these specs, 'Modern' in the title pokes fun at the fact that the core protocol specifications most people refer to are around 25 and 18 years old, respectively. RFC 1459, very commonly referred to and still the first reference for a lot of IRC software authors, came out before I had my first birthday!

> I am using a text-based browser and so I do not use the upvote/downvote javascript. Consider this comment an upvote.

I haven't tried, but looking at this page source it looks to me that vote arrows are divs wrapped in anchors pointing to up- and down vote URLs. They should definitely be usable without JS; maybe the problem is that the empty divs are not visible in your text browser?

Correct. They are not visible.

I could convert these anchors into visible URLs and they should work. Nevertheless I will not be doing that.

When I mentioned JS I was thinking of the presence of the onclick attribute and the vote() function as seen below.

I for one am waiting for the Post-Modern or New-Modern IRC Client Protocol. Modernism is just so dated these days. /s

Thanks for posting this here! I will admit, it's hard to know when to start posting it around, but this is already a fair bit more accurate than the traditional RFCs in a lot of ways. It's also lead to an Internet-Draft around CTCP being submitted here: https://tools.ietf.org/html/draft-oakley-irc-ctcp-01

If anyone's interested in contributing or asking questions, just reach out!

As someone who's tried to develop stuff for IRC before, thank you for this. People act like IRC is dead, but it's very much alive in 2017 and severely neglected on the tooling and documentation side.

> People act like IRC is dead, but it's very much alive in 2017 and severely neglected on the tooling and documentation side.

This[1] XKCD ;-)

[1] https://xkcd.com/1782/

Wish I could connect to Hipchat over my Weechat client :)

Hipchat can be configured to offer an IRC gateway.

Whoa. I will look into this. Thanks for letting me know! Figured that was only the case with Slack since Slack is IRC-based (IIRC).

You can use Bitlbee as a gateway between your IRC client and the HipChat server.

See, è.g., https://wiki.bitlbee.org/HowtoHipchat

Thanks, I'm glad it's useful! Feel free to check out this page for some other useful links if you dev on it in the future: https://ircdocs.horse/info/ :)

Why .horse TLD?

The first page I wrote when I was making the site was this one (https://ircdocs.horse/specs/) – and the initial drafts were a fair bit screechier than what's there now. I wanted people to know that everything on ircdocs is pretty much just my thoughts (as opposed to the more consensus-based approach of IRCv3), and figured the horse TLD would make people take it less seriously.

Didn't exactly work out, now that a fair number of devs are using it as a legit protocol reference. Still, gives the site some decent character and makes it memorable :P

Is end-to-end encryption going to be part of a modern IRC experience? Please, this is an absolute must. And don't make it optional if possible. Make non-e2ee optional.

These specifications just capture how the IRC protocol currently operates, so that isn't described here (isn't widespread afaict, and there isn't a clear 'winner' in terms of implementations/mindshare). The issue with something like E2E encryption is getting rough consensus with all the vendors, which is what the IRCv3 WG focuses on: http://ircv3.net/

There's been a number of E2E encryption methods proposed in the past such as SSL/TLS DCC (which doesn't do certificate verification from what I've seen, so that's not too useful here), FiSH and OTR are already used decently out there but I'm not aware of any widely-available, simple-to-implement specification for clients to look at. There's another interesting proposal here, but it hasn't gained traction as of yet: http://blog.bjrn.se/2009/01/proposal-for-better-irc-encrypti...

What's the point if anyone can just publish the log?

What's the point of any encryption if any of the participating parties can publish the plaintext?

Good initiative. It is of greater value to document established standards rather than making new ones.

If I wanted to modernize IRC today, I would focus on Matrix.

https://matrix.org/docs/spec/

The link seems to describe IRC as it exists today, and does not appear to be an attempt to modernize IRC.

Quoting from https://modern.ircdocs.horse/

   This document intends to be a useful overview and reference of the IRC client protocol as it is implemented today.

The title is a bit misleading. This is a documentation of current best practices / de factor standards in IRC. It's not a proposal on how to make IRC better.

Thanks for the link to matrix.org though.

Yeah, I admit the title's not great. I'll update it in the next few days, thanks for the feedback :)

What about IRCv3? http://ircv3.net

This project (ircdocs) works in tandem with IRCv3. ircdocs tends to focus on currently-implemented stuff (such as the linked Modern docs), where v3 focuses more on establishing rough consensus around new specifications and features.

i wish matrix was written in something like elixir or go instead of python.

matrix/riot is indeed a good attempt but if you are going to modernize it, it makes sense to use a modern stack to keep up with the times.

Matrix refers to a specification, not an implementation. There is nothing stopping you, or anyone, from implementing a Matrix server in whatever language you'd like. In fact, there is already a server being implemented in Go called Dendrite,[1] another called Ruma[2] that is being implemented in Rust, a "WIP toy" Elixir implementation called Matrex,[3] as well as others.[4]

[1] https://github.com/matrix-org/dendrite

[2] https://github.com/ruma/ruma

[3] https://github.com/bismark/matrex

[4] https://matrix.org/docs/projects/try-matrix-now.html#servers

Python's a modern stack in any reasonable definition of the word. Just because it doesn't use $TRENDY_LANGUAGES doesn't make it 'not modern'.

Just like ipv6 they are over complicating things that need simplification.

End to end encryption and chat room backlog would be nice. DCC and CTCP need to go away. A simpler protocol that does more with less would in my opinion be optimal.

AFAIU the site is just documenting existing practices, so I don't think they are over-complicating anything - things just were already complicated (and poorly documented).

Yep, pretty much. Unfortunately the protocol's gotten fairly complex without standardisation to keep everyone on the same track. I do my best to simplify the text where I can, but a little more in-depth and correct is better than something simpler that doesn't match real-world implementations.

edit: With regards to encryption and backlog, they're being worked on in the IRCv3 WG, worth checking out if you're interested in changing the protocol for the better: http://ircv3.net

You are right. My comment was more towards the ircv3 wg.

For what it's worth, there's been a bunch of work around backlogs (to simplify bouncers, though if more niche IRCds wanted to incorporate it natively that'd work too). CTCP isn't great, but the simplified CTCP I-D improves things for clients. DCC I'm documenting, hoping we can replace it with something more appropriate and/or extend DCC as it currently exists in a backwards-compatible way (there's a loooot of debate and discussion on DCC in the v3 WG. once we fix up a bunch of misc protocol stuff it's definitely something we'll approach).

For sure, simplicity is better than complexity. A fair amount of the v3 work aims to simplify things that are already done in a bunch of vendor-specific ways and bring them all under one clean, well-specified roof. Always happy for extra help there :)

I'm part of a team working on a player (a vm) to run small user scripts with voice and vision.

We've picked the irc "/" idea for commands as a way to communicate between processes.

For example, we have /say and /listen commands.

I started a document to describe that this afternoon (very early wip - only to make an idea)

https://u.sicp.me/dhSk5.pdf

And, yes! IRC is still alive and some networks (like freenode) are even growing.

FYI we are on irc.rizon.net #eva

The server types concept reminds me of the NTP stratum paradigm

A relevant XKCD: https://xkcd.com/927/

And also, https://en.wikipedia.org/wiki/IRCd#/media/File:IRCd_software...

Irc is the merovingian protocol who has outlived many "new" protocols that were allegedly better than it. Why will this protocol be any different?

Because it is irc.

I think you've misunderstood the purpose of this site: they are documenting the existing IRC protocol as it is "generally" implemented today, as IRC is now a poorly-specified pile of hacks upon hacks. This project seems like a good idea for that reason.

Reply on news.ycombinator.com