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.
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.
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.
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.
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.
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.
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.
Readit News
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.
IRC is free, it will be there next year, doing the exact same thing.
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 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.).
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.
Deleted Comment
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.
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.
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.
Not necessarily.
An SMS, sure. Because that's more of a message than a chat.
IRC, that's strictly chat and that doesn't have to persist. I can duck into and out of it as I wish.
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.
EDIT: Also, how does Matrix handle large communities? I'm interested not just in the user side but the moderator side of things.
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.
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
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.
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.
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.
Candor?
any conclusions you can think to highlight given all that. for instance when would you choose one or the other?
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.