Absence of certain features in IRC considered a feature
drewdevault.com
drewdevault.com
The two biggest pain point that I see is: 1. Because there is no real account management you don't have any proper authentication, which make administrating a channel real dodgy (even with network provided bots).
2. No offline history: You have to have a client/bouncer running 24/24 if you want history.
One thing though, because of how IRC work, you don't have the problem that other protocol like XMPP faced with multy-device sync (there is a extension for that in XMPP but, like almost every extension in XMPP, not many client support it).
Also, nowadays we should consider end-to-end encryption standard.
I feel like IRC is in the same space as email: It's a very good technology that just lack a few feature to be perfect but any project that try to replace them just end up over-bloated with features ...
However, if you're going to run your own IRC server you can also run your own bouncer service. Lots of authentication options exist as well. IRC is totally fine for an org who can stand up a server. It's pretty low-maintenance too.
Presumably, when some random IRCd hacker decides to spend their spare time doing so. Most of the IRCds are FOSS, no?
https://irc.com/lets-take-irc-further
Latest update from the team: https://irc.com/blog/2019-04-Development_updates
That's not really an issue of IRC itself, but the IRC network you are using.
Running your own IRC server would solve that issue - ngircd for instance supports authentication using PAM or inspircd can directly perform authentication against either LDAP or a SQL database.
And doesn't IRCv3 SASL authentication + only allowing registered users into the channel pretty much solve the issue as well?
I would say it's even worse than this. Even if you attempt to have a client 24/7, the lack of an acknowledgement and re-transmit on lack of acknowledgement means that if you have any hiccup that causes you to need to reset the TCP connection, you can drop messages.
It's statistically guaranteed to fail, and IRC as a protocol spec is powerless to do anything other than shrug.
It's a social protocol.
I did change careers to escape that...
Now in a real life situation you can mishear or fail to hear. But technology can make this better.
I might not want a 24/7 archive. Especially not for all the silly things I said in my teens.
For high-volume, fast-paced channels this may not be appropriate. For slower channels where people rarely post anything, you constantly asking "did I miss anything while I disconnected" might be considered spam.
> I might not want a 24/7 archive
What you may or may not want has no bearing on what the technology should be capable of providing when others may require it.
Technology can, and already has, solved these problems. If that's not your cup of tea, fine, but don't impose your own use cases on others through "but it works fine for me"-ism.
IRC remains popular, so same to you buddy.
I didn't suggest anybody do anything in my post. I merely postulated on scenarios where technology can (and does exist to) solve problems that aren't your own.
> IRC remains popular
I don't doubt it; in fact, I never disputed that. Further, in no way did I imply that IRC should cease to exist because other options are out there that address other peoples' needs, nor did I indicate that I think any IRC users are wrong to prefer it.
> so same to you buddy
Please keep your language respectful; your tone in that reply was nothing short of dismissive and needlessly condescending.
For the general population, the user may not know to doubt reliability, nor do I think they ought to. So I think there is value in higher reliability of delivery.
The most obvious version of this is a netsplit, but even single users can get isolated from the network and have all of their messages dropped without realizing it until minutes later (if ever). There's no cool name for that; it's just IRC being unreliable.
Maybe unreliability is part of the charm for you, but that bug is absolutely not a feature, and not intrinsic to being a "social protocol."
You do however get informed by the server after a netsplit has occurred... and key-up retains most of what you have said recently so achieving coherency isn't difficult, although a manual task.
While this is certainly the initial deployment scenario, there's no reason in principle why you couldn't develop a server that natively supports that extension.
2. This is also a solved problem, there are bots that log everything on the channel and then you can read/search through channel history from web interface. But mostly this is not needed as you can just spin znc for whole your team.
2 is a problem with the architectural decisions modern IRC has inherited. It cannot be fixed because it depends on persistent TCP connections and that is not the way the internet works.
Care to elaborate? It solves authentication for us and we are using it for 10+ years like this.
> is a problem with the architectural decisions modern IRC has inherited. It cannot be fixed because it depends on persistent TCP connections and that is not the way the internet works.
Let me check my current znc IRC session signon: Wed Jul 18 07:43:12
So almost a year.
If "we use plaintext passwords communicated to a faux user" is your idea of "solved" then we have very different standards.
> Let me check my current znc IRC session signon: Wed Jul 18 07:43:12
Congrats on being rich and lucky I guess? That's not a thing most folks can replicate at scale. I have had more than one IP address in the duration of writing this post.
But aside, it seems like not all networks support TLS logins?
As it stands, I have no IRC equivalent of a 2FA key. I present a plaintext token and hope that it's all handled properly and that I'm not a victim of a password reuse attack.
Any web based solution is light years ahead on this.
That's also the case for 99% of authentication in the web context. 2FA adoption is on the rise but by no means the standard. If it was a thing users asked for, there's no protocol reason a nickserv service and clients couldn't adopt a 2FA flow, even without breaking backwards-compatibility.
plaintext? In our use case TLS usage is mandatory and passwords are not stored in plaintext. I think your knowledge about how IRC is used now is a little outdated.
> Congrats on being rich and lucky I guess? That's not a thing most folks can replicate at scale. I have had more than one IP address in the duration of writing this post.
VPN -> znc -> IRC
You don't need to be rich and lucky to replicate this. Signon time was from znc to irc, not from my home connection to irc.
Actually I wondered if that might be the case so I checked TFM: https://freenode.net/kb/answer/registration
Plaintext negotiation is my complaint. I doubt we'd be discussing this if it was plaintext storage. Not even the most fanatical IRC proponent would be okay with that.
> TLS usage is mandatory and passwords are not stored in it plaintext. I think your knowledge about how IRC is used now is a little outdated.
> VPN -> znc -> IRC
Where is your znc hosted? How much does it cost? Are you paying for a VPN service (please no)?
Even having a decent in-home internet connection, a way to route traffic back into your network, and a raspberry pi to host it on is a tall order.
You can do all that over an encrypted connection [1] if you like. All this protocol nitpicking kind of ignores that IRC is a stack that is a) open to a multitude of clients and thus use cases (vs. all those fancy web-things that offer me either lockin and emojis or a lack of user base) and b) proven over decades. Yeah, it has it's inherited edge cases and downsides but this thread makes it seem like it's a stupid idea somebody came up with in 2 hours, which it is absolutely not.
The network architecture was ridiculous 20 years ago, it still works. That's one of those things where I feel like "cool, if it's really broken enough, write a new backend and maintain compatbility to my stuff. I'm a user and don't care about your architecture". I'll gladly admit that there's a non-trivial amount of nostalgia in that logic though. :)
IRC's network architecture only survives because people tolerate it. Even slightly animosity from the community brings it down hard every time.
I think what's valuable is the chatroom model, which is largely dead outside of Telegram (which is, I agree, unusable from a user privacy and control standpoint). Part of the reason I'm passionate about this is that I want the model to be robust and well-maintained. I am nostalgic for the model, but I view the underlying legacy implementation as an obstacle to the preservation of that model.
We are running our own IRC servers and you can't connect without using TLS, I still don't know what's your issue is with the registration ? You would need to have access to the machines that are running IRC servers to use that information. It's like saying that none of the standard authentication over the internet (login + password to your bank, your slack account, google cloud etc) using encrypted connection is not secure because you are entering password in plaintext.
> Where is your znc hosted? How much does it cost? Are you paying for a VPN service (please no)?
It's hosted at one of the largest datacenters in Europe. We are not using cloud. Cost is low, very low, compared to Google cloud/AWS we are paying around 50x times less for our whole infrastructure. But we digress now from the main discussion.
> Are you paying for a VPN service (please no)?
We are running our own VPN servers on dedicated hardware.
2 is trivially solvable on the server side by writing logs
IRC is a protocol, not a product, and an IRCd author can add these features. The fact that it has not been done speaks to the demand for these features.
> Logs
Yes if you sacrifice all privacy you can patch over this problem by running a local bot and then using extra software to republish it. I suppose that is a valid, if unsatisfying, answer.
> IRC is a protocol, not a product, and an IRCd author can add these features.
Except that to directly address these issues within the framework of IRC is impossible. Folks just push any problem they don't feel like solving down the stack, or hand tweaking of their IRCd in ways that most clients won't respect.
Using IRC to build a protocol (as anything other than the shallowest integration for a more robust chat backend) seems to be extremely niche.
>The fact that it has not been done speaks to the demand for these features
Alternative hypothesis: it's much easier to just go build something else rather than listen to folks list off a string of excuses rather than just amicably agree it's a nostalgia thing and it's not for everyone.
I don't understand, is this referring to running company chats on EFNet or Freenode or something? IRCd can be run locally, on an inside server or other controlled execution environment.
freenode and Rizon both support SASL, and UnrealIRCd has support built in[1]. It's not 'bolted on' as you claim, and many networks support it.
>Yes if you sacrifice all privacy you can patch over this problem by running a local bot and then using extra software to republish it. I suppose that is a valid, if unsatisfying, answer.
You can add a module to an IRCd to log on the server. This is ideal in a work situation where people know they're being logged. This is not a client side method as you seem to imply.
>it's not for everyone
Nobody, especially the most 'hardcore' of IRC users I've met, would contend that everyone should be using IRC. Rather, what they're contending is that IRC has technical limitations and the people that use IRC _prefer_ having those technical limitations because their use does not require those features.
Re 2: ZNC works, but is a really trash user experience from both sides. For instance, you never really know if someone is there or not. Also no push messages, which breaks the "get this person's attention" thing that most people use it for.
And you get the same problem if for some reason the bouncer loses connectivity.
2. ZNC has plugins for push messages, or at least it did when I was using it several years ago. My personal bouncer was configured to automatically set my away status when I went offline; alternatives include (de)voicing (in)active users, changing nickname, etc. When my bouncer had no clients connected and someone sent me a pm, it was configured to send a message to Pushbullet.
If you're not using a bouncer or the bouncer is down, services packages such as anope may include a memoserv for sending messages to offline users; on services login, memoserv will notify you of pending messages.
2: Which ties right back into point 1 that setting this up is not user-friendly.
[1] - https://thelounge.chat/ https://github.com/thelounge/thelounge
If it's easy to get history people will assume everyone is reading what they're typing. This would make people feel obligated to play catch-up every time they miss some messages due to being AFK or in the zone.
By making history hard to obtain, IRC simulates real-world conversation -- you're either in the room or you're not.
I'm beginning to feel this way about everything. Reddit, Twitter, social media in general...
The hoarder mentality likes for this stuff to still exist in the hopes it might one day be useful. In fact, it has very little value.
Snapchat got it right when they started with ephemerality.
Chats in organizations are specifically for when email is not realtime enough but it's important to keep a record of the conversations for some time.
This varies immensely per organisation so it's always kind of dangerous to generalise like this. For example: The use-case you quote does not align with my experience of (bigcorp) chats at all.
"You have to have a client/bouncer running 24/24 if you want history." Or a logging bot, which some channels have. Another alternative is for the logging to be part of the server implementation; I have once done this, and it is possible, but it does not seem to be common (although I think maybe it should be done more).
Another thing about IRC is that it can be used without any kind of special software (although software specifically for IRC is still useful; for one thing, if you do not have a IRC client then you must manually respond to pings). It isn't too complicated; Matrix and Discord and so on are too complicated.
IRCv3 has support for this: https://ircv3.net/specs/extensions/batch/chathistory-3.3.htm... and at least InspIRCd (a major server implementation) implements it.
ihabunek [m] sent a long message: < https://matrix.org/_matrix/media/blahblahblah >
ihabunek [m] uploaded an image: image.png (39KB) < https://matrix.org/_matrix/media/blahblahblah >
The truth is, IRC folks do need to share long snippets and images, and they do it by linking to them; that's exactly what Matrix does when integrating with IRC. That's one among many reasons that Matrix is better than IRC.
https://lists.sr.ht/~sircmpwn/public-inbox/%3Ca6e64b69-c0cf-...
I think this could prove to be a good compromise. https://i.imgur.com/O1qw0dI.png
> When one side sees it embedded in the chat but the other side sees it as a link, it affects how the former uses the feature and how the latter perceives the former, in ways that could be unexpected to the former. The point of my article is that these features have a social effect which is not necessarily positive.
How does it affect it? What ways? What social effect?
This explanation is totally devoid of any concrete examples of a mismatch of expectations and resulting social effects, it just alludes to them existing without any concrete basis - essentially weasel wording.
I have seen a user who had half their messages replaced by a link, that was unreadable.
...and a ton of hate.
It's what users already do, but without having to pop a new tab, head to imgur, upload the image, and copy paste it back etc.
I personally just $ cp whatever.jpg ~/www/ because I host my static site from my home connection and have for 20 years. I know self-hosting is not for everyone but everyone self hosting would literally solve all the problems of the web.
As an example, I have my thinkpads prtscr button hooked up to automatically capture the screen, upload to 0x0.st, put the url into my clipboard, and then alert dunst to pop a notification that it's done.
It takes a very common 60 second process and makes it almost as fast as prtscr, ctrl+v
Just running a webserver is dead simple. The only technical stumbling block would be forwarding the port from the router and a good chunk of internet users understand that.
You can't seriously say that and talk about port forwarding in the next sentence. Some people still think internet is the web is Google is Facebook. Some people (understandably) don't want to have something running 24/7. Most people won't be able to maintain their server, turning them into the biggest botnet ever created. I'd love the internet to be more decentralized, but this is just not reasonable.
People who are absolutely ignorant and incapable of learning aren't who I'm talking about. Most people can learn to change a turn signal bulb.
And no, running a static webserver will not cause vulnerabilities. Again, like in my prior comment, that only happens when you use some complex combination of webserver, database, and scripting language. A static webserver is significantly more secure than opening up a page in your browser with javascript enabled.
I'm always baffled when I see that the Signal client package is like 80MB on desktop and lacks basic functionality and configurability while irssi is barely 1MB, extremely lightweight and effectively endlessly configurable. Let's not even talk about Discord which manages to lag severely in Firefox on my high-end gaming PC.
Because all people find it valuable to find out how IRC clients are scriptable, figuring out all the moving parts to the clients' scripting interface, to a third-party API (if it exists), etc. etc.
Or, you know, use Slack or Discord :)
And the problems continue beyond just scripting another app. The world is mobile, and old protocols have missed the memo.
The same thing could have been said about messaging clients like ICQ, AIM, MSN messenger etc. vs IRC, but none of them remain while IRC is still actively used.
Yeah, lets just forget how painful it was for non english speaking users to use IRC. 255 characters for unicode and 510, but you have to guess encoding.
But apart from that, I've certainly had my share of truncated messages, both in German and English. Sometimes you want to express a thought in full in several sentences without twenty other channel messages appearing in between the sentences while you're typing.
This is why one of the major Thai IRC networks were stuck with TIS-620 for a long time (ThaiNet/irc.thai.com, though I'm not sure if this is still the case) which is 8-bit compatible with ASCII (uses 0xA1 to 0xFB for Thai characters).
Let's just use a modest channel name like "#𐑥𐑨𐑔 𐑯 𐑕𐑲𐑧𐑯𐑕". I've now got a base 45 bytes without any message at all. If I want to aim a message at someone I have even less than that. Your pithy reply with a similarly modest title is 20% of the total allocation for a line, half of which is just overhead.
We run into line limits talk about category theory in #haskell even in English and folks are quite good at compressing contexts. The only alternative is to slice your messages across lines and make a confusing experience for participants.
[1]: Idiomatic Yojijukugo 四字熟語 is an extreme example for this, but there's non-idiom Yojijukugo too, e.g. 日米関係 is a 12 bytes word that translates to "United States-Japan relations"
[2]: https://www.nikkei.com/article/DGXMZO46571150V20C19A6000000/
[3]: It describes how people are walking around the park in Chicago on Jun 13 to catch a rare Pokemon with a one line interview of a son of Mr. Stuart from California.
(I speak three languages: Thai, English, Japanese)
For Japanese, I don't think the way people talk casually to one another is as amenable to compression as newspaper headlines
But surely for Thai you're in a sub-optimal boat?
For Thai, yeah, this one is a little more complicated. I’ve commented about this in sibling thread.
Once we have some sensible way, then clients can sensibly opt to pop a dialog for new users allowing them to register an account with nickserv without having to fiddle away in a query.
Unless you regard it as inane.
Throwing reaction gifs at a happy birthday/congratulation post is one thing.
Throwing them into the oncall production ops channel and context switch everyone so they can see Homer back into a hedge is another.
This is part of the reason I like the "reactji" of slack / discord / etc. They don't cause a new message notification.
Because of that, they're less interruptive, and you can do some interesting, useful things. Like lightweight interaction - we "seed" an up/down arrow pair for voting, people just click one. Or controlling bots more easily - we use one to add Qs to a queue, others to shut them up when they're being noisy, or there's fancier options: https://codeascraft.com/2018/10/10/etsys-experiment-with-imm...
Humor is subjective. All you have to do is reference "Office Space"'s "looks like somebody has a case of the Monday's!" scene to realize she thought it was funny, the "someone" did not.
I help run a irc network which was spawned out of Undernet #linux around 15 years ago, because even back then we were really unhappy with general instability and how Undernet was run. Back then, it would split or simply go down several times a day.
We were making the claim that “Undernet is dying” even back then.
A few people and #linux channel-ops legitimately asked “How hard can it be?” and surprise surprise: not very.
So here we are 15 years later, aside from some very few incidents, with almost zero downtime.
Some servers has gone, some new have arrived. Same with oppers.
But the network is still there and all the same IRC-clients and users can still reach us.
IRC is one of the best things Internet has to offer, and these days people are working furiously to avoid learning what has made it so great.
There's a certain whimsical botanical style to the way in which IRC networks tended to grow large enough to start budding off new networks, some of which were able to find sufficient purchase to grow large themselves and repeat the cycle anew.
I'm pretty sure Dinnerbone was around 18? at the start of Bukkit.
IRC is capable. It is a box of nuts and bolts that lets us communicate and build awesome bots and so on.
Bloating the protocol gives us suitability: features that are robust and can federate.
This is working well for us, without any issues for years.
Despite all these deficiencies it's still widely used – My guess is that nobody has come up with a chat medium that would replace it completely. It's still pretty much the only decentralized, push-pull, clutter free real time discussion medium.
Make no mistake, we don't want to change IRC, but we do want to take some of the sharp edges off. I'll never move away from hexchat, the client I use now, and maintaining that backwards compatibility and character for all users is a red line for us.
And it doesn't seem to me that "fixing" irc is just a matter of adding the bells and whistles, but there's some work to be done on the lower levels as well
For example, how well would irc work on mobile? Keeping logs requires a bot usually on irc as well.
I really do miss using IRC all the time. My favorite server got taken down and I never bothered to find out where everyone ran off to.
MUDs face a similar set of issues. Some new MUD frameworks skip over these by ignoring telnet and going HTML/JS.
There's an interesting third path, GMCP, which is basically treated by the server/client (once support is negotiated) as out-of-band communication. If either end can't negotiate support, you get the basic experience. As a pressure-release valve, options like this can be better than clients or servers trying to overload the primary protocol with magic messages that other servers/clients without support are still forced to digest and display.
Something like:
%M!i=//shrt.url/j3f87h38f;t=fr,bb;a=Kitten Mittens!
Finally, there is an elegant, comfortable mitten for cats.
The image upload thing, though, the convenience there is being able to just upload an image directly into the client, rather than having to deal with some external service. That's it. There isn't much preventing this from being implemented in an IRC client.
Character limits are silly and should be removed - enforce them with a moderation bot if you really have to.
Just because most modern chat services are Electron trash does not mean we should throw out every bit of convenience learned. IRC (clients) could stand to gain better text formatting and file sharing options - things that make life easier for users, and in most cases don't really affect how the actual protocol works.
I was a part of the original Eternal September in the 1980's as the Internet was opened up to undergrads. The idea of a "Reverse Eternal September" sounds super awesome! I wonder how it can be implemented? (In a limited context, not across the whole of the Internet, of course.)
The eternal september happened when the manswarm flooded in; you can't bail out the flood, but it'll drain to a lower-common-denominator cesspool if one is available, and you might be able to build a high enough tower to stay above the waterline.
This is really the only feature I miss in IRC.
I still love IRC. My second home.
http://dx.fi/alt/ircmap/fdp.png here’s a map of IRCnet, they’re really going out of their way to generate netsplits.
A network operated by a single entity doesn’t need such a silly amount of nodes, you can support hundreds of thousands of IRC uses on a single server.
In an increasingly surveillance filled Internet, the fact that what I've said in the past can't be held against me today is a feature, not a bug.
If you don’t adapt, you die. Wanna die? Sure, no one is stopping you.
And when that RFC was made, they made strong decisions about bandwidth costs. They gave up things like federation and more.
So yeah, it's time that it's revisited in making a IRC that can be federated, multiple login/endpoints without using bouncers, and more. I welcome their new RFC. And it it doesn't work, we're free to keep what we currently have.
Of course they aren't, but most people aren't like Drew Devault either. Most people don't use ancient hardware to prove some sort of point. The "Drew Devault will approve of it"-argument generally doesn't show up in a business case.
In a perverse way, I am glad that programmers come up with better and better ways to waste hardware resources. In doing so, they ensure the continued progress of the semiconductor (and battery) industry through mass market demand.
I do not believe it is a coincidence that Moore's law has slowed significantly right at the time when computers became "good enough" for the everyday user. If it wasn't for gamers spending hundreds of dollars on pushing more pixels on-screen, we'd be way behind on deep learning.
Buy a new computer, Drew.
I've purchased a number of computers over the last several decades, yet using facebook/slack is still slower and less responsive on a computer with a Core i7 processor and 16 MB of system memory and a 100 Mbps downstream connection compared with using usenet/irc on a 486 with 16 MB of system memory and a a 28.8 kbps downstream connection.
As one of these greybeards who started with 300 baud modems and text chats in the 80's, and moved onto IRC because the internet was better than BBS's, I wholeheartedly endorse the idea that the only people clinging to the UX garbagefire that is IRC are the people who are either unwilling or unable to adapt to the new reality that modern services offer so much more value than IRC will ever be capable of.
I mean it's not IRC where the protocol is etched on stone tablets but Slack has been thus far a good steward of their API.
Slack is Young and evolving and driven by a single company which wants to push their client
IRC definitely has stability going for it but it also means it has been unable to adapt to user requirements changing over time. The most usable IRC client right now is IRCCloud which is good, but it doesn't inspire much hope because it's only usable since they completely plaster over the protocol in their UI.
In this model there's nothing special about IRC except that it's a common denominator protocol for a few networks that use it. If we were choosing a inter-network protocol I don't think anyone today would come up with IRC.
This is what people said about Twitter as well ;)
And slack, for instance, discontinued their IRC gateways as that limited their possibilities to "innovate" and I can image Slack, being pushed by shareholders, restricting free add-ons to getting data into slack (from Version control, business tools, task trackers, ...) but restricting getting data out to more expensive tiers (making transition of Slack harder)
But there are the key difference between open and proprietary protocols: Open protocols are slow to evolve (see also the state of mail protocols ... where innovation happens mostly in Gmail's protocols, not SMTP/imap/...) but allow wide variety of clients, while proprietary systems can evolve faster, but are more limited in clients.
But we really need to stop trying to make IRC 'work' and build something more usable that can interop with existing IRC networks (hi Matrix!). IRC is fundamentally not a good enough protocol for how people people chat today but it's easy for people who have been using it for 20 years and have a lot of pride and machismo sunk into figuring it to dismiss outsiders that are struggling and believe that if you pile enough barely-working brittleware on top that it can sorta-kinda work like Slack or Mattermost.
The difference between IRC and Slack is that IRC is seen as a standard protocol while for Slack the network protocol is an inofficial implementation detail and any use other than of the official client is unsupported. I'm not very familiar with Slack, but I've heard about Whatsapp users being banned just for the crime of using an alternative client. That's the difference between an open protocol and a proprietary one.
Obviously Slack doesn't provide support for 3rd party clients; how could they? But they do provide support to the developers of those clients using their API.
But that's the thing, I think Slack is a fundamentally inappropriate tool for FOSS work or public communications. Anyone who stakes their long-term community on a single company's proprietary product is asking to be hurt down the road. But I don't think IRC is the right alternative because the UX is so newcomer unfriendly and requires so many disparate 3rd party services to be useful. I would much rather see communities standardize on something like Riot or Mattermost with OpenID.
Simultaneously, I think that Slack (and its contemporaries) are a breath of fresh air for internal team/office chat. Sure it's expensive, and like all corporate-y things you have to keep a little distance so you can migrate when they get shitty, but we can at least acknowledge that it's a damn slick product.
The official Slack client sets the tone for usage there.
Many of the paint points are solved when using alternative clients. Alternative clients will allow you to, for example:
* Use Slack on an ancient computer
* Use TTS systems
* Not use threads (you can just dump everything in the channel)
* Not have link previews
* Use keyboard only
* Get a less distracting experience
I'm also an IRC user and I like it but I just wanted to point out the post isn't fair with Slack if only one client is evaluated.
Edit: list formatting
What happens here is that I don’t see any significant portion of Slack users moving to IRC anytime soon. Therefore, if you’re forced to use Slack, you should know that alternative clients are available as of today.
I kind of feel like the second-to-last paragraph of my article does address this.