It was quite predictable. Their incentives as a VC-backed, for-profit company aiming for massive IPO are to lock-in as many people as possible. Interoperability works against profitable lock-in. This is why rich, software companies either fight, subvert, or cripple it where possible. So, Slack eventually would ditch that. I doubt they put a lot of effort into maintaining its quality either if it was a marketing gimmick. I don’t use Slack, though, so I can’t say.
Honestly, Slack to me has become a lot more than just chat, and I can see how they can’t coerce their methodology for chat anymore into IRC. Threads are used very extensively by my team, and I can see how that’s hard to fit into IRC. Rich content messages from apps, images, and posts are basically impossible to fit into IRC. I agree that all those things don’t fit into some people’s ideas of an ideal workflow, but they’ve become crucial for a lot of people on Slack, and kind of break in IRC.
I think that the features you mention could be mapped to IRC, with some loss of course, but IRC users are (maybe?) used to a simpler experience.
IIRC, less choice is often touted as a good design practice. But Slack is removing the simple thing in favour of the bells and whistles. It’s not a surprise, but it’s sad.
It’s in the ‘wrong’ place in my stack, but the wee-slack plugin mentioned by @oz claims to have thread support. As a WeeChat plugin has access to windows and buffers I can imagine that being a smoother experience that a plugin in the otherwise ‘correct’ place: the bouncer.
Messages from apps are or could be notices in IRC, and images appear as links that I can click through to see using a web browser. It is certainly true that the more a tool tries to structure a conversation the more difficult it becomes to map that to the IRC protocol. That said, I’m absolutely open to retaining the ability to chat from an IRC client by fixing problems anywhere and everywhere they need to be fixed. There is no fundamental reason a thread feature can’t work outside of the official client.
It’s in the ‘wrong’ place in my stack, but the wee-slack plugin mentioned by @oz claims to have thread support. As a WeeChat plugin has access to windows and buffers I can imagine that being a smoother experience that a plugin in the otherwise ‘correct’ place: the bouncer.
Yeah I can see where you’re coming from. I love wee-slack, and would use it if it had Enterprise Grid support. I just think that Slack is making more and more design decisions that make it hard to shoe-horn back into IRC.
I just think that Slack is making more and more design decisions that make it hard to shoe-horn back into IRC.
If not IRC, then an open, extended version of it or new protocol with a reference client. Worst case is that important stuff like messages stay in the open system whereas extra bells and whistles end up in proprietary system. Less transition cost later if people want to ditch Slack for something better. An open, reference implementation people are using in a lot of environments would also give them more testing of their protocols. They definitely have the money for it at their revenue levels.
They’re locking it up instead since it’s more profitable in the long run for the founders and investors. The good news is they might have at least inspired some revamps of IRC or chat that will be done better for us without their problems. I think I’ve already seen some like that but we gotta wait to see who gets a sound, business model going.
I’m hoping that new protocol will be matrix. It’s open, federated, has good support for bridges (even a slack bridge), and a solid e2e encryption design (with some polishing left in the implementation to do). There are lots of clients, with riot.im being the most featureful.
I’ve used the Jabber gateway to connect to HipChat and the IRC gateway to connect to Slack. Hands down the Slack gateway was the superior experience. You could, to be sure, tell you were not connecting to a real IRC server. The experience was remarkably good anyway. by comparison, my messages in to HipChat would sometimes take hours (actual multiple hours) to be received–completely crippling my ability to participate.
As Slack has evolved over the years, we’ve built features and capabilities — like Shared Channels, Threads, and emoji reactions (to name a few) — that the IRC and XMPP gateways aren’t able to handle. Our priority is to provide a secure and high-quality experience across all platforms, and so the time has come to close the gateways.
We know this may affect your workflow in ways that are frustrating or disruptive, and we’re here to help and answer questions. Thank you in advance for making this transition with us.
Please note that the gateways will be closed according to the following schedule:
March 6, 2018: No longer available to newly-created workspaces
April 3, 2018: Removed from workspaces where they’re not in use
May 15, 2018: Closed for all remaining workspaces
If your workspace currently uses gateways, your experience won’t change until May 15th. But we encourage you to prepare for the transition soon. Feel free to contact our support team for help.
Accessibility & screen reading
We are focused on making Slack accessible to all people. Over the past year, we’ve made great progress in improving both the keyboard and screen reading experiences in Slack. We know many users have been relying on IRC and XMPP clients for a more accessible experience — but our goal is to build all of the accessibility features you need directly into Slack.
Navigating Slack by keyboard: In addition to Slack’s keyboard shortcuts and basic keyboard accessibility, you can now work in Slack using our new, more efficient navigation model.
Using a screen reader in Slack: We’ve also been improving the screen reader experience. Here’s what you’ll find:
All UI elements are accessible by keyboard and functional with a screen reader
We’ve improved our UI labeling & naming, including ARIA landmarks
Interactions like the message input autocomplete have also been enhanced with ARIA
We’ve improved the virtual and focus navigation experience for reading messages
Message content, states (e.g. stars, pins, etc.) and actions (e.g. reply, react) are fully perceivable
These changes are just the beginning of our accessibility journey. We’ll be releasing further improvements in the near future!
Creative uses of gateways
Although the gateways were never supported as a developer feature, many of you have built useful and creative integrations that rely on them. We recognize removing these gateways may disrupt your work, but we’re hopeful that our Real Time Messaging and Events APIs will meet the majority of your integration & bot needs.
Many other creative uses of gateways are now supported with full-fledged features right in Slack, like setting per-channel notifications, searching logs, sending email straight to Slack, and more. A quick search in our Help Center is an easy way to see if Slack’s capabilities now cover your use case, or you can reach out to our support team.
XMPP and IRC Disabled
Guest accounts are not permitted to use the XMPP and IRC gateways.
We are focused on making Slack accessible to all people. Over the past year, we’ve made great progress in improving both the keyboard and screen reading experiences in Slack. We know many users have been relying on IRC and XMPP clients for a more accessible experience — but our goal is to build all of the accessibility features you need directly into Slack.
What if your accessibility reason is because the client is crap?
One of my secret powers, using the IRC gateway, was a complete log history. I gather the free tier expires messages after some time or message limit. Twice I’ve gone in to my own logs to recover a conversation we needed to reference.
I’m a big fan of this feature as well. Even though my company has a paid account with access to the entire history through the UI, it’s still way faster and more flexible to just grep through the folder. However, you don’t have to use the IRC gateway – wee-slack will take care of this as well (assuming you use WeeChat, of course).
I’m a heavy user of the Slack IRC gateway. I have been expecting this news but am gravely disappointed by it. I use Slack to stay in touch with largely non-technical folk that don’t find the IRC experience worth their time. I would like to stay in touch with these folk. Just as they’re not willing or able to use IRC, I can’t and won’t use the Slack interface. I need chat to work like IRC or it doesn’t work for me.
What are my options? I’d be happy to sign a contract and fix whatever technical issue Slack thinks it has with it’s IRC gateway. I’d be happy to discover or fix any plugin for ZNC or bitlbee that would let me continue to chat. What would it take to make my IRC client participate on Slack servers?
oops: I submitted the same story without realizing it had just been posted.
Do any of you using IRCCloud have experience with the Slack integration in that product? I work with one group that picked Slack as their communication platform, with IRCCloud being the second choice.
The bitlbee dev team cited the existence of the official IRC gateway as rationale for refusing to support Slack. Perhaps they will change their mind now?
#bitlbee on OFTC is chittering about it just this moment. I wouldn’t describe it as particularly focused, as discussions go, but there is apparently a Slack module for libpurple.
I’m on a number of Slack instances, and the answer is particular to each one. Two of them were formerly Facebook Messenger groups. I helped with the technology selection for one (where we eventually picked Slack) and on the success of that migration shared my experience with the other group (where we eventually picked Slack).
These two groups don’t particularly need Slack, the product, but are served using a communication tool like Slack. Slack was and is a plausible replacement for Facebook Messenger. Another tool would also have to be.
Have you used IRCCloud? It’s a potential option for me for Slack servers I connect to, but not an option for some IRC servers–I’m not willing for some of my traffic to leave my network without e2e.
I never had access to the IRC gateway (admins at work refused to turn it on) so this has been a life-saver since I started my job. It works much better than I was expecting.
Like other folks have said, I’ve also been dreading this. There’s not a lot of chat rooms that are worth the RAM and UI of Slack. Thanks very much for this link. I’ve been considering a move from irssi to weechat for a few years (my twitter client is unmaintained and I don’t enjoy the Perl), maybe this will be the final push to get me to shave this yak.
I moved from irssi to weechat under duress myself. After an OS upgrade bold ceased working for me and was not able to fix it! I find weechat better designed: I’ve used it as an example of convergent evolution in tooling, by comparing irssi and weechat to screen and tmux: both irssi and screen feel haphazard whereas weechat and tmux have a more layered, bottom-up design.
All in all I’m happy to have moved to weechat. I must admit however I still keep an irssi running for the things I haven’t managed to port yet. It’s one of the rougher migrations I’ve had.
Slack often is desired by users, sometimes even set up as clandestine shadow IT uncontrolled by corporate sysadmins. If organized labour is made of these people, it seems logical to assume those people would want Slack there too.
it’s logical that they would want some form of communication, if that’s what you mean. but i don’t see where you get to slack being the obvious choice.
Regrettably, in the US, most software professionals are opposed to unionization; and outspokenly supporting them is hazardous to one’s employment. Furthermore, unionization presents a path to removing Slack from the workplace, but certainly does not guarantee it.
Many of the features they claim that IRC doesn’t support it does in fact support nowadays as IRCCloud and others are cooperating on creating modern IRC specifications that make IRC more on par with the Slack experience than classic IRC is. Link: https://ircv3.net/
Unfortunately, I don’t have much faith with IRCv3 - it’s barely been implemented, and one of the IRCv3 people I talked to left and gave up on it - he’s now supporting Matrix, due to it basically being an independent JSON reimplementation of a proposed binary replacement idea for IRCv3 that resolved much of its fundamental problems, and free of IRC “culture.”
How many ways do 2 people have to communicate nowadays!
If we do not use open standards, human communication is in the hand of companies, and we are doomed!
IRC for communities IM, Mail/NNTP for long-lasting threads, Tox for video chat. What else do we need? Why should we use a company’s service while you can have such a good experience with open and free solutions?
My vision: Advertising. If you use anything not open, my bet is that you have been affected by advertizing at some point, or live with people affected by advertizing.
On the other hand, it is hard not to use Slack if everyone at your job use Slack, or to get your non tech-savvy family use something else than Skype if they stick to it.
While I prefer antipodean solution like ii, if you are seeking for a “modern, web-based solution” instead of an “old rusty terminal”, you can use https://thelounge.chat or other web self-hosted client for IRC. They also work for mobile phones, and will save the backlog in case of disconnection.
The problem is these protocols died out because they didn’t evolve - they were unfortunately replaced with proprietary equivalents.
Like, NNTP - moderation is effectively non-existent there. IRC doesn’t have rich media support and mobile sucks. Tox is actually modern, I’ll give you that, but has poor implementations and a drama-filled development team.
Well, IRC was always federated - it’s just that the federation broke apart due to the Eris incident, caused by protocol flaws and an administration refusing to work around them.
For IRC the idea is to use other protocol for everything rich-media. Some might say it is a workaround, some other that it is the proper way to do it. But then each and every client would need to implement fetching images and whatnot to make it look like a “modern chat client”.
Looks like a tradeoff.
It looks like NNTP have been eaten by mailing lists.
drama-filled development team
I always wondered what does http://tox.im was all about!
It was quite predictable. Their incentives as a VC-backed, for-profit company aiming for massive IPO are to lock-in as many people as possible. Interoperability works against profitable lock-in. This is why rich, software companies either fight, subvert, or cripple it where possible. So, Slack eventually would ditch that. I doubt they put a lot of effort into maintaining its quality either if it was a marketing gimmick. I don’t use Slack, though, so I can’t say.
Interop feels a lot like what some leaders said about democracy:
It’s like a train. You get off when you reached your destination.
Honestly, Slack to me has become a lot more than just chat, and I can see how they can’t coerce their methodology for chat anymore into IRC. Threads are used very extensively by my team, and I can see how that’s hard to fit into IRC. Rich content messages from apps, images, and posts are basically impossible to fit into IRC. I agree that all those things don’t fit into some people’s ideas of an ideal workflow, but they’ve become crucial for a lot of people on Slack, and kind of break in IRC.
I think that the features you mention could be mapped to IRC, with some loss of course, but IRC users are (maybe?) used to a simpler experience.
IIRC, less choice is often touted as a good design practice. But Slack is removing the simple thing in favour of the bells and whistles. It’s not a surprise, but it’s sad.
Could you be more specific? This is a Slack-IRC gateway using the recent IRCv3 drafts for threads, reactions and rich content messages: https://twitter.com/irccloud/status/971416931373854721
As far as I can see, IRC can handle all these just fine.
It’s in the ‘wrong’ place in my stack, but the wee-slack plugin mentioned by @oz claims to have thread support. As a WeeChat plugin has access to windows and buffers I can imagine that being a smoother experience that a plugin in the otherwise ‘correct’ place: the bouncer.
Messages from apps are or could be notices in IRC, and images appear as links that I can click through to see using a web browser. It is certainly true that the more a tool tries to structure a conversation the more difficult it becomes to map that to the IRC protocol. That said, I’m absolutely open to retaining the ability to chat from an IRC client by fixing problems anywhere and everywhere they need to be fixed. There is no fundamental reason a thread feature can’t work outside of the official client.
Yeah I can see where you’re coming from. I love wee-slack, and would use it if it had Enterprise Grid support. I just think that Slack is making more and more design decisions that make it hard to shoe-horn back into IRC.
If not IRC, then an open, extended version of it or new protocol with a reference client. Worst case is that important stuff like messages stay in the open system whereas extra bells and whistles end up in proprietary system. Less transition cost later if people want to ditch Slack for something better. An open, reference implementation people are using in a lot of environments would also give them more testing of their protocols. They definitely have the money for it at their revenue levels.
They’re locking it up instead since it’s more profitable in the long run for the founders and investors. The good news is they might have at least inspired some revamps of IRC or chat that will be done better for us without their problems. I think I’ve already seen some like that but we gotta wait to see who gets a sound, business model going.
I’m hoping that new protocol will be matrix. It’s open, federated, has good support for bridges (even a slack bridge), and a solid e2e encryption design (with some polishing left in the implementation to do). There are lots of clients, with riot.im being the most featureful.
I’ve used the Jabber gateway to connect to HipChat and the IRC gateway to connect to Slack. Hands down the Slack gateway was the superior experience. You could, to be sure, tell you were not connecting to a real IRC server. The experience was remarkably good anyway. by comparison, my messages in to HipChat would sometimes take hours (actual multiple hours) to be received–completely crippling my ability to participate.
Here’s the full text for anyone that doesn’t have an account: https://i.imgur.com/6iUWOzf.png
Saying goodbye to Slack’s IRC and XMPP gateways
As Slack has evolved over the years, we’ve built features and capabilities — like Shared Channels, Threads, and emoji reactions (to name a few) — that the IRC and XMPP gateways aren’t able to handle. Our priority is to provide a secure and high-quality experience across all platforms, and so the time has come to close the gateways.
We know this may affect your workflow in ways that are frustrating or disruptive, and we’re here to help and answer questions. Thank you in advance for making this transition with us.
Please note that the gateways will be closed according to the following schedule:
If your workspace currently uses gateways, your experience won’t change until May 15th. But we encourage you to prepare for the transition soon. Feel free to contact our support team for help.
Accessibility & screen reading
We are focused on making Slack accessible to all people. Over the past year, we’ve made great progress in improving both the keyboard and screen reading experiences in Slack. We know many users have been relying on IRC and XMPP clients for a more accessible experience — but our goal is to build all of the accessibility features you need directly into Slack.
Navigating Slack by keyboard: In addition to Slack’s keyboard shortcuts and basic keyboard accessibility, you can now work in Slack using our new, more efficient navigation model.
Using a screen reader in Slack: We’ve also been improving the screen reader experience. Here’s what you’ll find:
All UI elements are accessible by keyboard and functional with a screen reader We’ve improved our UI labeling & naming, including ARIA landmarks Interactions like the message input autocomplete have also been enhanced with ARIA We’ve improved the virtual and focus navigation experience for reading messages Message content, states (e.g. stars, pins, etc.) and actions (e.g. reply, react) are fully perceivable These changes are just the beginning of our accessibility journey. We’ll be releasing further improvements in the near future!
Creative uses of gateways
Although the gateways were never supported as a developer feature, many of you have built useful and creative integrations that rely on them. We recognize removing these gateways may disrupt your work, but we’re hopeful that our Real Time Messaging and Events APIs will meet the majority of your integration & bot needs.
Many other creative uses of gateways are now supported with full-fledged features right in Slack, like setting per-channel notifications, searching logs, sending email straight to Slack, and more. A quick search in our Help Center is an easy way to see if Slack’s capabilities now cover your use case, or you can reach out to our support team.
XMPP and IRC Disabled
Guest accounts are not permitted to use the XMPP and IRC gateways.
What if your accessibility reason is because the client is crap?
One of my secret powers, using the IRC gateway, was a complete log history. I gather the free tier expires messages after some time or message limit. Twice I’ve gone in to my own logs to recover a conversation we needed to reference.
I’m a big fan of this feature as well. Even though my company has a paid account with access to the entire history through the UI, it’s still way faster and more flexible to just grep through the folder. However, you don’t have to use the IRC gateway – wee-slack will take care of this as well (assuming you use WeeChat, of course).
I’m a heavy user of the Slack IRC gateway. I have been expecting this news but am gravely disappointed by it. I use Slack to stay in touch with largely non-technical folk that don’t find the IRC experience worth their time. I would like to stay in touch with these folk. Just as they’re not willing or able to use IRC, I can’t and won’t use the Slack interface. I need chat to work like IRC or it doesn’t work for me.
What are my options? I’d be happy to sign a contract and fix whatever technical issue Slack thinks it has with it’s IRC gateway. I’d be happy to discover or fix any plugin for ZNC or bitlbee that would let me continue to chat. What would it take to make my IRC client participate on Slack servers?
oops: I submitted the same story without realizing it had just been posted.
Do any of you using IRCCloud have experience with the Slack integration in that product? I work with one group that picked Slack as their communication platform, with IRCCloud being the second choice.
IRCCloud’s slack integration is great. While there are some issues they are working out the developers have been nothing but responsive and helpful.
This might be relevant to you:
https://twitter.com/IRCCloud/status/971416931373854721
The bitlbee dev team cited the existence of the official IRC gateway as rationale for refusing to support Slack. Perhaps they will change their mind now?
#bitlbee on OFTC is chittering about it just this moment. I wouldn’t describe it as particularly focused, as discussions go, but there is apparently a Slack module for libpurple.
Would moving away from Slack work for you?
I’m on a number of Slack instances, and the answer is particular to each one. Two of them were formerly Facebook Messenger groups. I helped with the technology selection for one (where we eventually picked Slack) and on the success of that migration shared my experience with the other group (where we eventually picked Slack).
These two groups don’t particularly need Slack, the product, but are served using a communication tool like Slack. Slack was and is a plausible replacement for Facebook Messenger. Another tool would also have to be.
What about irccloud? https://www.irccloud.com/
Have you used IRCCloud? It’s a potential option for me for Slack servers I connect to, but not an option for some IRC servers–I’m not willing for some of my traffic to leave my network without e2e.
Sad to see these go.
I’ve been using wee-slack for a few weeks now, and it looks like I will have to get used to it.
I never had access to the IRC gateway (admins at work refused to turn it on) so this has been a life-saver since I started my job. It works much better than I was expecting.
Conversely, while my workplace has the IRC gateway enabled, I can’t use wee-slack because I don’t have perms to install their Slack integration :-/
Like other folks have said, I’ve also been dreading this. There’s not a lot of chat rooms that are worth the RAM and UI of Slack. Thanks very much for this link. I’ve been considering a move from irssi to weechat for a few years (my twitter client is unmaintained and I don’t enjoy the Perl), maybe this will be the final push to get me to shave this yak.
I moved from irssi to weechat under duress myself. After an OS upgrade bold ceased working for me and was not able to fix it! I find weechat better designed: I’ve used it as an example of convergent evolution in tooling, by comparing irssi and weechat to screen and tmux: both irssi and screen feel haphazard whereas weechat and tmux have a more layered, bottom-up design.
All in all I’m happy to have moved to weechat. I must admit however I still keep an irssi running for the things I haven’t managed to port yet. It’s one of the rougher migrations I’ve had.
you’ll only be disappointed by this if you trusted slack in the first place
For many of us I assume this isn’t so much of a choice because it’s mandated by our employer.
unionize!
then the union is on slack too
yours is?
Slack often is desired by users, sometimes even set up as clandestine shadow IT uncontrolled by corporate sysadmins. If organized labour is made of these people, it seems logical to assume those people would want Slack there too.
it’s logical that they would want some form of communication, if that’s what you mean. but i don’t see where you get to slack being the obvious choice.
What makes you think that a union wouldn’t choose Slack?
union members are likely to care about freedom
Yup.
:(
Regrettably, in the US, most software professionals are opposed to unionization; and outspokenly supporting them is hazardous to one’s employment. Furthermore, unionization presents a path to removing Slack from the workplace, but certainly does not guarantee it.
it’s illegal to fire someone for organizing a union
It’s illegal but it happens all the time.
They are?
Many of the features they claim that IRC doesn’t support it does in fact support nowadays as IRCCloud and others are cooperating on creating modern IRC specifications that make IRC more on par with the Slack experience than classic IRC is. Link: https://ircv3.net/
Unfortunately, I don’t have much faith with IRCv3 - it’s barely been implemented, and one of the IRCv3 people I talked to left and gave up on it - he’s now supporting Matrix, due to it basically being an independent JSON reimplementation of a proposed binary replacement idea for IRCv3 that resolved much of its fundamental problems, and free of IRC “culture.”
A pity if so :/ Progressively enhancing IRC was a way that I found promising
How many ways do 2 people have to communicate nowadays!
If we do not use open standards, human communication is in the hand of companies, and we are doomed!
IRC for communities IM, Mail/NNTP for long-lasting threads, Tox for video chat. What else do we need? Why should we use a company’s service while you can have such a good experience with open and free solutions?
My vision: Advertising. If you use anything not open, my bet is that you have been affected by advertizing at some point, or live with people affected by advertizing.
On the other hand, it is hard not to use Slack if everyone at your job use Slack, or to get your non tech-savvy family use something else than Skype if they stick to it.
I wish you luck through this all!
While I prefer antipodean solution like ii, if you are seeking for a “modern, web-based solution” instead of an “old rusty terminal”, you can use https://thelounge.chat or other web self-hosted client for IRC. They also work for mobile phones, and will save the backlog in case of disconnection.
https://thelounge.chat
The problem is these protocols died out because they didn’t evolve - they were unfortunately replaced with proprietary equivalents.
Like, NNTP - moderation is effectively non-existent there. IRC doesn’t have rich media support and mobile sucks. Tox is actually modern, I’ll give you that, but has poor implementations and a drama-filled development team.
https://matrix.org/ is a pretty interesting proposition. it’s basically federated irc.
Well, IRC was always federated - it’s just that the federation broke apart due to the Eris incident, caused by protocol flaws and an administration refusing to work around them.
sounds like the protocol wasn’t really built with federation as the focus then?
It was, it’s just that the protocol was very naïve and trusting, much like how the rest of the internet was.
Ah so it is bad, so I guess this is irc but better at doing the thing that irc was designed for.
For IRC the idea is to use other protocol for everything rich-media. Some might say it is a workaround, some other that it is the proper way to do it. But then each and every client would need to implement fetching images and whatnot to make it look like a “modern chat client”.
Looks like a tradeoff.
It looks like NNTP have been eaten by mailing lists.
I always wondered what does http://tox.im was all about!
Personally I’m very satisfied with Discord: the client is lightweight, infinite history, and free.
I think all the gaming stuff will be a major barrier keeping businesses from trying Discord.
webshit is webshit; it’s just slack with a cringier aesthetic