I think the key deciding factor isn't even technical, but: if you want to enter Slack (or Zoom, or similar), it is streamlined, easy and clear what you need to do. Compare it to IRC, where you have to find a client, make the choice, and make many other small decisions. It's also about immediate benefit: the way many people try to start with IRC involves searching for rooms and trying to somehow fit in and enter the conversation, while the local culture may not be welcoming or easy to get into.
That said, I've succeeded in gradually getting some of my friends onto Riot/Matrix. To be clear, I did it without much technical/ideological evangelizing or being obtuse, just on the basis of them wanting to talk to me and in our social group. But Riot is also at least nice-looking, multiplatform, has modern features etc. Things that are still annoying:
1. Dealing with Riot/Matrix system/client confusion. Most people don't care about such distinctions, I should probably just focus on talking about Riot. (I understand that developers may choose to do different in their communication)
2. Entering into 1/1 conversations. I still don't know/remember how to reliably do it with a new person, always did it by trial and error by trying to invite in ways X and Y etc. It probably requires finding the opt-in into email invitations in the configuration by each participant. I understand these are some anti-stalking measures, but God is it annoying.
> Dealing with Riot/Matrix system/client confusion. Most people don't care about such distinctions, I should probably just focus on talking about Riot.
The thing I haven’t figured out is... why would people find this hard to understand for chat, but not for email? Everyone uses email, and everyone knows they can send an email to whatever email address they want no matter who their provider is.
I don't see it as a question of understanding as much as caring. It's not very realistic to do a "here's technical details of the protocol we'll be using" talk every time you invite someone.
They probably don’t care that much in the case of email either. Would it be better to explain it by analogy? “This is like email, you pick a provider and you can talk to anyone from there.”
Okay, I can agree with your framing from the sibling:
> I’m not convinced that open/federated protocols are inherently more difficult for people in general to understand.
We may be disagreeing on the hierarchy of the goals. I think the priorities here are:
1. That the protocol is open and decentralized from the operator perspective (which is ensured in the case of Matrix).
2. That many people use it.
The #1 should be important for an opinionated minority pushing everyone else. The good thing is, non-technical people usually don't have much brand loyalty in these things. It's purely perceived convenience.
That the majority of people understand and care about #1 may or may not be realistic. I see it as partially another cause. Today, we have much of de facto centralization in email while the protocol is still decentralized. It would be nice to push chat to a more or less similar state and work from there. (I would also gladly see decentralization and inter-operation of many things enforced by law, but this is even more pie in the sky.)
Still, certainly your analogy can be used in communicating with people. But the main thing I'm trying to achieve is #2, getting them on board anyway.
Yeah, I think we largely agree. I'm mostly aiming for #2, because I'm hoping that if we can get enough people using something that's hard to centralize, network effects will take care of #1.
Consider email for example: I think the main reason it's stuck around with us for so long is that we're at the point where being reachable by email is just expected. With everyone using email, someone trying to replace it with a centralized option would need to get everyone on board, while someone who wants to interoperate with email in general doesn't have that issue.
ISPs and phone companies are similar; nobody's going to start one that can't interoperate with the others nowadays. The public wouldn't stand for it, even if they couldn't explain why in terms of the underlying protocols.
While I would certainly love it if we could get people to care about open protocols, I think getting enough adoption of an open protocol would really be sufficient, so long as it's not easy for one big player to lock it down. (Google Talk for example; it was XMPP, but Google was the only player that mattered then as far as the public was concerned. Matrix is in a better position than that now.)
They may not understand the underlying architecture, but they definitely do understand it from a user perspective - they can send an email regardless of provider.
Telephones are the same way, too. You get a phone number from whatever company you want and can use it to call people no matter what provider they’re using.
I’m not convinced that open/federated protocols are inherently more difficult for people in general to understand.
I think you are overestimating the level of understanding a lot of people have. For lots of people, IE == the internet. Start Firefox: "My internet looks different". Same for Outlook vs GMail.
The average office worker (and home computer user?) has eg. Outlook installed and set up by the IT department.
But yes, the analogy with cell phone providers is useful. With this analogy, who would still tie their social media profile to a single provider?
It's not the idea that you can chat with people on other providers it's that you still have to choose a provider with no real guide on how you would make an informed decision among them.
You choose your phone provider by looking at the top 3 or so established providers and the choice is usually made on price or other signing incentives. With your ISP you just pick from a couple ISPs that serve your area. With email you just pick GMail or whatever your work gives you.
All of these decentralized chat systems just need to act centralized. Have Matrix.org just be the matrix server that people sign up on and let the fact that other providers exist just be something that comes naturally. Have Mastadon be the StatusNet server but casually interface with other servers.
What seems to kill these projects is that the group positioned to own the market actively shoots themselves in the foot in an attempt to not become too big.
Let the protocol be an implementation detail. Sell the provider as a service.
> The thing I haven’t figured out is... why would people find this hard to understand for chat, but not for email? Everyone uses email, and everyone knows they can send an email to whatever email address they want no matter who their provider is.
I see you haven't worked in corporate IT very much. You're missing the comparison too, Riot isn't the service, it's the client, and there are a crapload of people in the corporate world who "aren't computer people" and for whom Outlook is email. Or AOL. Or Gmail. Whichever email client they encountered first, that is email to them.
They know they can email people at different companies, they just don't know or care that many of those people are not using the same client.
> think the key deciding factor isn't even technical, but: if you want to enter Slack (or Zoom, or similar), it is streamlined, easy and clear what you need to do. Compare it to IRC, where you have to find a client, make the choice, and make many other small decisions.
> 1. Dealing with Riot/Matrix system/client confusion. Most people don't care about such distinctions, I should probably just focus on talking about Riot.
Ugh, this is depressingly on the nose. As someone who loves choice in his software it's hard to admit that most people are beyond not caring and it is legitimately a negative factor for a lot of people to have to pick.
> Compare it to IRC, where you have to find a client, make the choice, and make many other small decisions.
A lot of these are one time decisions though. Once I install a client and configure it, then all I have to do for subsequent uses is to start the client and it will automatically connect to the server, set my nick, and join the channels I was in.
With Slack, you still have to create an account, find a workspace, join channels or get invited to them, etc. But once that's done, then you just need to open the Slack client and log in and it will load up the page, much like an IRC client does.
Slack wasn't competing with IRC. By the time Slack launched, IRC usage within companies was a very tiny slice of the market, mainly by very technical people. Slack was competing with Microsoft Lync, Google Talk, HipChat, Campfire, and the various other "IM for businesses" software products that were available in 2013.
Yes, Slack borrowed some of the better features from IRC, which helped drive its popularity, but very, very few companies that are currently paying for Slack would have considered IRC to be a reasonable alternative.
I consider one of the biggest deal-breakers being able to snip part of your screen with a keyboard shortcut and Ctrl-V it into the client for everyone to see it inline, seamlessly. You don't have to mess around with image uploaders or open image links externally in your browser.
Want to send a file to someone? Drag and drop, done. No hassle and it works for everyone, in the same way, without having to explain anything, use an external website, install a dependency, or change a setting.
Same as with Discord, these modern chat clients support richer content, have nicer looking UIs, better UX which draw more people in.
It's more fun to code bots for them because you can make them do amazing stuff, as the output doesn't just have to be plain text, but it can also be rich content like charts, embeds, propmts that can trigger multiple actions by selecting a reaction emoji, you get the idea.
Just overall a great, low friction and _modern_ experience.
I remember we used tools that saved the snip to a specified directory, targeted it at Dropbox public folder, and then there was an app or maybe config option that pushed url of any new file in the public directory to clipboard. Was even better because you had the URL immediately, without waiting for upload.
> (although, that's not technically true since irccloud does all the things you just mentioned)
Yes but then you're not using IRC, you're using IRCCloud. Its features are independent from the backend that is used; they could switch to Matrix or XMPP or a proprietary protocol for that matter, and the features would still be there. You can't expect the one you talk to to have IRCCloud and tell them "just search in the conversation history, it's there" because the protocol doesn't allow it.
The GP's answer is correct, Slack does a lot of useful things by default. That's why people like installing Ubuntu or even Debian but don't want to take time to setup an Archlinux or a Gentoo anymore: it's fun, but if I just want to do something other than tuning my install I'm not going to consider those distributions.
Now, the question is, does that mean that LFS or any bare distribution "lost" to, say, Fedora ? No, because they are meant for different needs. I'd say it's the same for IRC: it's best suited for people who are not interested in the full history and want to talk to people in a synchronous manner, people for whom text is a more than good enough solution and aren't necessarily interested in binary exchanges, people who like pseudonymity, etc
The client -> relay protocol for weechat relay is not the same as the client -> ircccloud protocol for irccloud, and both of those are _not_ IRC
All those clutches exist to support the deficiencies of IRC, which only proves the initial point: IRC in its current form doesn't do enough, and that's why Slack, with all of those features out-of-the-box, "won".
If you replace IRC with SMTP the story is very different. IRC has a lot of protocol problems but the biggest one was honestly just not having an IMAP equivalent. IRCCloud is just providing the complementary protocol to IRC. Its existence doesn't necessarily mean that IRC is a bad transport protocol.
IRC has no message storage - so not only it has no IMAP, it has no POP3 either.
And IRC is a horrible transport protocol because it handles errors by dropping messages. SMTP has both message-ids and explicit confirmation response to make sure that as long as server comes up, eventually, the message will be delivered exactly once. IRC does not; so it is simply not appropriate for the cases where each message matters.
What I was eluding to was that irc (as a server to server protocol) is fine. As a client it has deficits but those are quite literally smoothed over by websocket capable bouncers and weechat relay.
IRC The protocol is not competing with slack. The IRC ecosystem is. And yes, it lost.
You might actually be right, server-to-server IRC is good for finding an efficient path between all the servers in the network (ie it considers the network as a whole, not just a series of 1-to-1 connections) and send the minimum information required, so we should be able to keep that and make the client-to-server protocol different.
In short, make the relay/bouncer part of the server itself, and tell clients to connect with the relay protocol, not the IRC protocol. If there were some common standard for this second part that would actually be a great thing.
But we're talking about reasons people ended up choosing slack over something like IRC (or, really, any open protocol instant messaging specification).
The grand-parent comment raises good points, people want these things, being connected and reachable while not being connected to the server with any client and having a context later on. These are problems that can be solved but nobody has put effort into making a sexy product to do it. (and monetising that kind of product might be troublesome)
Frankly, it reminds me a lot of XHTML vs HTML5. I buy all the arguments XHTML had, I like the vision it had for the internet. It also wasn't what actual end-users valued, and something that offered that won out because it provided more value, even if it didn't pursue the same vision.
The replies really should be "no, stop wanting that." IRC is not meant for such interactions, and is built around different social expectations. If you want 24/7 presence, then you ought to justify it socially, because there is a qualitative cultural difference between folks who regularly idle on IRC vs. folks who are only connected to IRC when they actively want to discuss something. Similarly, backlogs are only marginally useful and are usually a security risk, but the typical client does offer full-text search through IRC backlogs, when needed, and I'm not sure why that's a problem for users.
It's obvious why Slack wins for businesses: Because it gives businesses greater control and legibility over their employees' work habits and decision-making. DCC or any other P2P connection is anathema to this sort of control.
Users want different things. They want both plain text and rich text, and similarly, they want both plain chat and rich chat.
Oh, and aside from all of this, there is a working group [0] which publishes proposals for modernization of the IRC protocol. Adoption rates are low, but perhaps that should tell you something about what users actually want.
I like the ephemeral nature of IRC. It's supposed to be for real-time communication, the "chat" in irC, not for keeping bouncers. Bouncers defeat the point of IRC entirely.
I also use slack btw, and discord, and matrix too, so I fully understand the importance of a backlog, and having server caching for files is much more convenient than using an additional sharing site.
IRC is not perfect, but for what it does is pretty nice. Having a customizable backlog per-channel would solve most of the issues you have with reconnects and people's expectation. I'd love this backlog to be short by default though (<10m).
X/DCC is plainly annoying and it just breaks too often nowdays. Server assist, even for 1-on-1 sharing would be very useful. Sharing one image with a group of people while working on something is really, _really_ useful and having a common way of doing it that integrates with the chat is very helpful. Reasonable limits and auto-expiration (matching the backlog length or even shorter) would also be very useful.
We know what introducing file sharing does to a chat though. Instant memes pop up. I love how IRC channels look compared to all modern equivalents: just boring text, and minimal text formatting. If file sharing is added, I wished it would never be with inline formatting to keep it the same.
I don't care for search. Storing info in these chat mediums is a horrible, _HORRIBLE_ way to reference anything. Short backlogs are the only way to enforce people to store valuable content where it belongs. Searching through the backlog would then be no different than what irc clients already implement (simple look-back).
Keep in mind text-only chats are so compact that having a full day worth of backlog and downloading that from a cold-cache is still cheaper than getting a single inline animated gif. Just for reference.
I hate slack threads and how people tend to use them. I wished people would simply create ephemeral chats instead.
I find all matrix clients to be absolutely horrendous for exactly the same reasons. They become cesspools of memes and repository of information that are terrible to use. Honestly, the best way to use matrix seems to be gomux, or weechat via a matrix plugin, simply because these clients _ENFORCE_ a certain kind of usage that keeps the TEXT in the chat in the center. Sadly, both are incredibly limited. Cannot get ephemeral channels to work on weechat (which would be the "modern" equivalent of a query with multiple parties). Channel discovery is horrible.
But the backlog does help a lot for reconnections. So does the built-in file sharing.
It seems that the userbase of matrix has a different concept of what a chat should be, and that's why I still prefer IRC for now.
I like how your comment, which I totally agree with, is right below this one when I read it.
> Frankly, it reminds me a lot of XHTML vs HTML5. I buy all the arguments XHTML had, I like the vision it had for the internet. It also wasn't what actual end-users valued, and something that offered that won out because it provided more value, even if it didn't pursue the same vision.
Realistically, people don't tend to care about how much ram they're using, that's why PWA's are able to take the jobs of native applications, and people are even happy about it.
This article is comparing apples to oranges. IRC is a protocol, Slack is a client/app that uses protocols (one of which used to be IRC). Many IRC clients, although beloved by some users, are rough around the edges.
In my opinion, Slack has "won" over other clients because of UX: it's extremely easy to sign-up, understand, and use productively. Plus, even large orgs (ours included), can use the free version if they're OK with having chat history disappear after a few days/weeks.
Slack made the process easy, and with emojis and slash commands, fun and useful.
I think another benefit to slack is you can come back to it and see the history. IRC is ephemeral unless you stick to a single device and leave it running. That's impossible for a mobile phone.
It frustrates me that some large projects (ex Ansible) who insist on all discussions there, and explicitly ignore things like GitHub issues.
I am in no way saying that this isn't a barrier to entry (and if we're honest I think that barrier is an intentional choice) but you're supposed run a bouncer/logger and just connect your client to that.
It's always weird to me that IRC didn't evolve like email with something like IMAP.
I still kind of struggle to understand why Slack is so popular within the corporate world. It is a good choice when you have some public initiative and let people swarm in, yes. But when it comes to private entities(I'm talking about large corporations), I really don't get it. I've been using MatterMost for years and while it had a rough start, at this point I'd take it over Slack any day of the week. Functionality is pretty much the same, integrations are much more simplified(I use them a lot to say the least and from my point of view, all the API's work as a charm) and at the end of the day, you are the owner of your data. So it is a genuine question: What gives?
In a lot of corporate environments, "self-hosted" is not an advantage if you're the one trying to set up something new. In order to self-host, you have to go through your corporate IT department to provision servers. This alone can take 6 or 12 months, and you still have to find someone to maintain the service.
And the kind of companies that value self-hosting will usually want this to be set up inside the company's internal network. So you'll have a bunch of firewall issues to get through, otherwise good luck getting your users to connect to some non-publicly-accessible server from their phones.
Other comments talk about how Slack nailed the UX for users to join a Slack workspace. But they also nailed the UX for getting a workspace set up in the first place.
(Well ok the whole idea of separate accounts per workspace thing is a bit of a mess, but they nailed everything else)
It took _forever_ to get a self-hosted Jabber-based chat client going at a mid-sized corporation, about 10 years ago. Someone went “rogue” and set a server up anyway. Our security staff began blocking ports, so it eventually died anyway... in favor of Skype and Yammer. All because no one wanted to host chat history and a server.
Nope, so far I haven't come across a single Atlassian product I can even mildly tolerate so I'm not putting faith in their products unless I have to. Lync - I'm a full time linux user so that's a tough one to say the least.
Because at some point all corporate firewalls were configured to block all incoming traffic except port 80. Then everything died out: News, Irc, and now finally FTP.
Slack won over IRC for me by prohibiting anonymous users. Simply verifying their emails or having it be invite-approvals only was enough to improve my experience dramatically versus IRC’s endless anonymous harassment.
It looks to me like anonymous harassers on IRC would not really be blocked by email validation... As such, it's probably just a matter of time before public Slack rooms become their target.
The definition of 'public' is not equivalent for IRC and for Slack.
IRC anope-style email verification simply requires that you are able to initiate a TCP connection to the IRC server. If you can do so, you can have a verified account. This kind of "public" is vulnerable to harassment as you describe.
Slack additionally requires an invitation by a workspace owner for all new users who wish to join, excepting only domains where the owner permits users to join without invitation using a special invite link. Anyone who invites harassers will find themselves under Slack's microscope as well. Owners who enable automatic invite approvals for e.g. @gmail.com or @throwaway.com that result in harassment can expect to find themselves banned by Slack and their Slack shutdown. While in theory this kind of "public" could be abused to some degree, it does not permit the 'anonymous' abuse that IRC's kind of "public" does.
If an IRC network was set up to require that existing users put their reputation on the line for new users, and in cases of harassment both the new and existing user were banned, then that would be a far more tenable system than what we have today. There's nothing that requires this to be unique to Slack. It just happens that Slack is willing to turn users away if they don't like it, and so as a result their network is baseline safer than virtually all IRC networks — such as Freenode.
FreeNode doesn’t, not do many others. The unstated assumption here is that it’s easy to decentralize IRC because “run your own server”, but it’s not easy to run your own IRC server, nor to time-efficiently share how to configure IRC clients on how to connect to it using SASL.
This is actually a huge + for any extensible chat client. We send alerts from various monitoring solutions and use emoji to quickly identify the environment and app. Makes it very easy to understand exactly what is going on.
I concur, a hosted thelounge client instance brought me back to IRC after a decade of absence, giving me Log history and recoverable state. If the expectation is to go on public record (vs. private p2p chat) only user experience decides for group chat, not the underlying technology. Though IRC can't replicate threads, that is the only nitpick. In high volume channels replies to old questions are fine and the dynamic caused by seemingly disjoint replies can be learned.
Regardless of that, Slack is a complete and easy to understand solution. IRC is a collection of unknowns where each user ends up with a different implementation and may not be satisfied with where they end up.
That said, I've succeeded in gradually getting some of my friends onto Riot/Matrix. To be clear, I did it without much technical/ideological evangelizing or being obtuse, just on the basis of them wanting to talk to me and in our social group. But Riot is also at least nice-looking, multiplatform, has modern features etc. Things that are still annoying:
1. Dealing with Riot/Matrix system/client confusion. Most people don't care about such distinctions, I should probably just focus on talking about Riot. (I understand that developers may choose to do different in their communication)
2. Entering into 1/1 conversations. I still don't know/remember how to reliably do it with a new person, always did it by trial and error by trying to invite in ways X and Y etc. It probably requires finding the opt-in into email invitations in the configuration by each participant. I understand these are some anti-stalking measures, but God is it annoying.