Slack has finally decided to close down their IRC and XMPP gateways.
True to form, you can only read their announcement if you already have a Slack
account and are logged in to a workspace.
Here's the gist of their announcement:
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.
They're of course being economical with the truth here.
Perhaps their XMPP gateway can't handle "Shared Channels" and "Threads",
but that's because they purposefully stopped working on it.
A "Shared Channel" simply means a chatroom which people from outside your
workspace can participate in. If a workspace is mapped to a members-only
chatroom, then making something a shared channel simply means updating the members
list or making the chatroom open (so anybody can join it).
Threads can be implemented by adding a <thread> element in the message
stanza, as documented in XEP-201.
And emoji... there's nothing in XMPP that prevents people from sending emoji.
UPDATE: Several readers have pointed out that "emoji reactions" and emoji are different things.
Emoji reactions can be tacked to a particular message.
Still, there's nothing fundamental about XMPP that prevents emoji reactions,
and work is currently underway to add support for them.
The protocol is designed to be eXtensible (hence the X in XMPP) and new features are continuously being added.
Classic bait and switch
We all know the real reason Slack has closed off their gateways. Their business
model dictates that they should.
Slack's business model is to record everything said in a workspace and then to
sell you access to their record of your conversations.
They're a typical walled garden, information silo or
So they have to close everything off, to make sure that people can't extract
their conversations out of the silo.
We saw it with Google, who built Gtalk on XMPP and even federated with
other XMPP servers, only to later stop federation and XMPP support in favour of
trying to herd the digital cattle into the Google+ enclosure.
Facebook, who also built their chat app on XMPP at first allowed 3rd party
XMPP clients to connect and then later dropped interoperability.
Twitter, although not using or supporting XMPP, had a vibrant 3rd party client
ecosystem which they killed off once they felt big enough.
Slack, like so many others before them, pretend to care about interoperability,
opening up just so slightly, so that they can lure in people with
the promise of "openness", before eventually closing the gate once they've
achieved sufficient size and lock-in.
When we talk about "federation" in networks, we mean the ability to communicate
between different service providers.
For example, email is federated. You can set up your own email server, and then
send emails to people with their own email servers, or to people with Gmail or
You can email any other email address in the world, regardless of
where that email address is hosted.
If email never existed, and a company like Slack today would come out with this
brand new concept of "Electronic Mail", let's call it digimail, do you think
they would standardise the digimail protocol and allow you to send messages to
other digimail purveyors?
We all know the answer to that. They won't, and neither would Google, Microsoft
Heck, Facebook is actively trying to replace email since years.
The reason email is federated, is because it was developed before surveillance
capitalism was a thing and because it was established and entrenched
long before these companies came around.
There's a reason why your email address is still the de facto way to sign up
for any service on the web (sometimes with one or two degrees of separation),
and it's because of federation.
XMPP is designed to allow federation. Think about that. Instead of having to
sign up to various different chat providers, all which try to
lock you in and monetize your conversations, you could instead have one chat
account, and use that to chat with anybody else, regardless of which chat
provider they are using.
Alas, that's the dream, but because XMPP came much later to the scene, it
didn't develop the critical mass as email has, and here we are. With dozens of
chat apps, all non-interoperable and closed off.
What would it take for XMPP to take off?
One of the sad things that has come out of Slack's meteoric rise to success,
has been how many free and open source projects have jumped over to using it
(after previously using IRC or XMPP).
In so doing, they have closed off their discussions from search engines and
they prevent people from accessing their past archives.
Slack has many cool features, and they work very well, I'm not going to deny
However, the XMPP Software Foundation has done a lot of work in recent years to
enable protocol extensions that provide features that people have come to
expect from chat applications, for example:
Unfortunately XMPP clients have been lagging far behind in various respects.
One of the main problems is funding. The modern digital economy is largely set
up around surveillance capitalism and user lock-in.
So attempts to create software that doesn't follow these precepts, often end up
unfunded or underfunded.
However, our "weakness", is also our strength.
XMPP clients, and the XMPP network can provide something that Slack never can.
Federation, free and open software, interoperability, extensibility and user choice.
For the last few years I've been working in my spare time on making a
Originally the idea was to make a Gtalk like chat client that you integrate in
your website, and it can still be used like that.
However, in the last year I've updated it further so that it can also be used
as a fullscreen application, like Slack is used.
You can try the fullscreen version at https://inverse.chat/
If you have no-one to chat to, then come join the
This link will take you directly there (via inverse.chat):
Converse.js still lacks lots of features that Slack has, but that's not because
XMPP itself can't support those features.
What converse.js however does have, is that it's free and open source software,
based on a standard protocol and it can be extended, updated and
improved upon, by anyone.
We're actively working on adding new features and more and more people are joining in.
Moreover, anybody can host it and you can integrate it into any website.
Ultimately, I believe in the power and utility of interoperability and software
freedom, even though the current trend is to close off and lock down.
These information silos are as powerful as we make them. If enough projects
choose standardised protocols and FOSS software, we will be able to create
viable alternatives that foster freedom instead of lock-in.