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-0201.
Emoji reactions can be tacked to a particular message. There’s nothing fundamental about XMPP that prevents emoji reactions, and [work is currently underway to add support for them](https://github.com/jabber t/jabbercat/issues/80). The protocol is designed to be eXtensible (hence the X in XMPP) and new features are continuously being added.
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 Siren Server
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.
On Federation
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 Yahoo! accounts.
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 or Facebook.
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 it.
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:
- Message threading XEP-0201
- Last message corrections XEP-0308
- Message delivery receipts XEP-0184
- Markdown-like syntax for messages XEP-0393
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.
Converse
For the last few years I’ve been working in my spare time on making a JavaScript XMPP chat client, called Converse.
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 discuss@conference.conversejs.org chat room.
This link will take you directly there (via inverse.chat): https://inverse.chat/#converse/room?jid=discuss@conference.conversejs.org
Converse still lacks lots of features that Slack has, but that’s not because XMPP itself can’t support those features.
What Converse 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.
