Slashdot Mirror
Slack Is Shutting Down Its IRC Gateway (slack.help)
Slack, a team collaboration communication service, has updated its IRC support page to note that it is ending support for IRC on its platform: Unfortunately, support for gateways is ending. Starting on May 15th, it will no longer be possible to connect to Slack using the IRC and XMPP gateways. In another support page, which requires you to log in to one of your Slack groups, the company elaborates: 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.
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.
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.
The whole IRC and XMPP compatibility of Slack was used as an argument to placate the old timers at my company.
Mostly I've found that people waste too much time making custom emoji and spend too little time working out real business due to the security and retention policies inherent in the Slack services.
Hopefully this can trigger some businesses to walk away from this seemingly useless tool.
“Common sense is not so common.” — Voltaire
We want to support more superfluous shiny garbage and supporting IRC might remind people they don't need this bullshit.
They are shutting down the gateway because their system is more advanced than IRC and other XMPP clients? The entire point of the gateway is to allow two disparate systems to work with each other, even with limited features.
I'm more concerned about the trend to https-only on the internet. Eventually the only ports open will be 53 and 443. At that point, the internet will be silo'd into a consumer-only model just like cable TV. I think you can imagine what will happen past that.
some karma... and kinda lukewarm about it.
https://xkcd.com/1782/
One of the big reasons to use the gateway was simple - the web client, the node.js "app" and all that were resource hogs. Probably one of the few chat things that needs an i7 with 32GB of RAM just to use it.
Had one project where I was forced to use it, and was so dismayed when it seemed to consume half of one processor core and a ton of RAM. OF course, the IRC client takes 0% most of the time and barely any memory at all
It doesn't have to be this way, since Discord offers similar features, and yet happily consumes barely any processor and memory.
... if Slack is not based on XMPP itself.
crap crap crapity crap.
Dang slack app is a wretched reeking steaming pile. Getting stuck with slack has been tolerable with the XMPP gateway. Bleah.
I want information density. Text, that I can relegate to one side of the screen. Not a whole page taken up with pretty-pretty whitespace and formatting diddlypoo.
Yes because a cron job to reenew letsencrypt every (vas it 60 or 90) days an reload your http deamon rakes so much time. Ok Iâ(TM)ll admit youâ(TM)ll probably use a bit more electricity, but comated to the other things usualy running on a web server tls is not your biggest problem.
OMG, Facebook is just MySpace with no user customization and a terrible homepage!
Come on over to Riot.im or any other Matrix server. They love bridges, more all the time! Plus, it's federated and supports encryption.
the worst features define interprotocol interaction. threads are shit. the whole emoji thing is utterly pointless and doesn't add a shred of anything productive.
on the other hand, those assholes on irc that try to do lame slack shit just look stupid, millenial, and well, just fucking stupid.
Slack is progressively getting to be a company that is just going down the corporate toilet. Discord is eating its lunch but I don't think Slack even knows what its lunch is anymore. It doesn't give a crap about 99% of the market.. it keeps getting smaller and smaller and yet more and more resource intensive. No developments have helped it and it is hell bent on alienating its own usage by not changing archaic price models or anything. Total crap.
Yeah, most of us consider lack of emoji support a feature not a bug.
IRC, XMPP (depending on the server), nntp, etc could be set up quite quickly and easily if you didn't need federating support.
What IRC server software handles persistence and attachments? And how big of a virtual machine is needed to run it?
The http-01 challenge needs to be able to connect to your server from random locations on the Internet. This is unacceptable for many servers internal to an organization. And the dns-01 challenge is a lot harder to automate, especially if your domains happen to currently be registered with a registrar whose bundled DNS zone hosting doesn't have an API that Dehydrated can use.
Discord offers similar features, and yet happily consumes barely any processor and memory.
Since when? Discord's downloadable client is an Electron application, and last time I tried it (on Debian), its three Chromium processes combined took 365 MB. Skype's downloadable client for Linux also uses Electron and also takes hundreds of megabytes of RAM.
I hate the idea of letting some third party proprietary host (like Slack) decide how and when it should work for me, though.
Personally, I'm running a Rocket.Chat instance - very Slack-like (and "Slack-compatible" if you have any bots you've developed for Slack's API that you want to use). Mattermost is another, similar option.
Hacker Public Radio is our Friend
... since everyone will need to double their system's memory to send their co-workers a morning "Yo."
Slack is basically just expensive IRC with a web client after all >:)
"When information is power, privacy is freedom" - Jah-Wren Ryel
What IRC server software handles persistence
Most bouncers like ZNC.
and attachments?
Client-side thing. DCC if you want. Pastebin otherwise. IMHO nothing that should be proper part of IRC.
And how big of a virtual machine is needed to run it?
It has to be at least this |-----------------| big.
CLI paste? paste.pr0.tips!
Most bouncers like ZNC.
Which IRC client integrates seamlessly with a bouncer, such that scrolling to the top of the scrollback automatically requests past messages from the bouncer and integrates them into the scrollback?
Client-side thing. DCC if you want.
Good luck reliably DCCing from one NAT to another, especially for users behind an ISP that applies carrier grade NAT to all home subscribers. And good luck DCCing when the user who sent the file is offline. To make that work, you'd end up having to integrate DCC into the bouncer, turning it into a pastebin. About that:
Pastebin otherwise.
Which IRC client for each of the five major operating systems (X11/Linux, Android, Windows, macOS, and iOS) has a decent pastebin client?
IMHO nothing that should be proper part of IRC.
In the same way that GNU, Apache or NGINX, MySQL or PostgreSQL, and PHP or Python aren't part of Linux proper, which is a kernel. Distributions combine them. So which distribution of IRC server, bouncer, and pastebin server is any good?
[A VM to run an IRC server, bouncer, and pastebin server] has to be at least this |-----------------| big.
How big is that in RAM megabytes and storage gigabytes?
such that scrolling to the top of the scrollback automatically requests past messages from the bouncer and integrates them into the scrollback?
Any why would you want this oddly specific and useless mechanism? Why does the scrollback have to be requested on demand?
Because people accustomed to Slack, Skype, or Discord demand the ability of a proposed replacement therefor to review and search chat history. It's likely that you have some model to review and search chat history in mind that you find superior to infinite scrolling; what is it?
An IRC client having a pastebin client? Why do I get the impression I'm talking to a Windows user here...
You're talking not to a user of Windows but instead to a user who collaborates with other team members who use Windows and tries to convince said team members to switch from Slack, Skype, or Discord to a combination of some IRC server and client, a bouncer, and a pastebin. They are accustomed to a user experience that integrates IRC, bouncer, and pastebin.
Apples and Oranges, IRC is not software, it's specification.
I am aware that IRC proper is a specification for client to IRC server communication. That's why I mentioned "Apache or NGINX", as both are examples of servers that follow the HTTP specification for web browser to web server communication. But what is the specification for client to bouncer communication for the actions of reviewing and searching chat history? And what is the specification for client to pastebin communication? Among SFTP, FTPS, and WebDAV over HTTPS, which is preferred?
Check out wee-slack which is a python script for weechat that uses the slack api. Very easy to setup and works great. You get a lot more features using this and it's a good enough alternative for me.
I've got some potentially life-changing news for you: you don't need to use your registrar's bundled DNS.
Apart from Cloudflare, with which "other free options out there" for name hosting do readers have experience?
This is on par with the general move of the internet towards walled gardens. From independent websites and blogs with RSS feeds for updates to Facebook/Twitter to abandoning the web itself in favor of apps. Also, every once in a while you'll see an article in the business/tech press bemoaning the existence of email when there are so many wonderful proprietary alternatives.
If XMPP had become as widespread as POP/SMTP/IMAP, we would've been able to chat as easily we can send an email, using any combination of client and provider.
"..One hosts to look them up, one DNS to find them, and in the darkness BIND them."