6 ms·

Simplicity of IRC (2022)

107 points by susam 3y ago

fddrdplktrew 3y ago
IRC is great and you can do SSL connections and also encrypted DCC transfers on some servers (Abjects/#moviegods, for example)
- _flux 3y ago
  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.
  - Arathorn 3y ago
    ooh, mxrxtx sounds interesting - is this solving https://github.com/matrix-org/matrix-spec/issues/189 https://github.com/matrix-org/matrix-spec/issues/189?
    - _flux 3y ago
      Yes, I think it solves that as-is. 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.
  - M95D 3y ago
    And this is how good old services, protocols and standards get enshittified. Welcome to HTTP(S) v121.99.5146.
    - _flux 3y ago
      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.
      - M95D 3y ago
        > 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.
        _flux 3y ago
        You can use https://github.com/paullouisageneau/libdatachannel 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.
        M95D 3y ago
  - dijit 3y ago
    That's mostly due to NAT. 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.
    - _flux 3y ago
      It could be the future—unless non-permissive firewall configurations ruin it.
    - blibble 3y ago
      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)
      - dijit 3y ago
        I disagree, anything that requires Peer-to-peer needs to be considered, so firewalls will always support some kind of upnp. Else the gamers and the people who rely on voip are going to go ballistic.
        blibble 3y ago
        both games and voip have used STUN for the past decade or so
  - fddrdplktrew 3y ago
    [dead]
- Avamander 3y ago
  Except it directly reveals your IP to the other peer. Might as well share a magnet link. Though I would indeed like direct file transfer for more usual purposes in other chat clients. Would be great with Matrix/Element.
  - fddrdplktrew 3y ago
    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.
  - weberer 3y ago
    You connect to a server, not a peer. Your client does no uploading.
    - Avamander 3y ago
      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. https://www.tg007.net/archive/tutorials/showdocca03.html https://www.tg007.net/archive/tutorials/showdocca03.html
    - crtasm 3y ago
      DCC stands for Direct Client to Client
bilekas 3y ago
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.
creesch 3y ago
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 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 https://thelounge.chat . But, that is only easy for technically inclined folks.
- lifthrasiir 3y ago
  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.
  - vilunov 3y ago
    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.
    - lifthrasiir 3y ago
      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...
8BitArmour 3y ago
This guy's article on infosys is good too: https://susam.net/infosys-tcs-or-wipro.html https://susam.net/infosys-tcs-or-wipro.html
- zer0tonin 3y ago
  It's funny how you could make almost exactly the same article about Google/Meta/Amazon
  - 8BitArmour 3y ago
    so,startups ftw?
  - mapreduce 3y ago
    (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.
    - zer0tonin 3y ago
      Yes, I can believe that the industry landscape has changed a lot in that time.
t0mas88 3y ago
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.
- cs02rm0 3y ago
  I did similar perhaps a touch later with some of the messenger protocols, MSN I think primarily. So long ago it's difficult to remember. 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.
  - sshine 3y ago
    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.
- outime 3y ago
  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.
- Al-Khwarizmi 3y ago
d--b 3y ago
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.
- wkat4242 3y ago
  That's not really my experience on libera. They are just about the projects.
  - nottorp 3y ago
    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.
rerdavies 3y ago
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.
- vilunov 3y ago
  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.
  - lifthrasiir 3y ago
    > 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.
hideout_berlin 3y ago
still love irc
boredemployee 3y ago
could someone point me a good and active irc server and (possibly) channels? miss a lot the old days but the last time I tried every person seemed to be "idle"
- qiqitori 3y ago
  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.
  - gaws 3y ago
    > 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.
    - susam 3y ago
      >> 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.
mid-kid 3y ago
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.
- vilunov 3y ago
  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.
  - kqr 3y ago
    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.
    - vilunov 3y ago
      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
    - ben_w 3y ago
      > 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…)
anthk 3y ago
Netcat as an IRC client: http://morena.rest/20230501 http://morena.rest/20230501
- henvic 3y ago
  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.
deleted 3y ago
[deleted]

107 points by susam 3y ago

IRC is great and you can do SSL connections and also encrypted DCC transfers on some servers (Abjects/#moviegods, for example)

_flux 3y ago
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.
- Arathorn 3y ago
  ooh, mxrxtx sounds interesting - is this solving https://github.com/matrix-org/matrix-spec/issues/189 https://github.com/matrix-org/matrix-spec/issues/189?
  - _flux 3y ago
    Yes, I think it solves that as-is. 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.
- M95D 3y ago
  And this is how good old services, protocols and standards get enshittified. Welcome to HTTP(S) v121.99.5146.
  - _flux 3y ago
    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.
    - M95D 3y ago
      > 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.
      - _flux 3y ago
        You can use https://github.com/paullouisageneau/libdatachannel 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.
        M95D 3y ago
- dijit 3y ago
  That's mostly due to NAT. 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.
  - _flux 3y ago
    It could be the future—unless non-permissive firewall configurations ruin it.
  - blibble 3y ago
    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)
    - dijit 3y ago
      I disagree, anything that requires Peer-to-peer needs to be considered, so firewalls will always support some kind of upnp. Else the gamers and the people who rely on voip are going to go ballistic.
      - blibble 3y ago
        both games and voip have used STUN for the past decade or so
- fddrdplktrew 3y ago
  [dead]
Avamander 3y ago
Except it directly reveals your IP to the other peer. Might as well share a magnet link. Though I would indeed like direct file transfer for more usual purposes in other chat clients. Would be great with Matrix/Element.
- fddrdplktrew 3y ago
  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.
- weberer 3y ago
  You connect to a server, not a peer. Your client does no uploading.
  - Avamander 3y ago
    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. https://www.tg007.net/archive/tutorials/showdocca03.html https://www.tg007.net/archive/tutorials/showdocca03.html
  - crtasm 3y ago
    DCC stands for Direct Client to Client

bilekas 3y ago

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.

creesch 3y ago

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 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 https://thelounge.chat . But, that is only easy for technically inclined folks.

lifthrasiir 3y ago
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.
- vilunov 3y ago
  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.
  - lifthrasiir 3y ago
    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...

8BitArmour 3y ago

This guy's article on infosys is good too: https://susam.net/infosys-tcs-or-wipro.html https://susam.net/infosys-tcs-or-wipro.html

zer0tonin 3y ago
It's funny how you could make almost exactly the same article about Google/Meta/Amazon
- 8BitArmour 3y ago
  so,startups ftw?
- mapreduce 3y ago
  (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.
  - zer0tonin 3y ago
    Yes, I can believe that the industry landscape has changed a lot in that time.

t0mas88 3y ago

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.

cs02rm0 3y ago
I did similar perhaps a touch later with some of the messenger protocols, MSN I think primarily. So long ago it's difficult to remember. 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.
- sshine 3y ago
  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.
outime 3y ago
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.
Al-Khwarizmi 3y ago

d--b 3y ago

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.

wkat4242 3y ago
That's not really my experience on libera. They are just about the projects.
- nottorp 3y ago
  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.

rerdavies 3y ago

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.

vilunov 3y ago
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.
- lifthrasiir 3y ago
  > 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.

hideout_berlin 3y ago

still love irc

boredemployee 3y ago

could someone point me a good and active irc server and (possibly) channels? miss a lot the old days but the last time I tried every person seemed to be "idle"

qiqitori 3y ago
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.
- gaws 3y ago
  > 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.
  - susam 3y ago
    >> 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.

mid-kid 3y ago

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.

vilunov 3y ago
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.
- kqr 3y ago
  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.
  - vilunov 3y ago
    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
  - ben_w 3y ago
    > 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…)

anthk 3y ago

Netcat as an IRC client: http://morena.rest/20230501 http://morena.rest/20230501

henvic 3y ago
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.

deleted 3y ago

[deleted]