While we don’t want to change IRC radically, there is absolutely the issue that more and more projects and people see IRC as being full of sharp edges, or lacking what they need. We’re really interested in what we can do that enhances, rather than changes the protocol. A hard line for us is not to change how older clients can use our network, as those clients and users are very important to us - but we also want to smooth the way for new and migrating projects.
It’s a fact that IRC is shrinking, and in the face of things like the moznet closure, we should be looking to keep IRC healthy. This doesn’t mean “growth” as our primary target, but we do need to understand what people want to keep the protocol competitive and true to itself. We don’t want to be a matrix catch-up, we want to be able to compete with it as the different protocol and ecosystem it always has been.
The tl;dr is that I like the shell (hence spending a long time writing one), and I used BBSes back in the mid-90’s, and I used Gopher before Netscape existed, but I’ve never gotten into IRC.
Since then I started using Zulip for https://oilshell.zulipchat.com, and it works quite well (aside from most people not knowing how to use it, which is sumountable obstacle). It’s better and faster than Slack IMO.
Likewise I don’t want to spend mental energy signing up for and trying to figure out some new IRC replacement, especially since it’ll presumably sit in the browser, where I try to minimise how much text I have to type. Whereas for IRC, I can use any number of frontends, including one right in my editor.
Just like for using the shell, TeX, etc.; IRC has some upfront time/mental energy cost, but then after that it’s really easy, comfortable, and powerful. I have no interest in setting up/signing up for Slack, Zulip, [insert name here], ….
Also, for Mattermost (a open-source self-hostable Slack alternative) there’s Matterhorn. I prefer the web-based clients myself but there are some options; even slack-term is a thing.
Yeah, that’s totally fair. I don’t want to convince anyone who likes iRC not to use it. I’m just explaining why most people don’t prefer it.
Although I don’t necesssarily agree with the equivalence. I would say the signup cost to Slack/Zulip is less than the setup cost to IRC, depending on your definition of usability. If you already set IRC up 10 years ago, then obviously the equation changes.
The setup/learning cost to something like Slack/Zulip is less than the setup/learning cost of IRC in the same way that the setup/learning cost of Word is less than the setup/learning cost of (La)TeX, but you pay a high hidden cost in that now you have to use Slack/Word rather than IRC/LaTeX.
The main issue that IRC faces imo is the lack of connection persistence: If you get thrown into a room without knowing if your spamming by interrupting, how active it is, etc. you’ll have a bad experience. If you can’t turn of your laptop because you’re still expecting a response, you’ll have a bad experience. If the suggestion to fix this is to try to set up one of the who knows how many broken bouncer servers, you’ll have a bad experience.
And if you have a bad experience, you’ll loose users.
But isn’t this more natural? Consider entering a room in real life where people may be having a conversation. Do you barge right in and immediately start talking at everybody? Of course not, you take time to see who’s present and what the feel of the situation is.
Of course, that might be the case, but now imagine a room with people sitting around staring into the void, and seeing no reaction when you ask a question. Since you just suddenly appeared in this room and have no ability to look back into it’s history (one unrealistic fact for another) you’ll have to wait to see if anyone is even alive – what the value of being “natural” is in this situation can clearly be questioned.
IRC has addressed this problem mostly through norms rather than technically (i.e., it’s sort of impolite to just join a channel, ask a question, and leave if you don’t get an answer: proper netiquitte is to idle in every channel you think you’re liable to be interested in using more or less forever, which produces local logs & also raises the likelihood that conversation will happen & relationships will be developed). IRC is not stackoverflow, in other words, & this makes IRC great for developing long-term relationships in a community but terrible as a mechanism for newbies to get help.
I think the problem here is not that IRC fails to be stackoverflow, but that folks who do a lot of their dev communication on IRC have made the mistake of suggesting non-developers use IRC for tech support, filling channels with users who don’t know or care about the norms or about developing long-term relationships as regulars. (Or, in said in the hyperbolic & slightly acid way I used to say it back in my heavy IRC days, “people who shut off their computers shouldn’t be on IRC”.) Mailing lists (unless they are announcement-based) have basically the same issue.
There are common norms around hosting public logs, as well. As Drew says, pretty much everything that slack tries to build in is already supported on IRC as an add-on (or as expectations around behavior), & this allows the system to be accessible to a wider variety of people – it’s just not accessible to people who are unwilling to learn the norms or use the tools (i.e., people who aren’t going to buy into the community).
Yeah, the in-person experience usually has existing conversations you overhear, people physically situated in a way that tells you stuff, and even their gestures or clothing might indicate some interests. Whereas, IRC is much more like a void at the start unless it’s really active.
That’s why there are IRC bouncers/persistent clients. The problem is that you either pay a monthly fee or you have to figure out how to set it up yourself.
That said, all of the alternatives to IRC offer worse experiences.
you either pay a monthly fee or you have to figure out how to set it up yourself.
That’s not even the primary issue, instead it’s that in practice most bouncers are unmaintained, have very specific and peculiar settings, too many moving components, bad documentation (*cough*, ZNC) etc. They are generally a mess and don’t integrate all to well into IRC as a protocol in general.
That said, all of the alternatives to IRC offer worse experiences.
If I’m quite honest, and I don’t like saying this, but most IM networks like WhatsApp or Facebook Messenger offer a far more stable and expectable experience, which is why people use these kinds of clients/networks. The network effect only determines which from this category becomes popular.
most bouncers are unmaintained, have very specific and peculiar settings, too many moving components, bad documentation (cough, ZNC) etc
Weechat is really excellent. It still has some upfront ‘costs’ in terms of setting it up, but it’s really easy and pleasant, and I’ve had no real issues with IRC via Weechat.
If I’m quite honest, and I don’t like saying this, but most IM networks like WhatsApp or Facebook Messenger offer a far more stable and expectable experience,
I also end up using WhatsApp from time to time, and it’s a far, far, far worse experience than IRC. The web client sucks, and has all sorts of connectivity issues. If your phone isn’t on the same network, it simply doesn’t work. It expects to be used on mobile. I can’t easily adjust how things are displayed to me in the app. I can’t connect to it from, say, Emacs.
So in practice I much more frequently check IRC than I do WhatsApp, despite having family members etc. on WhatsApp.
Thus, I think your example of WhatsApp is excellent. As an example of a far worse, very miserable user experience.
An alternative, however, is the option to display to newly joined users the last, say, 25 lines of history in the channel. Many users may think a channel is dead, or struggle to understand the context of the current conversation on join, and this is something that could help alleviate it.
It’s something we’re considering, and would likely be opt-in by channel operators via a channel mode - with the added bonus of this meaning that users who are sensitive to such backlog can be warned by their client when it receives the channel modes.
An alternative, however, is the option to display to newly joined users the last, say, 25 lines of history in the channel. Many users may think a channel is dead, or struggle to understand the context of the current conversation on join, and this is something that could help alleviate it.
This is how XMPP has worked for years, and is the main reason I chose it over IRC when I was first getting into these things back in the day.
This was a very interesting point I hadn’t even considered before!
One interesting thing: XMPP supports “infinite backlog” but some rooms (such as prosody) explicitly do not enable it for the same reason - to keep the discussion ephemeral.
Only with some recent draft extensions does XMPP support infinite backlog. By default it uses a finite backlog to get you some context when you join – which is of course and amazing killer feature by itself and the main reason I originally switched to XMPP.
Only with some recent draft extensions does XMPP support infinite backlog.
I know that in XMPP timeline it’s “recent” but I think it’s good to put it into perspective: MAM was initially released in 2012. Prosody module implementing that is 7 years old.
Just as context for people reading the thread and wondering, Prosody’s mod_mam (backlog module) expires messages after one week by default. You can configure it for months, years, or forever, but honestly, one week is a pretty good default.
I don’t think ephemerality is as common as he makes it out to be, but putting the onus of logging on individual users is itself a big deal & desirable. Social norms on irc are that everybody keeps full logs & nobody ever logs off (and bigger channels tend to have logger bots that don’t have anybody on ignore, often keeping public logs), so arbitrary scrollback is generally available if you ask for it.
The difference is that, because everybody keeps their own logs, authority with regard to recording history is also distributed: Slack, Inc can rewrite the history of any conversation on Slack any way they like, but it’s much harder for somebody to hack into the machines of everybody on an IRC channel and falsify their logs.
The logs we keep on IRC are records of what we see (or what we would see, if we weren’t AFK), reflecting our ignorelist and such, & the absence of a single canonical record is philosophically important.
This is the reason I never really got into web BBSes as general-purpose chatting platforms.
(Unlike domain-specific news aggregators like Lobsters, where we’re only commenting on articles.)
I love that I can just drop in and drop out any time I like with IRC.
None of this even considers what is good about IRC. It’s a series of decentralized networks built on the shoulders of volunteers. It’s venerable and well-supported with hundreds of client and server implementations.
Like all decentralized networks, it’s has to overcome the inherent streamlining advantages of VC-backed, centralized, poised-to-monetize competitors.
Ideally simply the presence of the VC vultures hovering over a service like Slack, poised to monetize it by striking without notice would be enough that folks would instinctively flinch away from using them. But we’ve seen that folks tend to have a short memory about these kinds of things and are very good at coming up with rationalizations why “this time it will be different”.
The more I think about this, the more I think the solution (to this and many other problems) would be some sort of mental inoculation against the tricks that tech companies use to convince people to use their products even when it’s not in their best long-term interests.
Yes, and when you’ve figured that out you’ll likely to be able to solve many of the other problems which have arisen in the world since 1688 (or, arguably, much earlier).
Sometimes I think it’s OK to let technologies become obsolete.
For those of us who’ve been around the block a few times, there will always be a soft spot for IRC - that initial moment of HOLY CRAP I’M TALKING TO A WOMAN FROM AUSTRALIA! or whatever, back when that was a Really Amazing Thing to be doing at no cost, but maybe it’s time to consider letting younger technologies have a turn.
I’m not suggesting we should all throw in the towel and join Slack, far from it - but things like Matrix make it hard for me to justify continuing to evolve this old friend.
I can’t help but notice that this page uses almost all of the features it claims are are bad for IRC.
You might respond that browsers are ubiquitous, so it’s ok to assume that the user has a browser that will handle images and css (and I suspect this page is ok in lynx–but not great, there’s no alt text on the images). However, it seems to me that the force of this argument is that “you can’t assume IRC clients will ever be updated to handle useful features, so it’s best to assume they will not have them, and work accordingly.”
This seems like a reasonable accommodation, but not quite a feature.
I thought about this question before posting. Certainly there are some differences, and I can see arguing that they invalidate this point. However, I think on most of the points that are relevant, the differences don’t matter that much.
Suppose we’re talking about the advantages/disadvantages of Slack & IRC, and we’re doing it on IRC. There’s just as much of a use-case for posting images inline. Or, for another point, phishing is a concern on the web. Email is a huge source of phishing, that probably dwarfs messaging platforms and the web, but it affects all three. Ditto for
The implicit answer in the post seems to be “use IRC conventions”, but imo, that’s more work for less gain. Sometimes you want to include source text or an image, sometimes you just want to link to things. A good GUI makes both possible, with feedback as to which you’re doing. IRC does not (a convention is an invitation to subtly break things thanks to irrelevant details).
One of the big reasons why I think IRC is better than Slack is that I can use scripting in an IRC client to highlight and filter incoming text. In Slack, receiving a channel’s messages is 100% binary. I must get both messages of interest to me AND messages of no interest to me (GIFs, bots auto-posting, and so on); or I must leave the channel to avoid the unwanted messages – and accept that I see none of the other possibly interesting or important messages. Threading in Slack helps with this problem a bit (I do think Zulip’s design has the right idea), but not enough. I often miss being able to do text processing in whatever messaging client I’m using.
A related and upstream point on this can be found here: https://cmpwn.com/@kline/102333166678467931
While we don’t want to change IRC radically, there is absolutely the issue that more and more projects and people see IRC as being full of sharp edges, or lacking what they need. We’re really interested in what we can do that enhances, rather than changes the protocol. A hard line for us is not to change how older clients can use our network, as those clients and users are very important to us - but we also want to smooth the way for new and migrating projects.
It’s a fact that IRC is shrinking, and in the face of things like the moznet closure, we should be looking to keep IRC healthy. This doesn’t mean “growth” as our primary target, but we do need to understand what people want to keep the protocol competitive and true to itself. We don’t want to be a matrix catch-up, we want to be able to compete with it as the different protocol and ecosystem it always has been.
FWIW here are my comments on why I barely use IRC from a year ago:
https://news.ycombinator.com/item?id=16495984
The tl;dr is that I like the shell (hence spending a long time writing one), and I used BBSes back in the mid-90’s, and I used Gopher before Netscape existed, but I’ve never gotten into IRC.
Since then I started using Zulip for https://oilshell.zulipchat.com, and it works quite well (aside from most people not knowing how to use it, which is sumountable obstacle). It’s better and faster than Slack IMO.
Likewise I don’t want to spend mental energy signing up for and trying to figure out some new IRC replacement, especially since it’ll presumably sit in the browser, where I try to minimise how much text I have to type. Whereas for IRC, I can use any number of frontends, including one right in my editor.
Just like for using the shell, TeX, etc.; IRC has some upfront time/mental energy cost, but then after that it’s really easy, comfortable, and powerful. I have no interest in setting up/signing up for Slack, Zulip, [insert name here], ….
See https://github.com/zulip/zulip-terminal
Also, for Mattermost (a open-source self-hostable Slack alternative) there’s Matterhorn. I prefer the web-based clients myself but there are some options; even slack-term is a thing.
When there’s a https://github.com/zulip/zulip.el maybe I’ll take a look.
But as far as I can tell everything’s that worth talking about is on Freenode.
Yeah, that’s totally fair. I don’t want to convince anyone who likes iRC not to use it. I’m just explaining why most people don’t prefer it.
Although I don’t necesssarily agree with the equivalence. I would say the signup cost to Slack/Zulip is less than the setup cost to IRC, depending on your definition of usability. If you already set IRC up 10 years ago, then obviously the equation changes.
The setup/learning cost to something like Slack/Zulip is less than the setup/learning cost of IRC in the same way that the setup/learning cost of Word is less than the setup/learning cost of (La)TeX, but you pay a high hidden cost in that now you have to use Slack/Word rather than IRC/LaTeX.
The main issue that IRC faces imo is the lack of connection persistence: If you get thrown into a room without knowing if your spamming by interrupting, how active it is, etc. you’ll have a bad experience. If you can’t turn of your laptop because you’re still expecting a response, you’ll have a bad experience. If the suggestion to fix this is to try to set up one of the who knows how many broken bouncer servers, you’ll have a bad experience.
And if you have a bad experience, you’ll loose users.
But isn’t this more natural? Consider entering a room in real life where people may be having a conversation. Do you barge right in and immediately start talking at everybody? Of course not, you take time to see who’s present and what the feel of the situation is.
Of course, that might be the case, but now imagine a room with people sitting around staring into the void, and seeing no reaction when you ask a question. Since you just suddenly appeared in this room and have no ability to look back into it’s history (one unrealistic fact for another) you’ll have to wait to see if anyone is even alive – what the value of being “natural” is in this situation can clearly be questioned.
IRC has addressed this problem mostly through norms rather than technically (i.e., it’s sort of impolite to just join a channel, ask a question, and leave if you don’t get an answer: proper netiquitte is to idle in every channel you think you’re liable to be interested in using more or less forever, which produces local logs & also raises the likelihood that conversation will happen & relationships will be developed). IRC is not stackoverflow, in other words, & this makes IRC great for developing long-term relationships in a community but terrible as a mechanism for newbies to get help.
I think the problem here is not that IRC fails to be stackoverflow, but that folks who do a lot of their dev communication on IRC have made the mistake of suggesting non-developers use IRC for tech support, filling channels with users who don’t know or care about the norms or about developing long-term relationships as regulars. (Or, in said in the hyperbolic & slightly acid way I used to say it back in my heavy IRC days, “people who shut off their computers shouldn’t be on IRC”.) Mailing lists (unless they are announcement-based) have basically the same issue.
There are common norms around hosting public logs, as well. As Drew says, pretty much everything that slack tries to build in is already supported on IRC as an add-on (or as expectations around behavior), & this allows the system to be accessible to a wider variety of people – it’s just not accessible to people who are unwilling to learn the norms or use the tools (i.e., people who aren’t going to buy into the community).
I like this, well said!
Yeah, the in-person experience usually has existing conversations you overhear, people physically situated in a way that tells you stuff, and even their gestures or clothing might indicate some interests. Whereas, IRC is much more like a void at the start unless it’s really active.
If I wanted something as shitty as real life I’d go outside. I want my tools to do better than I could do without them.
That’s why there are IRC bouncers/persistent clients. The problem is that you either pay a monthly fee or you have to figure out how to set it up yourself.
That said, all of the alternatives to IRC offer worse experiences.
That’s not even the primary issue, instead it’s that in practice most bouncers are unmaintained, have very specific and peculiar settings, too many moving components, bad documentation (*cough*, ZNC) etc. They are generally a mess and don’t integrate all to well into IRC as a protocol in general.
If I’m quite honest, and I don’t like saying this, but most IM networks like WhatsApp or Facebook Messenger offer a far more stable and expectable experience, which is why people use these kinds of clients/networks. The network effect only determines which from this category becomes popular.
Weechat is really excellent. It still has some upfront ‘costs’ in terms of setting it up, but it’s really easy and pleasant, and I’ve had no real issues with IRC via Weechat.
I also end up using WhatsApp from time to time, and it’s a far, far, far worse experience than IRC. The web client sucks, and has all sorts of connectivity issues. If your phone isn’t on the same network, it simply doesn’t work. It expects to be used on mobile. I can’t easily adjust how things are displayed to me in the app. I can’t connect to it from, say, Emacs.
So in practice I much more frequently check IRC than I do WhatsApp, despite having family members etc. on WhatsApp.
Thus, I think your example of WhatsApp is excellent. As an example of a far worse, very miserable user experience.
(You might find sms-irc quite useful… :p)
Have you given Matrix a fair shake?
Eventually I’ll probably try to figure out how to set up a Matrix bridge or whatever via Weechat.
No need for a bridge if you’re an end user and just want Weechat to speak Matrix:
https://matrix.org/docs/projects/client/weechat-matrix
This was a very interesting point I hadn’t even considered before!
An alternative, however, is the option to display to newly joined users the last, say, 25 lines of history in the channel. Many users may think a channel is dead, or struggle to understand the context of the current conversation on join, and this is something that could help alleviate it.
It’s something we’re considering, and would likely be opt-in by channel operators via a channel mode - with the added bonus of this meaning that users who are sensitive to such backlog can be warned by their client when it receives the channel modes.
This is how XMPP has worked for years, and is the main reason I chose it over IRC when I was first getting into these things back in the day.
One interesting thing: XMPP supports “infinite backlog” but some rooms (such as prosody) explicitly do not enable it for the same reason - to keep the discussion ephemeral.
Only with some recent draft extensions does XMPP support infinite backlog. By default it uses a finite backlog to get you some context when you join – which is of course and amazing killer feature by itself and the main reason I originally switched to XMPP.
I know that in XMPP timeline it’s “recent” but I think it’s good to put it into perspective: MAM was initially released in 2012. Prosody module implementing that is 7 years old.
Just as context for people reading the thread and wondering, Prosody’s mod_mam (backlog module) expires messages after one week by default. You can configure it for months, years, or forever, but honestly, one week is a pretty good default.
I don’t think ephemerality is as common as he makes it out to be, but putting the onus of logging on individual users is itself a big deal & desirable. Social norms on irc are that everybody keeps full logs & nobody ever logs off (and bigger channels tend to have logger bots that don’t have anybody on ignore, often keeping public logs), so arbitrary scrollback is generally available if you ask for it.
The difference is that, because everybody keeps their own logs, authority with regard to recording history is also distributed: Slack, Inc can rewrite the history of any conversation on Slack any way they like, but it’s much harder for somebody to hack into the machines of everybody on an IRC channel and falsify their logs.
The logs we keep on IRC are records of what we see (or what we would see, if we weren’t AFK), reflecting our ignorelist and such, & the absence of a single canonical record is philosophically important.
This is the reason I never really got into web BBSes as general-purpose chatting platforms. (Unlike domain-specific news aggregators like Lobsters, where we’re only commenting on articles.) I love that I can just drop in and drop out any time I like with IRC.
Like all decentralized networks, it’s has to overcome the inherent streamlining advantages of VC-backed, centralized, poised-to-monetize competitors.
Ideally simply the presence of the VC vultures hovering over a service like Slack, poised to monetize it by striking without notice would be enough that folks would instinctively flinch away from using them. But we’ve seen that folks tend to have a short memory about these kinds of things and are very good at coming up with rationalizations why “this time it will be different”.
The more I think about this, the more I think the solution (to this and many other problems) would be some sort of mental inoculation against the tricks that tech companies use to convince people to use their products even when it’s not in their best long-term interests.
Yes, and when you’ve figured that out you’ll likely to be able to solve many of the other problems which have arisen in the world since 1688 (or, arguably, much earlier).
Sometimes I think it’s OK to let technologies become obsolete.
For those of us who’ve been around the block a few times, there will always be a soft spot for IRC - that initial moment of HOLY CRAP I’M TALKING TO A WOMAN FROM AUSTRALIA! or whatever, back when that was a Really Amazing Thing to be doing at no cost, but maybe it’s time to consider letting younger technologies have a turn.
I’m not suggesting we should all throw in the towel and join Slack, far from it - but things like Matrix make it hard for me to justify continuing to evolve this old friend.
Does anyone know the CLI IRC client pictured there?
Thanks in advance!
Weechat.
I can’t help but notice that this page uses almost all of the features it claims are are bad for IRC.
You might respond that browsers are ubiquitous, so it’s ok to assume that the user has a browser that will handle images and css (and I suspect this page is ok in lynx–but not great, there’s no alt text on the images). However, it seems to me that the force of this argument is that “you can’t assume IRC clients will ever be updated to handle useful features, so it’s best to assume they will not have them, and work accordingly.”
This seems like a reasonable accommodation, but not quite a feature.
Are you now not confusing instant messaging with short articles?
They are two different kinds of content, which may benefit from two different types of presentation/features.
I thought about this question before posting. Certainly there are some differences, and I can see arguing that they invalidate this point. However, I think on most of the points that are relevant, the differences don’t matter that much.
Suppose we’re talking about the advantages/disadvantages of Slack & IRC, and we’re doing it on IRC. There’s just as much of a use-case for posting images inline. Or, for another point, phishing is a concern on the web. Email is a huge source of phishing, that probably dwarfs messaging platforms and the web, but it affects all three. Ditto for
The implicit answer in the post seems to be “use IRC conventions”, but imo, that’s more work for less gain. Sometimes you want to include source text or an image, sometimes you just want to link to things. A good GUI makes both possible, with feedback as to which you’re doing. IRC does not (a convention is an invitation to subtly break things thanks to irrelevant details).
One of the big reasons why I think IRC is better than Slack is that I can use scripting in an IRC client to highlight and filter incoming text. In Slack, receiving a channel’s messages is 100% binary. I must get both messages of interest to me AND messages of no interest to me (GIFs, bots auto-posting, and so on); or I must leave the channel to avoid the unwanted messages – and accept that I see none of the other possibly interesting or important messages. Threading in Slack helps with this problem a bit (I do think Zulip’s design has the right idea), but not enough. I often miss being able to do text processing in whatever messaging client I’m using.
I think Weechat does have some sort of support for embedded images, actually, doesn’t it?
I use it in a console. Well, generally under
lxterminal.Weechat is nice because you can connect to it with a terminal, or emacs, or a web browser, or a mobile app.