Hacker News Reader

Comment by donatj | Hacker News Reader

If you've never poked the IRC protocol directly, Google how to connect to IRC with Telnet.

You can pretty reasonably use IRC just by writing to a socket - by hand. It's all human readable and understandable. It's incredible. It's what an open protocol should be.

Writing a simple IRC client is a breeze!

View on HN

I tried it before and it's not as easy as it sounds. There is no one spec, it's a handful of RFCs and other ad hoc extensions that are barely documented anywhere. I think there's at least a dozen different documents you have to refer to.

For most of the client protocol, it's just RFC 1459 and RFC 2812. Then there's CTCP, DCC, server-to-server protocols and the 005 numeric.

I'm not sure you need any of these for communicating via telnet or writing a small bot that will answer back.

Each of the big servers implement their own extensions, or share some extensions but not others. All poorly recorded in many documents across the Web.

To have a modern irc client, it is far from a clean protocol. If you just want the basics, it will still connect and send messages.

I tried to implement an IRC client in about 2004 and no popular server was implementing RFC 2812, which was released in 2000. I realise that's a long time ago but things move slowly in the IRC world, so I would be surprised if things had changed a lot since then.

RFC2812 was codifying one particular network's protocol choices and was never accepted by the wider community of IRC server and client developers.

There have been widely implemented improvements (eg RPL_ISUPPORT / 005) which succeeded by discussion and consensus rather than trying to lay down a new standard by fiat.

Yes, you can definitely connect manually through telnet (I did it back in the old days). The only problem is it will not stay connected too much, because you should also reply to server's PINGs at regular time intervals otherwise you'll get disconnected.

With most servers you don't actually have to specifically reply to the PINGs, just sending something regularly should keep you connected.

I've toyed with many protocols via reading RFCs, but in this case just run tcpdump on an existing client and you'll be set.

Some people already did a good job at making libs and tools to easily interact with IRC: libircclient [1] and the irctk [2] wrapper around it comes to mind. Using irctk it's remarkably easy to write an IRC bot that does whatever you want.

[1] http://www.ulduzsoft.com/libircclient/

[2] https://a3nm.net/blog/irctk.html

I've written several basic IRC clients and bots over the years. Compared to XMPP, and other newer proprietary protocols it is actually quite simple.

Hardly anyone uses the DCC file transfer stuff anymore, so other than encryption, all you really need to handle is channel messages and private messages, plus the management commands (ops, voice, mute etc).

For a simple client, the original RFC 1459 is still just enough.

Many of the oldest internet protocols are ASCII text protocols. IRC, HTTP, FTP, and SMTP can all be handled by a human being with a telnet client.

That's the way it all used to be, back when the net started rolling out. You could hook up to whatever you wanted, even roll your own protocol, just using either telnet or some sort of quasi-primitive scripting.

Now everything you touch has dozens of layers of junk on it -- and it's all mostly http.

It was a lot more fun when you were free to do your own thing without having to carry around 40 tons of tooling.

I tried that once. Main issue is you have to reply to the pings or you get kicked.

I have found Matrix to be easier to interact with. You need a HTTP client instead of netcat but it's super simple to send JSON from a program or terminal.

I keep meaning to write a simple client to get some networking code practice. It's been sometime since I wrote some.

> It's what an open protocol should be.

I'm not sure how I feel about this. I agree, but I also want to welcome things like gRPC/Protobuffs over HTTP/2 which introduce really fast comms between clients and servers, sacrificing the visibility of the stream's contents.

> I also want to welcome things like gRPC/Protobuffs over HTTP/2 which introduce really fast comms between clients and servers, sacrificing the visibility of the stream's contents.

Protobufs and similar serialization protocols are great for complex data. It is worth pointing out that we've had ASN.1 for a while and it's pretty fast too, at least for limited subsets of OIDs/types, in certain encodings, though XER or JER would probably not compete with BER.

HTTP/2 is a complex protocol designed to fix problems with the way people build websites today. A lot of its features does not make sense/is not needed for simple message passing.

e.g., some HTTP/2 implementations will probably see HPACK DoS bugs/vulns because HPACK is stateful, whereas if HTTP/2 wouldn't have HPACK that problem would not have existed, but the reason why HTTP/2 has HPACK is because people bloat headers with tons of stuff.

IRC works and works well for its use case. Apart from newline-delimited strings - netstrings and TLV are other examples of formats that can build great, simple and introspectable/open formats.

I'd venture a guess and say that an RFC1459 PRIVMSG message parses faster than a protobuf message carrying the same information - due to parsing an RFC1459 PRIVMSG message is so simple. Of course, if you want arbitrarily sized messages, or messages with an arbitrary number of nested messages inside it you need more complexity.

Before I had a home network or always-on internet connection I used to play with servers locally. I actually set up my own IRC network using unrealircd and learnt how to configure it etc. I don't know why but one day I decided to try to telnet into the IRC server and it blew my mind that it actually worked. You can do the same thing with an FTP server as well.

SMTP too.

I used to do this when I was a teenager.

Look at "modern" chat protocols (like XMPP...): it's a nightmare in comparison!

Except for the complete lack of security and blind trust of server operators?

It's downright dangerous to use it,but then again people still use email.

The same can be said for slack too. Irc is far superior.

You like irc. Does not mean it's superior. It's unsafe and lacks too many features natively. It wasn't even great in the early 90s. It was popular and I liked the experience but the protocol is even more broken than email.

I am a fan of simplicity,but it needs to be safe to use and friendly to users.

Your argument can be made about more or less any popular chat platform to have ever existed. At least you can set up your own IRCd, so you and your friends don't have to trust nobodies on the Internet.

To be fair, you do have to ultimately trust everyone communicating with you. Trust is pernicious in that way. That is to say, there is nothing guaranteeing that the communication delivered to your server is what was sent by your clients in a completely "open" system.

There are ways to fix this, I think. And I make no claims that common chat systems have fixed this. Just pointing out that having your own IRCd server is not at all solving it.

It's not safe. Period.

Reply on news.ycombinator.com