IRC is antiquated in most of the ways that matter, but there's one thing it has that I continue to miss in every other chat platform I've had to use: painless automation.
I spend a lot of time in Slack for work, and maybe half of that time is manually connecting pieces of data (who should I ping for a review on X? what's Y's email address or other contact information?) that I could trivially script with an IRC bot that listens for prefixed commands. I know I can do that with Slack Apps (or whatever else), but just looking at them gives me anxiety: there's tokens, and webhooks, and all kinds of ambiguously permanent or ephemeral state that's going to eventually break or expire. IRC bots, by contrast, have virtually no cognitive overhead: the only moving parts are the socket, and maybe a username and password for server authentication.
Ultimately, the tradeoffs are probably the right ones. But whenever I find myself chatting on IRC outside of work, I can't help but think of what would be possible if our "serious" chat services were just a little more hackable.
Kinda stating the obvious here but most of the mental overhead you feel with Slack Apps comes from a long list of Enterprise concerns that needed to be addressed.
If you just want to build a poc Slack won't keep you from creating an app manifest with all the permissions and be done with worrying about them.
Also all those public APIs are designed to be fairly permanent.
Can't compare it to IRC obviously but I wouldn't worry too much about stuff being deprecated all too quickly.
I work at Slack and frequently build automations for our customers so I'd love to hear about particular annoyances from the perspective of an old school IRC user.
I think part of what keeps me from getting too personally invested in Slack (or Discord. Or any other commercial chat platform) is that I've seen so many commercial chat platforms come and go over the years (I think my company has averaged 3 years per platform so far), while IRC is older than I am. I just don't expect any commercial chat platform to have a real long-term future because of the financial friction in keeping it running. But who knows, I grew up alongside computers so maybe the past thirty-something years were just the growing pains and Slack will be "it" for companies for the next thirty years.
Yeah, in their appropriate contexts I'm sure they all make perfect sense! I'm also glossing over quite a bit -- my company has security policies that we enforce on Slack as well, and it's perfectly reasonable for those policies to also complicate custom automation.
I think my biggest gripe is just the amount of state I feel like I need to be aware of. With IRC, I can throw together a bot using either a raw socket or a mature bot framework in an hour or two because there's no real "remote" state for me to think about; I'm just in the flow of editing the source code. With Slack (or any chat app, really), I feel like I context switch much more frequently (more things are full-fledged APIs instead of just string munging, I missed a scope, etc.).
I have a wide selection of clients for IRC, with varying levels of features (including client-side automation scripting), performance, and platform support. I'm annoyed that I have to use a GUI at all, or even worse, an Electron app.
Does that do requests asynchronously now? For a long time it would stall the whole client every time the slack API had issues (which was quite a lot more times than their status board suggested).
At some point it got so bad I had to stop using it - I have switched to matterircd now (it also does slack).
I never noticed that. I have key bindings for moving through the channel list, and movement is not blocked while the channel content is loading, so I guess it's not blocking?
Yeah, exactly. Those IRC bots work by reading EVERY chat message and looking for commands. Not exactly minimum permissions philosophy, and likely not acceptable liability and auditability wise for what is very specifically intentioned to be corporate software.
I'm not going to claim that IRC's permission model is good (it definitely isn't), but "EVERY chat message" is inaccurate in most deployments: you generally pick the channels you want the bot to be in, and prevent it/others from joining other channels. That's no different in effect from a Slack bot that's receiving webhook events on every channel message and scrubbing through them, which is also a common pattern.
Unless the IRC bot is a service like ChanServ it's just another IRC client. It's only receiving messages from channels it has joined or private messages sent directly to it. A bot is receiving what you would receive if you joined the same channels.
The problem is everyone is making a product not a protocol. Slack,discord,matrix they all care about having thie feature and that feature instead simple e2e encrypted plain text messaging.
That said, depends on what you mean my hackable. Python and restful api can be much easier to work with and hack than IRC because with IRC if you don't use a library you still have to account for various scenarios and do quite a bit of parsing and server specific command handling.
There is no “simple e2e encrypted messaging protocol” ;) the protocols used by Signal, WhatsApp, etc are very well thought out but they aren’t “simple” because keys are changed on every messages and both peers need to maintain and manage keys. With group chats the situation is even more complex. And making group chats with a large number of users (this is what IRC does btw) work well is a very complex technical problem.
TLS isn't simple but you still use it with IRC. Libolm/e2e is the session layer not the application layer. Why is there no library that handles key management,session handling,etc... for you and all you have to do is make a library api call similar to TLS with the destination, encoding and message size limit details as a parameter and each send() operation requiring a recipient so the library can handle the auth/encryption? Can you not do that with libolm? Why can't you use IRC on top of such a library then similar to how you would with TLS?
Using IRC without an IRC client doesn't seem very hard to me:
$ telnet irc.libera.chat 6667
Trying 2a01:270:0:666f::1...
Connected to irc.libera.chat.
Escape character is '^]'.
:lead.libera.chat NOTICE * :*** Checking Ident
:lead.libera.chat NOTICE * :*** Looking up your hostname...
:lead.libera.chat NOTICE * :*** Couldn't look up your hostname
:lead.libera.chat NOTICE * :*** No Ident response
user ircuser host.example.com irc.libera.chat :ircuser anon2317
nick anon2317
:lead.libera.chat 001 anon2317 :Welcome to the Libera.Chat Internet Relay Chat Network anon2317
...
:lead.libera.chat 376 anon2317 :End of /MOTD command.
:anon2317 MODE anon2317 :+iw
join #matrix
:anon2317!~ircuser@2800:[censored] JOIN #matrix
:lead.libera.chat 332 anon2317 #matrix :The Official Matrix HQ - chat about Matrix here! | https://matrix.org/docs/spec | To support Matrix.org development: https://patreon.com/matrixdotorg | Looking for hosting? Check out https://upcloud.com/matrix! | Code of Conduct: https://matrix.org/legal/code-of-conduct/ | This is an English speaking room |
:lead.libera.chat 366 anon2317 #matrix :End of /NAMES list.
privmsg matrix :hello, I am using IRC with telnet
:lead.libera.chat 401 anon2317 matrix :No such nick/channel
privmsg #matrix :hello, I am using IRC with telnet
privmsg #matrix :this is probably a little harder than using Matrix with cURL?
privmsg anon2317 :hello myself
:anon2317!~ircuser@2800:[censored] PRIVMSG anon2317 :hello myself
privmsg anon2317 :the #matrix channel seems a bit quiet
:anon2317!~ircuser@2800:[censored] PRIVMSG anon2317 :the #matrix channel seems a bit quiet
list -min 300
:lead.libera.chat 321 anon2317 Channel :Users Name
:lead.libera.chat NOTICE anon2317 :Invalid parameters for /LIST
:lead.libera.chat 323 anon2317 :End of /LIST
list -minusers 300
:lead.libera.chat 263 anon2317 LIST :This command could not be completed because it has been used recently, and is rate-limited.
:lead.libera.chat 323 anon2317 :End of /LIST
:dsrt^!~dsrt@[censored].hsd1.ga.comcast.net JOIN #matrix
mode #matrix
:lead.libera.chat 324 anon2317 #matrix +Cnt
:lead.libera.chat 329 anon2317 #matrix 1621432229
privmsg #matrix :hi dsrt^, how are you?
privmsg alis :help list
:alis!alis@services.libera.chat NOTICE anon2317 :***** alis Help *****
:alis!alis@services.libera.chat NOTICE anon2317 :
:alis!alis@services.libera.chat NOTICE anon2317 :Help for LIST:
:alis!alis@services.libera.chat NOTICE anon2317 :
:alis!alis@services.libera.chat NOTICE anon2317 :LIST gives a list of channels matching the
...
:milkt!~debian@gateway/tor-sasl/milkt QUIT :Remote host closed the connection
privmsg alis :list * -min 300
:alis!alis@services.libera.chat NOTICE anon2317 :Returning maximum of 64 channel names matching '*'
:alis!alis@services.libera.chat NOTICE anon2317 :##chat 445 :Welcome to ##chat, a social and offtopic channel for sensible conversations. Mind the language. | THIS IS A POLITICS-FREE ZONE! You have been warned. | Rules: https://pastebin.com/raw/ntTcx2xb | We reserve the right to remove annoying people | Free Speech: https://xkcd.com/1357/ | In case of PM spam, '/mode your_nick_here +R'
:alis!alis@services.libera.chat NOTICE anon2317 :##electronics 484 :http://electronicschat.org | Introductory electronics eBook: http://www.ibiblio.org/kuphaldt/electricCircuits/ | Battery information: http://batteryuniversity.com/ | Soldering: http://tinyurl.com/y8p8lfp9 | Welcome to electronics! | <HexaCube> maybe i can afford a beard implant soon | tawr> oh no, i just found out how dumb i am
...
join #chat
:lead.libera.chat 470 anon2317 #chat ##chat-overflow :Forwarding to another channel
:anon2317!~ircuser@2800:810:473:10f1:711f:4bae:293e:3a03 JOIN ##chat-overflow
:lead.libera.chat 332 anon2317 ##chat-overflow :If you find yourself here trying to join ##chat, please identify and try joining ##chat again (reference '/msg nickserv help identify' and/or '/msg nickserv help register' for assistance). This is to help curtail spam, we apologize for the inconvenience | SASL is preferred https://libera.chat/guides/sasl
...
part ##chat-overflow
:anon2317!~ircuser@2800:810:473:10f1:711f:4bae:293e:3a03 PART ##chat-overflow
join ##electronics
:lead.libera.chat 477 anon2317 ##electronics :Cannot join channel (+r) - you need to be logged into your NickServ account
join #c
:anon2317!~ircuser@2800:810:473:10f1:711f:4bae:293e:3a03 JOIN #c
:lead.libera.chat 332 anon2317 #c :C Programming Community | Paste (>3 lines): https://bpa.st/ or http://sprunge.us/ | Wiki: http://www.iso-9899.info/ | Books: http://www.iso-9899.info/wiki/Books | C2X Charter: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2086.htm | Standard: http://iso-9899.info/wiki/The_Standard | Off-topic: #c-offtopic | C11 trivia game: #c-jeopardy
:lead.libera.chat 333 anon2317 #c pragma- 1634682891
...
:lead.libera.chat 366 anon2317 #c :End of /NAMES list.
privmsg #c :hi there. I wrote this Karplus-Strong string-instrument synthesizer in one line of C: s[72]={512};main(i){for(;;i%=72)s[i]+=s[(i+1)%72],putchar(s[i++]/=2);}
privmsg #c :is this valid in ANSI C?:twkm!twkm@rfc1459.net PRIVMSG #c :wow, 1 line!
privmsg #c :You can pipe :sysRPL!~sysRPL@[censored].res.spectrum.com PRIVMSG #c :i think i got it .... cmake -DWIN32=1
its output to aplay on Linux
:twkm!twkm@rfc1459.net PRIVMSG #c :not i.
:sysRPL!~sysRPL@[censored].res.spectrum.com PRIVMSG #c :.. /usr/bin/x86_64-w64-mingw32-ld: cannot find -ldl ?
:sysRPL!~sysRPL@[censored].res.spectrum.com PRIVMSG #c ::(
:twkm!twkm@rfc1459.net PRIVMSG #c :you might need to compile it, or install it.
:progandy!~progandy@user/progandy JOIN #matrix
PING :lead.libera.chat
:sysRPL!~sysRPL@[censored].res.spectrum.com PRIVMSG #c :twkm: can you help me fix the error i posted above?
PONG :lead.libera.chat
:sysRPL!~sysRPL@[censored].res.spectrum.com PRIVMSG #c :i am trying to cross compile on linux to create a windows static library
:sysRPL!~sysRPL@[censored].res.spectrum.com PRIVMSG #c :using mingw ... but it looks like it's trying to use the linux dl library
privmsg #c :hmm, that sounds like it won't work :)
privmsg #c :I don't have any experience getting CMake to use mingw
:Viscometer!quassel@gateway/vpn/airvpn/viscometer JOIN #matrix
:sysRPL!~sysRPL@[censored].res.spectrum.com PRIVMSG #c :i am going to hate having to setup a windows computer to get this to build
privmsg #c :hmm, has nobody really ever gotten CMake to cross-compile things?
:sysRPL!~sysRPL@[censored].res.spectrum.com PRIVMSG #c :sure they have i am sure
:sysRPL!~sysRPL@[censored].res.spectrum.com PRIVMSG #c :the glfw even has a mention of it
:sysRPL!~sysRPL@[censored].res.spectrum.com PRIVMSG #c :unfortunately it's just a mention, not a guide
It's a little verbose, but the only really tricky part is that you need to answer pings within four minutes or you ping out, and other people's messages may appear in the middle of the line you're typing. (It's helpful to know that ^R redraws the line. Better still, use Emacs shell-mode.) And you need to know the USER and NICK commands, and type or paste them before the server times you out. Oh, and if you leave out the colon, only the first word of your message gets through, which is pretty confusing to figure out if you don't have another client on the same channel.
What does it look like to have a Matrix conversation with curl in a terminal?
One aspect I don't see mentioned much, if at all, is that the "C" in "IRC" stands for "chat", and that, to me, has always equated to in-real-life chats.
If I'm not present when friends are chatting I don't get to replay what they were saying before I arrived, or after I leave.
I think that is the fundamental disjoint - features are attributed to IRC that were not intended, and then attempts to bolt them on through services, bouncers, or whatever, is never going to create a seamless rich experience that many seem to want.
For me, IRC has always been the avenue for mostly throwaway, real-time at-this-moment off-the-top-of-my-head stream-of-consciousness discussion, with Usenet or forums and email mailing lists for more long-running considered and logged discussions.
I've never been impressed or attracted to products that try to force the two styles together.
Disagree. 15+ years ago, people used IRC in real time, to chat and hangout online. Async chat sucks, plus we had forums for that kind of thing.
More recently, I've contributed to a number of open source projects that have live chat meetings on IRC. We kept logs of those meetings, but live chat is totally the point.
I disagree when considered in the context of what we use IRC for 'traditionally' - hundreds of people able to share logical information, code, URLs, and more particularly on a very low bandwidth medium.
Can't do that in voice chat.
In the usual case of IRC channels the contributors are in the minority and so it can take the form of a voyeuristic learning experience for the passive bystanders - and very highly educational most of the time.
I can’t think of a single use where I need ultra low data transfer and can’t accept chat backlogs. It’s no wonder IRC usage is in constant decline when that is the target user.
The low data transfer bit is probably mostly irrelevant these days, though I would imagine that it would be useful for people with minimal mobile data plans.
As for chat backlogs, your client can log communications while you are online. Some people find that more desirable since they always know who they are speaking to. That is especially important since anyone can join an open channel at any time. If something that you found interesting came up on a channel you frequented, but while you were not in the channel, someone would copy it from their scrollback buffer for you (often without your even asking).
That being said, I doubt those two criteria define the target audience. As the author notes, IRC is great because its simplicity offers a great deal of flexibility. Anyone could make an IRC client or bot with minimal effort. Even for those who do not write software, it is advantagous. There were many IRC clients because of that, meaning one could choose a client that reflects their needs and tastes. The problem is that most people want something that is easier to use, and for most people that means they don't want to deal with choosing a client nor do they want to deal with setting up their client (notably, selecting a server).
IRC may be simple but there were massive amounts of pain back in the early days.
If you joined a server that was temporarily disconnected from a peer, you could get operator status on an empty channel that then carried over when the server reconnected to the larger network.
Chanserv/Nickserv are bolted on solutions for any kind of permanence. Messages delivered late are not recognizably late. There’s no threading etc.
What I thought worked remarkably well, however, was the loose structure formed by students/employees who were in charge of their university or ISP hosted server. They weren’t given heavy scrutiny but still had some accountability to a larger organization. It somehow bridged the gap between complete independence and central control.
I loved using IRC up to around 2016 or so. The main annoyance was that it fails to deal with mobile networks. Newer instant messengers allow you to see conversations you missed, something that also makes it hard to go back. I've yet to try Matrix, as Discord is all right for the time being. How does it handle these issues?
EDIT: Also, how does Matrix handle large communities? I'm interested not just in the user side but the moderator side of things.
Matrix syncs a buffer of messages and scales to large rooms of hundreds of people without issues in my experience.
Importantly it manages to do this while supporting end to end encryption giving you high privacy in DMs, and high anonymity Signal etc can not match due to phone and phone number requirements.
Also Matrix bridges well to other networks. I have several slacks bridged to mine so I only need to use Matrix. Think of a messenger and there are one or more bridges for it.
Supporting matrix also means supporting open software and networks, unlike proprietary walled gardens like Discord that can at any time leak or monetize your chatlogs.
Indeed. In the decentralised spirit of IRC, if you want a client to maintain a persistent connection and/or log while you're away, you need to run one yourself.
You don't have to run one yourself. Some networks like Rizon provide bouncers themselves. Otherwise there are a few third-party-hosted bouncers like chat.sr.ht. But yes, self-hosting is always an option.
That said, having set up self-hosted ZNC (the de facto IRC bouncer) last week, it's a damn PITA if you want the same experience as what you get with newer messaging stacks.
First, the default operation of ZNC is to replay the last lines from the client buffer regardless of whether your client already has them or not. To work around that, you have to install the non-built-in "playback" module. The OS I run ZNC on (Debian 11) doesn't package that, so it needs to be compiled from source with znc-buildmod, which means installing a C++ compiler. This also makes auto-updates harder because the module has to be recompiled out-of-band every time the ZNC package is updated by the package manager.
Second, the playback module uses a ZNC-specific capability which your client may not have support for, in which case you'd need a script to work with it.
Third, the playback module only operates in terms of server time. Your client asks the bouncer to replay all messages since timestamp T, where T is presumably the timestamp of the last message you received from the bouncer before the disconnect. But because of precision errors, this ends up replaying the message you received at time T, the one you already have, so your client ends up getting that message duplicated.
If you were to artificially add some milliseconds to T to work around that, you could miss out on any other messages that did occur in that time, so that's not a good solution. (Message loss is worse than duplicate messages, especially when the point of setting up a bouncer is to not have message loss.)
IRCv3 doesn't fix it either. The IRCv3 version of the CAP allows the server (bouncer) to implement either server time or "message IDs" or both. Message IDs would indeed solve this problem, but since server time is an option you can expect bouncers to only implement server time and not message IDs. Indeed, from a brief glance at the ZNC playback module code it seems ZNC itself makes it hard to add message ID support to that module, and even the new soju bouncer only supports server time.
Another alternative to the classic bouncers is using quassel or weechat-relay.
Both have the core running on a server and both use a custom protocol to the clients, which allows you to have multiple different clients (desktop, mobile) connected with synchronized history.
Of course this limits the choice of available client software by a lot, but it's an option to keep in mind.
If you want to package and maintain znc-playback for Debian, I'll be happy to sponsor it for sid and backports. I expect that we can come up with some mechanism to solve the auto-update issue, although I notice there aren't any third-party ZNC plugins in Debian yet, so we will probably need to talk to the Debian ZNC maintainer about it. Either go through the normal procedure for new packages and I'll notice the request for sponsor mail, or just contact me directly.
I had never heard of one, so I never used one. I also would have thought of leaving my computer on all day just for IRC as ridiculous. I imagine I can't be alone with that, the simplicity of IRC has its costs.
The Matrix homeserver that you have an account on acts like an IRC bouncer by default. The homeserver maintains your presence in the rooms you joined, and receives and persists events from those rooms, regardless of whether you currently have a client connected to that homeserver or not. When your client connects to the homeserver again, it can ask the homeserver for new events since the last event it has.
I mean, the protocol may be simple, but the UX is anything but. I've been around the block, but I find IRC incredibly opaque. Don't want to miss messages? You need a bouncer, which means you need a server somewhere, and then this pretty much sums that up: https://news.ycombinator.com/item?id=32326145. Registering nicknames on a server and reconnecting to them reliably so I get a consistent username is something I never managed. And the list goes on and on... I managed to use it, but "simple" is not the word I would use to describe the experience.
To hopefully short-circuit a lot of pointless endlessly rehashed debate:
Things IRC is better at:
– being light weight (both server and clients)
– being an open standard
– horizontal scaling
– simplicity (talk to it over telnet if you want)
Things every other modern messaging solution is better at:
– name and channel management
– permissions that are more granular than ability to access a channel or not
– non-textual content (images/video/emoji)
– rich text (HTML/markdown/syntax highlighting/typefaces/fonts)
– one to one/many to many calls and meetings in a world with everyone behind a NAT and middleboxes
– file transfers
– screen sharing
– mobile connectivity
– threading
– message history/ability to receive messages while not online
– aesthetics and UX (most IRC clients resemble TUI apps)
– accurate presence (whether a given person is actually available or not, attempts to paper over missing IRC features with things like bouncers usually break this and the offered features are usually more granular than connected or not connected)
– extensibility (/commands and "chatops")
– abuse control and prevention
Things that do not matter to the world at large:
– That you personally are not a fan of the modern solutions and/or find them distracting
– That modern messaging solutions are centralized rather than distributed
– That a new IRC standard is on the way that addresses most of IRC's deficiencies… Two decades too late.
– Privacy policies and TOSes that allow platform owners to target ads at users or "sell their data"
– That a variety of clients for each service is not available
– The availability of and license to the source code for the
client and server
Reasons why (insert name of decentralized project) is unlikely to displace the centralized incumbents anytime soon:
– Their UX is worse or they are lacking a significant number of features
– Users don't want to run servers or deal with technical minutia, and the alternative requires these
– The problems this project solves are mostly on the list of things that do not matter to the world at large
The debate is just team sports at this point. The camp that likes IRC likes IRC. The camp that doesn't like IRC doesn't like IRC. In 2022 I doubt there's going to be someone who re/discovers IRC as the next big thing. It always gets upvotes here because there's overlap between the vocal i-detest-social-media crowd and the IRC crowd.
I'd also add that IRC is very easy to write a client for, especially if you're in a language without too many niceties, like an HTTP client library. As long as you can open a TCP socket and read/write from it, you can make an IRC client.
Indeed. My comment reached -4 quite rapidly, without a single rebuttal given.
I say all of these things as someone that generally likes IRC. I have lots of good memories of it. But I also like plenty of other retro things, and the list of things that IRC does worse than everything else is long, objectively definable, and worst of all: ever-growing.
Generally speaking, choosing IRC as your messaging tool is doing a disservice to both yourself and your users. There are better tools for nearly every use case.
The initial version of your comment essentially stated that rebuttals are not welcome (still kinda does, since the stated goal is to avoid rehashing old discussions).
But just to give you some kind of rebuttal (or mention some unmentioned points by you): IRC has native clients for many more operating systems than any alternatives (many don't even have any native clients at all!). IRC will still work when everything is very broken (DNS on fire, AWS having a moment, ..) and I think a fair few still use it for that reliability aspect. UX is very much in the eye of the beholder. Chatops is very much a thing in IRC as well as adding commands to it (just with ! instead of /).
Yes, which is why I reworded it. The score continued to decline.
Honestly, everything I've posted here is a list of facts. I'm more than willing to entertain being wrong on one or more of them, but as far as I can tell those facts are not actually in question.
Regarding your edit, that could be seen as a benefit that IRC has, but right there with that would have to be "native clients" on the list of things that most people don't care about. The hatred of non-native packaged web apps is mostly a techie thing that doesn't exist outside of forums like HN. In a world where electron didn't exist, there would be a world with less platform support, not a world with more native apps.
I would actually still disagree a lot here, since a lot of the points you list under "Things every other modern messaging solution is better at:" for example is either things IRC has had forever (more fine-grained permissions and authentication; file transfers; abuse control and prevention; extensibility of all things.. nothing beats IRC here), that are really in the eye of the beholder (UX) or are things that not even most modern solutions have (threading; actual file sharing (good luck with large files); screen sharing) - some may have some subset of the features, but I don't think all of them have all of them.
Fair point that the non-native apps are something people don't actively think or care about (even if it's the cause their battery is flat all the time). It's just personally I want to avoid applications that use a significant fraction of my ram and cpu just to display 10 lines of text.
You'll have to note that the second part of the list is not just "things that that IRC doesn't have", it is "things that other stuff does better".
You mentioned file transfers; when's the last time you tried to do anything with DCC? NATting makes that a nonstarter in 2022. What abuse control does IRC give you aside from the ability to block a user (or more accurately, block a host mask, which is probably not even accurate since most servers these days hide those)? Meanwhile over on Discord, I can set it so people can't even message me without adding me to a friends list and me accepting. If someone on IRC wants to make my session unusable, it is not all that hard to do and my options are severely limited.
Discord and Slack and Teams all do threading, file sharing, screen sharing, and I'd be willing to bet that's the top three in the space. I'm not going to entertain the "actual" filesharing Scotsman, you drop the file onto the window and it is made available, which is good enough for most use cases. Not all or most are sharing multi-gigabyte database dumps.
Hard disagree on extensibility. If I want to integrate with discord or slack I don't even have to maintain a client with associated state anymore, I can just provision /commands that callout to a web service. And yes, with modern tooling, I'd rather be speaking HTTP with all the niceties that come with that for free rather than blasting telnet messages over a socket.
Hard disagree on permissions as well. Something like the permission hierarchy on Discord goes as far as command usage and who can even see a channel, and who can be directly notified, not just who can speak or who can kick other people. IRC is objectively more limited in that respect.
I think the main issue is that you wrote "every" there, instead of some, which would have been fine/correct. And that a lot more things in IRC are possible than you realize and some of the modern solutions are somewhat more limited than you state.
Is NAT still a thing in 2022? With IPv6 at home not really an issue anymore (which neither slack nor discord seems to support either...).
Also in the corporate use-case it's not really an issue either.
And wanting to share rather large files is not as obscure of a use-case as you make it out to be (even outside of work!). Of course it's a distribution of sizes and it's nice that the low to mid is covered, but would be nice to have it fully covered.
Every IRC client has ignore and depending on the client that can be very advanced with support for regex and more (slack doesn't have that at all; Discord only has all or nothing blocking; matrix depends on the client; not sure about other solutions).
A lot of the abuse control is server/network side (the same really as with discord, etc.) and really works rather well these days (I see as much/little spam on libera/oftc/.. as I see on slack or discord.. if even that). I would argue it works even better, since Discord has to resort to phone activation to combat spam, while well-run IRC networks manage to be just as spam-free without collecting any email or phone numbers (and just with server-side filtering and other behind the scenes tricks) or without being invitation-only for the most part (which does quite a bit of the heavy lifting as well - which you could do on IRC as well if need be). Some more capabilities very much depend on the network, but you can also limit who can send you privmsgs (for example on libera: everyone; only registered users; only users that share channels; only users that you have explicitly/implicitly allowed). Blocking by registered user names is also possible on many IRC networks - no need to rely on host masks.
If there are things that can be added or improved to improve moderation, people do add them over time - although not in any standardized way, I'll give you that.
Channel operators have more than enough tools at their disposal to moderate discussion and writing IRC bots to do more things that the network doesn't happen to support is trivial.
Modern tooling doesn't always mean better or easier - Getting slack integration to work was so much more pain than hacking up a simple IRC bot to do the same thing.
Great summary. The one thing I would add in favour of IRC was its main use case, which was pseudonym to pseudonym communication. It is similar to HN's light pseudonym identity that allows for just enough candidness (canditity? candidosity?) without having to support features for complete fugitives.
For Matrix channels to succeed, they need a culture around them, and the semi-criminal world of hacking back in the day is what led to its growth, imo. I remember one day someone very smart said, "stop using silc," where the implication was it was compromised in a very intentional way, and a lot of people dropped it and went back to irc.
It's hard to think of a subculture now that would facilitate that. IRC was the effect of the internet being novel. If you have a subculture, the effort to prevent it from being brigaded is going to come at a cost of organic growth. To get Matrix off the ground, you would need new tech with a lot of upside in front of it, like blockchains, maybe CRISPR, drone racing, analog/quantum computing, day trading, maybe a new musical form, something with a physical competence as a bar. I don't think the gap is in the tech, it's in the lack of diversity in what people physically do anymore.
The only time I would personally choose IRC is if my use case targeted retro systems with limited CPU/ram/network connectivity, or I am integrating with something that uses IRC for some reason (like the back end for Twitch chat).
If I actually cared about decentralization above other concerns, my next choice would be Matrix.
For literally all other use cases, I would be on Discord or Slack. Users are likely already familiar with it, likely already use one or both, and I'll have to answer a lot fewer technical questions.
My approach is irssi in tmux on a server. A full real client always running, used via ssh, same experience on a phone or computer. As a bonus I have a lot of power I wouldn't have in a separate phone app. I can search my logs at the source with less, grep, etc. I can copy lines of scrollback with tmux copy mode, I can use all my irssi aliases and scripts to do things like send delayed messages and set reminders or print out what song I'm playing or what the weather is. My email client and torrent client are accessible in the same tmux session. It all just works quite well no matter how I'm connected.
I hear a lot of bad things about configuring bouncers (mostly znc), and have been told before by a friend that he didn't get all the lines I sent while he was asleep because I sent too many or whatever other reason. Bouncers largely seem jank. My irssi + tmux setup makes sense to me and has no nasty surprises.
I get that to the average person this setup probably seems insane, but if you already have a computer locally or remotely that you leave on, I would recommend it. (optionally substitute irssi for weechat and/or tmux for gnu screen, I just use what I like)
Switching gears slightly, I just wanna say that I use IRC, XMPP, and Matrix on a daily basis. IRC continues to be my favorite overall, and has the best clients by far. XMPP and Matrix don't get logging right, don't get chat sorting right, don't get extensibility right, and they just actually crash on me more than most other software I use, oddly. I've heavily used Dino (past), Gajim, and Conversations for XMPP. For Matrix I've tried a lot, but mainly I now use nheko on my PC and element on my phone (I have fluffychat too, but it doesn't seem dramatically better).
Alternatively, I just have weechat in a tmux on a super cheap digitalocean instance. Easy to SSH and attach to the tmux session as needed, although I've been meaning for years to use Mosh instead of SSH for easier connectivity.
I also think that IRC is better than the other protocols for these reasons, and I had also used nc, telnet, etc. IRC has the advantage, you can use the IRC even without specialized IRC software, due to that.
Up until the late 2000s there were plenty of thirdparty clients in use and they could all interoperate reasonably well, although MS started turning later versions of the protocol towards a bloated XML-filled mess.
That was a big worry back then when you could nuke/portscan people with only their IPs. It's not so much nowadays and chances are when you see your hostname unobfuscated, you're the only one that does so (/whois other people). Most IRCds will have a host replacement mechanism for privacy and just general good-behaviourness.
Matrix is still kinda rough though. And there is no real lightweight homeserver implementation yet that I could find. Client situation is not much better.
Maybe I am not the target audience, but I just want a simple, lightweight and minimalist client. The only thing that comes close is gomuks and maybe the matrix-plugin for weechat (a irc client), but both are extremely buggy right now for me.
Have you done a Synapse -> Dendrite migration? I'd like to check it out, but there's a strong temptation to just leave things alone now that I have a working Synapse installation.
