IRC as a protocol is indeed incredibly simple and easy to get started with. Years ago did discover this when I was able to make [this atrocity](https://github.com/creesch/discordIRCd) bridging IRC and discord where for IRC I effectively did a simple server implementation.
There is a caveat, though. Like many older protocols (ftp) there is a lot that was not initially written down or left up to clients and server implementations. This, does lead to a lot of edge cases you need to be aware of once you want to actually support a wider user group.
Also, as this is apparently is still a discussion. IRC is not simple from a modern user UX perception. Registration can be complex and confusing, though hidden a bit through clients. Managing channels with various flags is a whole other thing. Then there is also the fact that these days people are no longer used to the fact that they can't see messages from periods where they were not connected. Of course, the latter can be easily handled by a BNC or fancy clients like https://thelounge.chat . But, that is only easy for technically inclined folks.
Not only that, but IRC server protocol(s) are much more underwhelming. If my last recollection is correct (and I gave up with IRC before IRCv3 became viable enough, which was too late IMO), pretty much every surviving server implementation had their own server protocol.
IRC is not a federated protocol, so this is not a big problem. Yes, it's a "relay chat", but in the end all servers of a single network must trust each other, and that means they are being run by a single organization and it's just a mechanism for horizontal scalability. This is not the same as XMPP, which has a federation s2s protocol, but each service provider can use a custom server protocol for horizontal scaling.
The original IRC was federated though. It is an unreasonable assumption but imagine that the original federated network did sufficiently evolve and adapt and strive to this day...
People had very different assumptions about the Internet and security. What was a federated protocol back than wouldn't be considered now. If that hypothetical evolution of IRC had happened, then I'm sure a s2s IRC protocol would emerge, but that's not a protocol problem, it's more fundamental than that.
It would have to influence the c2s protocol as well, e.g. the identity is tied to the service provider and it has to be communicated to other clients somehow to avoid collisions.
these days operating systems have better interfaces than select() so it's not for horizontal scaling, especially given each and every server has to maintain the full state of the network
The RFC ostensibly covers the server protocol too, but as-is, there are tons of extensions to make things actually work well (e.g. what happens on rejoin after a netsplit).
It's a bit sad IRC servers are no longer all the rage, because it would be interesting to see how good we could actually make them with current technology and programming practice. 1M+ users on a server should be easily attainable, for instance. And presumably a much more robust distributed system than just “connect them all in a spanning tree and accept any inconsistencies” (i.e., support redundant connections). I've seen a couple of times where A deopped B and B was still able to kick A (because they were on different servers), leaving the channel opless :-)
People like that are often still considered "technical" by the majority of people out there. Registering your nickname is still something that is more involved than sign up for any other web based chat service in the modern era.
Not to mention that people need to know about these are options.
You might scoff and roll your eyes, because to you, it seems easy. But I have seen it first hand for many years. Various online communities (forums, subreddits) I was involved in tried to set up chat side communities through IRC. They never really took of even with heavy promotion and sometimes nifty integrations with the accounts people already had.
Then Discord entered the scene, you only had to post a discord link. Because it was just one click the discord servers would often have more people in them in the period of week than the IRC servers ever had in years.
Er, yes - it's certainly true you can't use something you're unaware of.
Noting that I'm on lots of channels with lots of people that have never registered their nickname - agreed that it's seen as a necessity by many though.
I assume you mean the discords saw much higher levels of engagement. Just looking at numbers joined isn't the best comparison, I've seen many with huge member counts but only a handful of people interacting there (not that IRC is any different in that respect).
No scoffing or eyerolling here, I'm not suggesting it's easy.
I had been messing with game-related network protocols before writing my first IRC client, and the sheer simplicity of it was an eye opener.
For many protocols these days, the handshaking/authentication/formatting of the protocol and setting up a connection is so complex that you're already hundreds of lines down before you can do anything with the service, even if it's a dumb text chat like IRC is.
It's completely changed my view of what a network protocol is, and how to judge what features and characteristics are appropriate. Oftentimes this complexity is completely unwarranted! Underlying protocols like TCP and TLS already do a majority of the heavy lifting.
Personally, after implementing an IRC+XMPP server myself I became very disappointed by prevailance of HTTP-based protocols in everything. All software is so browser-based and/or browser-driven nowadays that HTTP became de-facto the only transport-layer protocol. This is just an additional abstraction and overhead over TCP/UDP, which we cannot remove at all.
Well, there are a lot of things one get for free by going over HTTP. Things like header parsing, widely-known status codes, handling of encoding and compression, connection reuse and upgrade, load balancing, caching, etc.
> Well, there are a lot of things one get for free by going over HTTP. Things like header parsing, widely-known status codes, handling of encoding and compression, connection reuse and upgrade, load balancing, caching, etc.
We should, but do we in practice?
Every so often it comes up that the status code is 200 but the body is {"error": "Internal Server Error"}
I've seen JSON Web Tokens used a lot in iOS apps over the last few years (cross platform products, so it makes sense to do whatever the web thing is), but I've never been clear how this isn't just reinventing the wheel over a normal cookie and HTTPS.
(How does caching work with HTTPS, anyway? I remember that being an argument against it back in the day, but I assume there's a solution now everyone's encrypting…)
> I've seen JSON Web Tokens used a lot in iOS apps over the last few years (cross platform products, so it makes sense to do whatever the web thing is), but I've never been clear how this isn't just reinventing the wheel over a normal cookie and HTTPS.
Why are you opposing JWTs and cookies/HTTPS? It’s common to set JWTs as cookies on HTTP(S). The benefit (and disadvantage!) of JWTs is that they contain the full state, so you don’t need a database to maintain it with a session identifier.
Ah, so it's for the benefit of backend. No wonder I didn't get it, being app-side.
(I wasn't "opposing" them with more boring forms of cookie, it just seemed like reinventing the same benefit but in a more complicated way; thanks for the explanation).
> (How does caching work with HTTPS, anyway? I remember that being an argument against it back in the day, but I assume there's a solution now everyone's encrypting…)
You use Cloudflare, and let them de-encrypt the user's data.
I feel like many of these things are a source of confusion, including headers and status codes. Others are not really are for free even with HTTP, e.g. load balancing, this is still very much service-specific.
UDP-based HTTP/3 could be considered a better transport protocol in the future with its multiplexing and lack of HOL-blocking, but right now it's still worse than TCP on stable connections
Funny, I did exactly what the article describes. When I was around 12 (previous century...) I learned a lot about coding from writing IRC bots in several languages.
In some ways things have become a lot easier, back in those days we had dial-up internet, no Stackoverflow and definitely no GenAI. But also harder, because protocols are now a lot more locked down, can't just sniff something and figure it out. And ecosystems like IRC have mostly been replaced by closed systems that you can't hack on.
I had lots of fun coding mIRC scripts, and then also some standalone IRC bots, when I was 14 or so (including an ambitious unfinished project of an IRC-based MUD, as well as a quite successful conversational chatbot that many people downloaded and used to fool others, especially with the option of posing as a girl which I added as an afterthought, but was what the overwhelming majority of users chose). I'm now a CS professor, and several others I know who had the same hobby at the time in my city or whereabouts have rather successful careers as tech entrepeneurs or professors :)
I paid the mIRC license like 15 years later, by the way... better late than never... that guy really deserved it.
I started writing bots and scripts in mIRC Scripting at around the same age, perhaps even a bit earlier. Back then, there were full-fledged bots (as in Nickserv, Chanserv, etc) for servers like UnrealIRCD that were entirely written in mIRC. I fondly remember those times as they were filled with lots of fun and opportunities to meet interesting people every day.
I did the same, writing IRC clients, bots and extension scripts from the age of 12.
Since you mentioned MSN, one thing I did in high school was connect an Eggdrop IRC bot via Bitlbee to MSN Messenger and hook it up with the MegaHAL module for text synthesis based on hidden Markov models. So basically, a chatbot on MSN. I trained it for a night to make it sound reasonable and respond well to various conversation, and I made it auto-accept connection requests and left it in training mode. Two weeks later, it was ruined. My kid sister's friends had all connected, and it now sounded like a 10 year old hyperactive psychopath. Strangely enough, it was a lot more authentic to them, since it spoke like them.
The first time I (gen z) had a run in with low-level tech was getting a Pi Pico and an ESP32 to talk to each other over the serial protocol. It's probably the only time I've had to get that down and dirty with a protocol. Writing messaging bots for modern apps are definitely fairly easy but it's unlikely you'd ever get that deep into the protocols of it all (probably something like json/graphql over http(s)).
IRC is a beautiful thing. I still write bots for it to unwind, the problem I have is the resistance to updating the protocol spec, some great ideas coming out but nothing seems to move fast enough these days.
(2011) that article. That's like 13 years old. I very well remember 13 years ago the FANG were not filled with middle managers like they are today. Massive cultural shifts in these places since then.
However actually establishing those DCC connections in the first place might need some configuration in a typical consumer internet setup?
I've been playing with the idea of adding IRC support to my prototype Matrix WebRTC transfer tool mxrxtx, but I haven't touched that for a while.. And I wouldn't have any use for it anyway.
When we have some more widespread IPv6 adoption we could (and should already) look into supporting IPv6 with DCC, that would make it function properly and dare-I-say would be excellent from a UX perspective.
with ipv6 there's still a firewall on the border router that will prevent incoming connections reaching your local machine's random ports
this is entirely a client problem, even with NAT there's no reason the IRC client couldn't do DCC using modern style hole punching (with the IRC server mediating)
But I'm hoping a future version of it would also solve some other scenarios, like when I share a file from a mobile to a room it would leverage an already running desktop session with better battery and better connectivity.
Another axis is providing a well-tested specficiations and providing it as a library that could be easily integrated into apps.
I have a TLA+ spec of the existing solution, so I hope the "next" version would also be as precisely specified, probably using Quint.
You don't actually need HTTP(S) to make use of WebRTC, though, if that's what you were implying.
For data transmission WebRTC layers on top of SRTP and the developer just needs to provide a way to pass the handshake data over some medium; could be an HTTP server, could be a Matrix room, could be an IRC channel (or PRIVMSG). And in the worst case it can also use STUN or TURN to solve the NAT issue which DCC makes zero attempts to.
Perhaps you can clarify what you mean by enshittification? I suppose the reality with NAT isn't the great, but it's not really about protocols but the way systems end up being built.
> You don't actually need HTTP(S) to make use of WebRTC, though, if that's what you were implying.
I wasn't aware that WebRTC can use other transports, but that wasn't the point. It was about the embrace-extend-extinguish of IRC protocol. I'm OK with embrace. I'm NOT OK with extend. It leads to extinguish.
> I suppose the reality with NAT isn't the great, but it's not really about protocols but the way systems end up being built.
How many GB of nodejs or some other crap need to be imported just to solve a NAT problem? It's just a text messenger FFS! Why can't you just document which are the incoming ports and let the user decide the forwarding or firewall setup, like we did for the last 25 years?? And why put WebRTC in a text messenger? That's for video calls.
You can use https://github.com/paullouisageneau/libdatachannel for your C/C++ integration needs. It's 10k lines. So the answer is 0. Its required dependencies (I assume this as they are git submodules in deps) are more than 100k lines, though, srtp support making the bulk of it. On my machine it took 11 seconds to compile it.
Irssi is 64k lines (plus its dependencies), so I guess that makes WebRTC complicated.
Can't argue that DCC isn't simple, but perhaps the protocol deviced decades ago is a bit too simple.
Each protocol serves a purpose - it's ORIGINAL purpose. To extend it like this means to degrade it's original usefulness, make it complicated to create new implementations and it won't even compete with a new protocol specifically designed for the new purpose. All this leads to "extinguish" phase.
IRC was implemented in probably hundreds of programs (many/most from scratch, not by importing the same library!). There's even an implementation for Arduino! It's a successful protocol as it is now. Could you run it on Arduino if it had WebRTC in it?
Probably not, but is it worth starting new projects with 16-bit MCUs in the year 2024? 32-bit MCUs are cheap and plentiful in offering.
I realize the IRC protocol is easy to implement (though the protocol itself has flaws that make it difficult e.g. to identify which message is a response to your query, IRC3 addresses this) and I too have done it in the past, but I see zero reasons to embrace it today.
The client receiving will connect to the one sharing the file. Routing the data through the IRC network would be unreasonable. This reveals your IP, which is kinda bad.
LoL... sharing your IP with a hacked server doesn't really affect me... but when I use magnets links from my home IP, I keep being harassed by Comcast.
Because I was maintaining some IRC bots, I knew the IRC protocol quite well back in the days.
I remember when I was about 12 years old...
The school computers were quite limited in terms of software and it was just not viable to download or install mIRC during a class.
So I fired up the telnet application to connect to the IRC network everyone at school used. The computer lab prof. was not impressed... Next class she told me that if something happened to the machines, she knew who did it... lol
* granted, we used a lot of colors / decoration (ctrl + K on mIRC) and while I was able to demonstrate my abilities it was not much practical as it was just too damn hard to read the messages quick enough.
IRC is not simple. Simple if you want to write a bot for a specific channel on a specific server, I suppose; but infuriatingly difficult to write a client for.
The curse of IRC: no standardization. There have been two major attempts to define a standardized version of IRC, neither of which has been successful, and neither of which are entirely adequate.
There are literally hundreds of messages, a large number of which are server-specific, and no two servers work remotely the same.
The protocol is also painfully bound to terminal-style user interfaces. Wrapping a clean graphical user interface around the protocol is difficult if not impossible. And any attempt to do so will require extensive customization for each server variant that the UI intends to support. And anything less than a clean wrap produces a user-interface that demands a sort of computer literacy that ordinary and casual users should not be expected to have.
Character set support is also fascinatingly and tragically broken. The ACTUAL official standard character set: Western European, with DEL replaced with an additional character to support Norwegian users. In practice choice of character set is cultural and varies from server to server, and from channel to channel. Some use Western European character codings, others use local or national codepages, many (but far from all) use UNICODE.
This might have been true some years ago, but I cannot agree with it now. There is a well-written IRCv3 spec, which I was following when implementing my own IRC server. I also tested it with several clients and I found out that core functionality and official extensions are pretty consistent. Bugs that I encountered always were a misinterpretation of the spec either by me, or by the relatively new IRC client that I was testing with, but they are fixed now.
The encoding is almost always UTF-8, I never encountered anything else on any network I used.
Yes, some networks may be stuck in the past, that's unfortunate, but the modern IRC is pretty good. Also custom extensions are not a problem since the capability negotiation was introduced.
> The encoding is almost always UTF-8, I never encountered anything else on any network I used.
Mainly because there are only a handful of living IRC networks anyway. Korean IRC networks are virtually vanished as of mid-2010s (and I operated one of last such networks), and while many have migrated to UTF-8, EUC-KR never died even at that point.
Honestly speaking, the modern IRC doesn't exist. The IRC today, which you refer as the "modern" IRC, is actually what IRC should have been at least a decade ago. Korean networks didn't even get to that point.
The thing is... most small or medium-sized channels are idle most of the time. Some then unidle for a bit if you wait e.g. a couple hours or even days. Even if there's no activity for months, if someone says something, someone may respond. Large channels are often quite active. Most channels have a topic of discussion, which can usually be inferred from the channel's name. If you like computers you may have a favorite programming language or whatever, and often there's a channel for it on chat.libera.org. E.g. #perl, #python, #c, #linux, #debian, #ubuntu, etc. (note, I'm currently on none of these). There's also channels for natural languages, electronics, etc. And most of the time the channel name is #WORD or ##WORD. Some of these channels are very active, some aren't.
Many mature channels have a group of regulars that have been part of the channel for years or decades. Many channels are a bit of a social club. Some channels have regulars that are insufferable.
> Many mature channels have a group of regulars that have been part of the channel for years or decades. Many channels are a bit of a social club. Some channels have regulars that are insufferable.
>> Many mature channels have a group of regulars that have been part of the channel for years or decades. Many channels are a bit of a social club. Some channels have regulars that are insufferable.
> Please share some examples.
Not the commenter you asked but the author of the original post here. I don't know about insufferable regulars but some channels like #emacs, #commonlisp, #esolang, etc. on irc.libera.chat do feel like social clubs but in a good sense. The same set of regulars can be seen everyday and people recognise each other by their nicknames. Further, I have found these channels to be very welcoming and kind to new members. Sorry I do not have examples of more "mainstream" channels that are also like social clubs and welcoming to new members. As an Emacser and Lisper myself, these are the channels I come across. But I am sure that "mainstream" channels which are social clubs and nice to new people do exist. Perhaps someone else can share some examples on this thread.
Now about regulars, many mainstream channels like #python, #rust, ##math, etc. have more or less the same set of regular and active members who answer on-topic/technical questions frequently. They don't exactly feel like "social clubs" to me. On the other hand they feel like small, tightly-knit, Q&A forums to me.
At some point though, IRC conversations seem to almost always turn into talking about IRC itself. Whether it’s bots or hostile takeovers, people stealing nicknames, moderation problems, who’s got the best client, and shit of that nature. I spent a lot time on it as a teenager, and it gets a bit old after a while. Discord is significantly better in that regard.
Irc is an old people thing now. And channel admin control is better.
Back when irc was the thing, there were a lot of teenagers on it and in some places the atmosphere was like in a modern competitive shooter if you take out all the "this is a violent game but we pretend it's family friendly" moderation.
There is a caveat, though. Like many older protocols (ftp) there is a lot that was not initially written down or left up to clients and server implementations. This, does lead to a lot of edge cases you need to be aware of once you want to actually support a wider user group.
Also, as this is apparently is still a discussion. IRC is not simple from a modern user UX perception. Registration can be complex and confusing, though hidden a bit through clients. Managing channels with various flags is a whole other thing. Then there is also the fact that these days people are no longer used to the fact that they can't see messages from periods where they were not connected. Of course, the latter can be easily handled by a BNC or fancy clients like https://thelounge.chat . But, that is only easy for technically inclined folks.