Simplicity of IRC (2022)
susam.net
susam.net
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.
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.
more for HA in face of DDoS :(
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 :-)
Non-technical people might use a TheLounge instance someone else hosts, a free/cheap bouncer, or (likely easiest) pay for a service like IRCCloud.
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.
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.
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.
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
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…)
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.
(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).
You use Cloudflare, and let them de-encrypt the user's data.
(I wonder if what I'm feeling is deja vu, or if you really did remind me of a previous time someone told me that…)
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.
Not sure it'll ever be the same for my kids. Which is a shame, whatever the gains and there are some, I think we've lost something.
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.
I paid the mIRC license like 15 years later, by the way... better late than never... that guy really deserved it.
Probably not valid anymore, fairly recently he changed something requiring a new license.
Not that he doesn't deserve a new license after all these years.
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.
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.
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.
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.
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.
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?
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.
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.
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)
Else the gamers and the people who rely on voip are going to go ballistic.
Though I would indeed like direct file transfer for more usual purposes in other chat clients. Would be great with Matrix/Element.
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.
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.
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.
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.
miss a lot the old days but the last time I tried every person seemed to be "idle"
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.
> 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.
What topics interest you? https://libera.chat/guides/findingchannels
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.