[danieloaks]

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!

[unimpressive]

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.

[danieloaks]

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/ :)

[app4soft]

> 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/

[spike021]

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

[HerrMonnezza]

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

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

[nine_k]

Hipchat can be configured to offer an IRC gateway.

[spike021]

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).

[Propen]

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.

[danieloaks]

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...

[jiggunjer]

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

[bastawhiz]

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

[jwilk]

Why .horse TLD?

[danieloaks]

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