I've been mad at the Go community in particular for continuing to promote Slack for ages, and this is exactly the hypothetical situation I always use to explain why (although there are other reasons too; Slack is a perfect embodiment of everything wrong with this industry, but that needs a fuller writeup). At a previous job we had to start doing this exact same thing when we were considering going public; this is the point at which I started considering leaving.
Using a proprietary protocol that doesn't allow any form of federation is an unacceptable way to build a global community. Please consider using an IRC based service for group chat or an XMPP based service where 1:1, history, rapid reconnects, and other more complex chat features are required (yes, if you're a dev you have to use XML which is annoying, but overall it's a well designed protocol, so get over it). This lets you host your own, and (in the case of XMPP at least) if one person wants to use a U.S. based service and another is in Iran they can just sign up for a Belgian account (or wherever). We can't afford to let he internet splinter off into siloed tiers based on nationality.
I would love to see more things built on open protocols. But for that to be the case, we have to find ways to make better apps built on top of open protocols.
We should start by admitting that Slack beat IRC. Beat it like a cheap hallway rug. IRC was always a terrible experience for novices, and it wasn't a great experience for experts. That it had any users at all is a testament not to IRC, but to what it enabled. Slack found a way to provide the same value but with a much better user experience. And then they rapidly iterated on that experience, making it better and better.
They started out with IRC and XMPP bridges. But they eventually shut those down because they were a drag on improving the product. When faced with the same choice, IRC kept the original protocol and shut down improving the product. This was an understandable choice, but one that set up the situation where commercial developers could come in and do something radically better. Open source needs to figure out how to compete with that, or things like this will keep happening.
I think as ethical, intelligent and conscious individuals, we folks in the developer and hacker community want people to make decisions on the basis of principles, when the reality is that people generally make decisions on the basis of convenience. In fact, people are often willing to sacrifice their principles (to a certain extent) in the name of convenience.
If we want people to use principled technology, then we need to be able to honestly advertise products as "it's just as good as X, and also doesn't violate [your privacy|human rights|the environment|etc.]" If we have to say, "It's not quite as good, but..." then we're dead in the water. (Side note: I switched to Firefox out of principle and I'm hopeful it will hold the line on market share, since it really is just as good as Chrome.)
The issue is that we're dealing with corporations who aren't just rich and powerful, they are also innovative, agile, and laser-focused on providing consumer value. Slack is doing an amazing job at serving their users!
You wrote, "we have to find ways to make better apps built on top of open protocols." It's a really interesting dilemma and I suspect it's one that isn't solved by better technology, better design, etc., but rather by addressing the base economics of the situation. We need a scenario where principled, open-source, ethical technology is generating the kind of investment we're seeing in Silicon Valley unicorns so they can innovate the same way.
If we want people to use principled technology, it has to be usable, full stop. As a developer, being able to say "I'm willing to sacrifice convenience, in the name of principle", is a privileged position - you know how to navigate software when it gets difficult - other people don't.
What I find a lot of people miss when comparing Slack to IRC, is that not everyone using Slack is a developer. The world doesn't consist solely of developers - and if your company is 30% of engineers, and the other 70% doesn't have the reserve to wrestle with XML, then your company is using Slack. Otherwise, you are simply choosing to sell out your friends and family in the name of "principle" as well.
Personally, I'm tired of the comparisons to IRC and XMPP. Both are garbage - time and time again its been show how difficult it is to create greate software on these protocols. Contrary to your final statement, there have been better open source applications - gitter and riot come to mind.
> What I find a lot of people miss when comparing Slack to IRC, is that not everyone using Slack is a developer.
I know plenty of non-technical people who chatted on IRC who were not developers. They just used the mIRC client on windows to do that. They also managed to configure their email and news clients to send and read email and browse usenet.
I simply don't understand where the idea of needing a technical background came from for using something like IRC.
> I know plenty of non-technical people who chatted on IRC who were not developers
> I simply don't understand where the idea of needing a technical background came from for using something like IRC.
You don't have to be a developer but you do need a level of technical background higher than that of the average computer user. There are plenty of tech-savvy, non-developers who can get up and running with things like IRC. There are plenty more non-technical users who can't. Or at least wouldn't given the learning curve time commitment.
I'm the only person in my family who would be able to sign on to IRC in under an hour whereas they'd all be able to have slack up and running in a matter of minutes.
No. I expect a certain competence when using a computer. If this level of competence is not enough to even install a piece of software and configure the most basic settings, then this person should not own a PC, yet use one.
It's amazing that when it comes to computers, it is somehow acceptable to be dumb. It's acceptable to not learn new stuff. It's acceptable to not read in order to understand stuff. As can be read in the comments here.
Do you want to be ‘right’, or actually have users?
The whole ethos of startups and Silicon Valley has been around finding a market for your product. If people don’t want to use it then you can’t blame anyone but yourself.
Feel free to chat with yourself using an ideologically pure system... it’ll be lonely though.
> Because it's the FLOSS devs who need to learn to empathize with the ordinary user.
If you were talking about using these protocols over a telnet session, then I would be more inclined to agree with that statement, but just installing an application, entering a server name and account credentials (the latter of which aren't needed for IRC), and connecting isn't any more difficult than creating an account on slack and connecting by entering the address in the browser.
Of course, but I don't think that Slack has done a better job with this compared to previous solutions. In a lot of ways, it's worse given its performance issues. For example, I never experienced UI lag in a chat application until I used Slack (comparing it with UIs like a GUI IRC application, AIM, ICQ, MSN messenger, Yahoo messenger, Skype, etc). Second, auto-completion and search do not work like they do in previous chat applications (or other applications in general) due to infinite scroll and the default of doing a global search instead of just limiting it to the chat or group. Third, the fact that you're forced to join some channels because you were invited or can't leave a channel because you're the last one in it are other issues that come to mind.
I think this is to enable history and mobile, for example?
Granted, I have not used IRC for a while, but last time I checked, the story for getting message history was "start a irc client inside a screen session on a server you own". And there were no mobile at all.
(I remember writing a script which exported chat logs from my desktop client to text files available over HTTP... I'd then visit those pages from cell phone to see if I had any more messages. This is not the experience I would wish on anybody)
For history, it's either local logging or having an always on client you can connect to (like a bouncer), but most people I knew would just switch their client on, chat for a while, and then close it. They didn't really care much about history.
It was pretty much the same thing with newer chat services like ICQ, AIM, MSN messenger, etc. (though I think they started offering offline messages in later versions).
As for mobile, my older Nokia phone had a Symbian IRC/XMPP client that I could use without any issues.
> being able to say "I'm willing to sacrifice convenience, in the name of principle", is a privileged position - you know how to navigate software when it gets difficult - other people don't.
In the same breath though, saying, "I'm not willing to sacrifice convenience in the name of principle" is also a privileged position, because Iranians who live in the US/Canada are currently being banned. Convenience is something we can address in the future, but bans aren't.
The concerns people raise about Slack -- that until very recently it wasn't blind-friendly, that it takes away control of user data, that it can arbitrarily ban companies and users for any reason; none of those are theoretical deontological postering. They are entirely practical in the sense of, "there are people who are affected by this who can't join your community because you're not using a tool that's accessible to them."
I think that it's easier and preferable to teach my friends and family members to use open tools than it is to use something that blocks people of Iranian descent from participating in my community. Yes, that means my communities will be less accessible to tech-unsavy people. But that's a problem I can try to address in the future. I'm OK making their life harder for right now if it means not permanently banning people based on a random company's whims.
That is selling people out, in the sense that it's making a calculated decision about which people are most important to support right now. But if the Go community is using Slack, they're making the same exact same decisions to prioritize accessibility for some people. They're just choosing different people.
Violating principles and respect for others is a vector for profit, which is why it always feels like a losing race. Its people in their spare time fighting against substantial revenue streams accrued from the violation of the freedoms and principles we want to uphold.
To have competitive apps built on top of open protocols, you need a big investment of time and money, so we need users to ask for it, or at least to reward companies when they invest money in it. For that, we need users to understand what they're asking for.
An example of how it might be possible to push this in the right direction is LEED. It didn't matter what the individual environmental ethics of people manufacturing electronics and designing houses was. Environmentally efficient building practices cost more, and there was no way for all the companies involved to form an opaque conspiratorial cabal to secretly impose the cost on consumers who would rather not pay it. Instead, they created LEED and used marketing to teach end consumers that LEED stood for more environmentally responsible practices.
Right now computer privacy and security are huge in the headlines, and a large number of people in the public and in industry want to do the right thing. But consumers don't know how to make the right choices, and companies aren't going to spend extra on the right thing if users are just as likely to choose something horrible. What companies need in order to invest extra capital in privacy and security is a plausible story of how to get users to choose the right thing and pay a bit more for it, if the industry builds it. They need a LEED standard for privacy and security. Then they can promote it and use it as a way to justify their investment in better, more ethical software. Corporations, schools, nonprofits, and other organizations can be pressured to make public commitments to use, or at least prefer, software that meets the standard. This won't drive horrible software out of the market, but it will create a sub-market where good software can survive.
Obviously laws and regulation are the bedrock, but in areas where consumers have a choice, we need to make it easy for them to make the right choice if they want to.
Matrix.org is really doing a good job of being a Slack replacement (it even has Slack and IRC bridges). It's also federated and has a bunch of other nice features (like e2e which is based on Signal's crypto with some improvements for group chats). I would suggest taking a look (and I would suggest that people start switching to it).
Honestly, at this point, I can't really tell the difference between Slack and most "Slack clones" -- the interface of Slack has basically been copied by most people and to be honest it really wasn't that hard. Mattermost and Rocket.chat both look exactly like Slack to me.
Matrix.org's problem was that they reinvented the wheel (again) WRT the protocol. Now you have a protocol that if the main company goes under, probably can't be developed further and doesn't already have wide adoption and lots of clients written for it (as is the case of IRC/XMPP). HipChat had a better model here where they used XMPP (admittedly, in the worst way possible and completely misunderstood and broke the protocol in lots of places) but build their own service on top of it. You could still use third party clients, the experience just wouldn't be quite as good. If they had enabled federation it would have solved the Slack problem to a certain degree.
Matrix could have done the same thing, but they chose to waste time and money reinventing the wheel (and doing a bad job of it) instead of focusing on the service and the clients.
I could count the number of good, modern, high featured XMPP and IRC clients on one hand. At least compared to their proprietary counterparts. Matrix has at least as many either mature (Fractal, Riot) or up and coming clients as I'd consider usable with anything else, and it has bridges into all that legacy, something I have never seen IRC or XMPP manage well.
If you have legitimate grievances with the protocol and feel you can see flaws in it, make an issue on the tracker now while its still a 0.x release, doesn't have the broad adoption you describe, and while the team (knowingly) can make breaking changes simultaneously released to matrix.org and riot.im and cover 95% of the users still.
Riot is the only client Matrix.org calls stable.[1] I would not call the desktop version good. The only third-party clients that are close to complete are Nheko (which has been abandoned) and FluffyChat (which is for Ubuntu Touch).[2][3]
There are no stable servers.[1] The reference server is being completely rewritten.
Matrix bridges work about as well as XMPP bridges in my experience.
The phone experience for riot is really, really bad (extremely high battery usage, even when the app is not in use. I'm aware of the technical reasoning behind it and I frankly don't care as a consumer). This was (and is) the one barrier stopping me from using it and converting my friends to matrix (they're not platform loyal at all).
Can you give precise examples of the problems? As someone who tried to use XMPP in the past, I found it to be far worse than IRC in terms of connectivity and how things worked. Matrix.org couldn't really have used IRC as a protocol because IRC isn't a very extensible protocol. I've been using Matrix.org for several years now, and it's much better than my experiences with IRC and XMPP (though IRC is still quite usable, and I do still use it regularly).
> Matrix can be thought of as an eventually consistent global JSON db with an HTTP API and pubsub semantics - whilst XMPP can be thought of as a message passing protocol.
Finally someone gets it! A chat service should value each message and it should never lose messages due to connectivity problems.
Thank you for sharing that link, I learned something new today.
How is this a good idea for a chat protocol though? And what makes you think XMPP doesn't do that (it's quite trivial to setup your server in such a way that messages won't be lost even if there is a network partition, client connectivity issue, etc.)
- Person-to-person chat system. This requires offline messages: "when you get to work, please take a look at ABC-1234". Some people have cell phone as well, so this needs multi-delivery to all the clients (so you can read the message on the phone, then read it again from work PC)
- Support system: one person posts "I cannot run TOOL_Z", people who know reply. This requires offline history -- if I maintain TOOL_Z and I come in late, I was to see the question asked, answers, and maybe I want to contribute an answer as well. By the way, slack threads are super helpful for this.
- Knowledge archive: next person to have TOOL_Z problem would search the channel history, and find previous answers.
- Announcement with discussion: someone posts "New version of TOOL_Z is released! New features: ...". People might respond by discussing the new features.
All of those basically require "global database" -- those messages are not volatile things; it is not OK if the announcement is lost, or if you did not see the help request because there was something wrong with the system.
And I know that XMPP does not work for that because back when my workplace used to use XMPP (a few years ago), I went to https://xmpp.org/software/clients.html , installed "gaijim", and found out it has no offline message history, no message searching, and half-broken multi-delivery.
So we ended up building scaffolding - set up our own search engine, archive system, use different methods for communication. This was a lot of pain and very little gain. So when we had to re-do infrastructure from scratch, we went with Slack.
(Note that you can't just say: "I don't need those features". As long as there is a single person in the company who does not have history, the whole company cannot use pure XMPP for support system or knowledge archive anymore -- or that person would be excluded.)
As you said in other messages, things are better now -- there are compliance suites. So "XMPP Advanced Client 2018" does do what you want. Unfortunately, I cannot find a list of clients which support "XMPP Advanced Client 2018".
Also, there are people who confuse matters by saying that "XMPP does everything Slack can, and has tons of clients". No. "XMPP Advanced Client 2018" does everything Slack can but has very few clients. Regular XMPP has tons of clients but does not support everything that Slack can. It is very important to distinguish between the two.
Yeah, I’m normally not a fan of creating a new protocol and further contributing to fragmentation of open source effort, but in this case matrix.org fills a technical need that old protocols like irc and xmpp simply weren’t up to the task for.
I've read that FAQ entry, but it's bogus in terms of chat. Maybe the protocol is more useful for some other thing, I don't know (although I doubt it since XMPP at least can also do very similar sorts of things with pubsub if you need them for some use case, eg. the IoT people do this sort of thing a lot).
The FAQ skirts around the fact that it doesn't matter if they're slightly different: you shouldn't make up your own new thing to force adoption of your commercial product. Use and improve the existing technologies that are "good enough" and stop splitting effort and making yet another standard that everyone has to try and support or run bridges for. This is unacceptably bad engineering. Saying "this is subjective" is true, but just an excuse for "we have not-invented-here syndrome".
XMPP on mobile was always a disaster for data use and battery life - back when gtalk was still XMPP the mobile clients used a proprietary protocol to talk to a google server that unwrapped it into XMPP.
Pure-XMPP simply would not have worked.
(I have my issues with the matrix protocol, mind, but they had good reasons to create a protocol even so)
Edit: I also wouldn't be surprised if this is why facebook messenger switched from XMPP to a custom MQTT-based system.
This is a myth (or one of those things that may have been true at one point but is now repeated as lore even though it was solved 15+ years ago); XMPP is actually pretty good on mobile. Between the persistent TLS connection which can let the radio go to sleep when no data is being sent (without the tail time of creating a new TCP connection constantly) and TLS style stream management it's very battery efficient when you're using a server that's optimized for mobile.
The last time I looked into this (maybe 6 months ago), this could only be achieved using non-standard/experimental server extensions with absolutely no guarantee of stability. This then led me to believe that it was one of those things that was theoretically possible, but not practically possible. Has that changed in the meantime?
Well, experimental doesn't mean it isn't usable (we are talking about an experimental standard here, not about experimental software).
I run an ejabberd server and for example the Client State Indicator (XEP-0352), which is one of the extensions that improve battery life for mobile clients, was experimental for a long time but at the same time also available for major servers (e.g. community edition of ejabberd) and mobile clients like Conversations (open source too).
So in my experience, the battery consumption of a modern XMPP client is quite good. When people are complaining about the bad mobile experience they are mostly referring to the time before the mobile extensions were built.
It was rather less than 15 years ago I had the conversations with gtalk architects (who liked XMPP and left when google abandoned interoperability) that led to my opinion.
So apparently not everybody shares your definition of
'solved' - I appreciate the alternative opinion, but simply declaring it a myth is, I suspect, unlikely to convince remaining skeptics.
I wouldn't subscribe to the "15 years ago" statement, but we have figured out mobile battery use pretty well, and the respective solutions are avialable in both server and client implementations. Have a look at [0] and [1] for (slightly biased but more detailed) elabortations.
simply declaring it a myth is, I suspect, unlikely to convince remaining skeptics
It's hard to provide specific counter-arguments to anecdotal evidence repeated since back when gtalk was a thing.
The Google Talk people literally never tried to implement any of it as far as anyone could see publicly (eg. stream management, compression, client state indication, etc.). I'm not sure if it was a problem with discoverability, or if they just didn't want to, but their feedback was always that things they needed didn't exist, and then stony silence when someone would point out the thing they needed.
If FLOSS developers started building their software products like businesses built their products, then they would have to turn into businesses. You see this in pretty much every segment, I'm looking at you, Canonical.
More to the point, there is always going to be some value-added service a profit-seeking enterprise is going to be able to provide over what's freely available. If we built IRC 2.0, then Slack 3.0 will provide what everyone hates about IRC 2.0 and then the dynamics of profit seeking will drive Slack 3.0 to divorce from the free alternative.
We see this pattern over and over and over again. It doesn't happen necessarily because businesses are being ruthless, but because there's always going to be a market space, even in the face of a fantastic free service. That's just how a market economy works.
Right. I'm not saying open-source developers have to start building in the same way as for profit companies. I'm saying they have to build products that are, from the user perspective, as good as the for-profit ones.
A good example here is Firefox. When it started out, it was better than the competition. Chrome pulled ahead for a while, but Mozilla responded and now it's competitive again. And Firefox has done this while advocating energetically for an open web.
Another one that interests me is WhatsApp. They built a messaging product that was clearly superior to the alternatives. They eventually sold out for billions. But there's no reason they couldn't have done that as a nonprofit. And Signal has shown that a nonprofit can still jump into the space and do good things.
Word. I don't love Slack, but IRC is awful, and an open protocol replacement for Slack would have to make easier many of the features that Slack has and IRC lacks.
What features does IRC lack? The messaging, chat rooms or PMs, private servers, file sharing, etc has existed forever. You can also build any sort of tool for integration with it.
I guess it lacks persistence and access to history? But there are surely ways to solve that.
persistence, history, search, rich formatting, image previews, synchronization between devices, usable mobile clients, group/here/channel mentions, channel directory/search, channel descriptions, file upload/sharing (XDCC is not this), multi-line/expandable messages (eg, paste code or logs without flooding the channel), user status (away/DND).
Some of this can be approximated with bots, of course, but there's a lot of extra work then required to make that work (namely, setting up, writing and maintaining the bot). Some of this can be done client-side, but then you have inconsistent experience.. you don't know if the other user is going to get the image preview or if their client understands markdown or some other formatting, or is going to interpret and display your message using some other markup format. Some of this you can also work around with one of those persistent IRC connection proxies, provided each user gets one and that is also maintained by somebody.
Eventually someone packages this stuff all together for simple deployment.. and basically creates a bad clone of Slack, but with 10x maintenance requirement and so many more things that can break.
As long as you’re willing to run a bouncer (and an organisation could run one for all their users), there are usable mobile clients with synchronization between devices, persistence, user status and even profile images.
For example my app https://quasseldroid.info/ which requires you to run the https://quassel-irc.org/ bouncer, but provides all that. As well as IRCCloud and Weechat-Android, which are also very awesome and provide a similar amount of functionality.
This is kind of my point though, especially for a company: this is kind of a pain to setup for technical users that want to get the functionality. It's basically a complete barrier for the types of users who still primarily use e-mail, phone calls and in-person meetings.
I agree — the current usability is still very suboptimal, and we need to work on it a lot. But compared to where we’ve been a few years ago, it’s already gotten better.
I wish I could do more, but in the end, I’m just a single developer improving the usability of a single app in my free time.
For open source non-centralized solutions to compete with the proprietary options, you need lots of devs and even more funding. Matrix/Riot.im has that, and even they aren’t close to where Slack is. Most of us IRC devs are either getting nothing, or, as e.g. in my case, the donations don’t even cover the server costs.
In the end, if people want open solutions to grow, they need to put their money where their mouth is.
irccloud is great and solves many of these issues. I'm not suggesting it's an alternative to Slack because of course then you're paying them $5/user/mo instead of paying Slack $6.67/user/mo and you're right back where you started, but if you're an IRC user looking for history/synchronization across devices, image previews, a mobile client, and drag-and-drop image sharing, irccloud is IMO totally worth it.
It's been a while since I've used IRC daily, but I think I remember the basics...
Doesn't IRC file sharing involve directly connecting to individual users to transfer the file, instead of those users choosing to download it at their leisure? And if you happened to be offline at the moment the user shared the file, can't you never download it unless you ask them to resend? For large, asynchronous groups, that is untenable. Slack's file sharing works because Slack hosts the file.
Also, basic messaging features are indeed missing from IRC. How do you do a private group chat? Like an SMS group thread? Doesn't it only support channels and then individual 1:1 DMs? Slack has ad-hoc group DMs. On IRC you'd have to make a new channel every time. It's like getting a conference room every time you want to talk to more than one person at once.
Slack also does voice and video calls, and screen sharing, and it's really quite good at it (feels light, not bloated). Sometimes talking with someone needs to turn into a face-to-face call.
Checkout IRCCloud.com ... it's an online service for connecting to IRC and can also connect to Slack too.
The obvious advantages versus classic IRC clients: it's always online and the connection happening through their servers you get good push notifications on mobile.
The obvious advantage versus Slack: they don't own the IRC networks you're connecting to, so if you have issues with IRCCloud you can just change to another client.
It has some missing features, most notably search in archives, but they are working on it.
>> "admitting that Slack beat IRC"
Sure but are we talking about a fundamental limitation of the IRC protocol, or are we simply talking about implementation details that can be fixed?
Not necessarily disagreeing but could someone provide some solid examples of IRC being a terrible user experience? Whenever IRC comes up, people say it lost and it’s not the right technology. When pressed, they wave their hands around saying “...because, uh, user experience reasons!” As a longtime user of IRC, I’m probably blind to these issues. What’s so bad about it that causes people to put up with these inadequate “cloud” re-implementations?
Too hard? I installed mIRC on my own at age ~12 in the late 90s and I don't remember having any issues, the only thing you had to do was to type a nickname and choose a server. Nowadays it's even more simpler since you don't even need to install a client (qwebirc, kiwiirc, etc.).
Sure. 12-year-olds who go on to be software developers can install it. That says nothing about the user experience of the bottom quartile of users in terms of technical aptitude.
I'd agree that it's possible there are some discoverability issues, but i don't see where '/server irc.(efnet|freenode|etc.)' is bordering on impossible.
Threads have been super useful for us, we have a few channels that are forums by social agreement where long running discussions are recorded to make it easy to reference. We found this style to be easier to review then breaking off separate channels per topic and we generally use it for initial feature exploration. Once something moves into the category of "We're doing this" we split off a channel and isolate the discussion.
You need a bouncer if you need access to history, that is a deal breaker for most people. Also, being able to ping somebody via a push message on their mobile is also a nice thing when working in a remote team. Apps on mobile are also not that nice.
That being said, I wish there was a better open source alternative.
The only problem with IRC is that iOS doesn't allow background processes. Otherwise it could be extended to support anything Slack or whatever does. If not in an open way, in an interoperable way.
In which world does it beat IRC? Number of users? That's not even sure, since there are dozens of thousands of IRC servers worldwide. And that's not even counting the private, self-hosted IRC servers.
IRC runs everywhere and does not need a fat browser or a RAM-and-CPU hungry application to enable "chat".
As for the user experience, this would merit a whole post in itself, but Slack sucks in many ways: threads are completely unusable, channels are hard to discover unless you know about them, and now Slack makes you pay for searching thru your past messages.
I'd say there is a lot more to this topic than "Slack beat IRC".
So my best guess is that Slack has at least an order of magnitude more users.
But users is not exactly the metric I'm thinking of. It's when people say, "We need some way for us to communicate," Slack is the popular option. Even though I'd rather not use it, I'm in 8 right now. If you look through this thread, you'll find plenty of people concerned about how prominent it is in the open-source world, IRC's home ground.
> IRC runs everywhere and does not need a fat browser or a RAM-and-CPU hungry application to enable "chat".
I get this in theory. But RAM and CPU power are fantastically cheap. Conserving them to get a worse user experience is optimizing for the wrong thing.
> but Slack sucks in many ways
Sure. There are no perfect things. But Slack doesn't have to be perfect. It just had to be better than the competition. And for most people it manifestly is.
How about user count? Isn't that the only metric that really matters for the question of who won? Slack beat IRC for work-related chat. It hasn't beat email for general written communication.
Yes, this attitude is a clear part of why Slack crushed IRC. "It was easy for me, therefore anybody who finds it hard is dumb and we can ignore them."
I too figured out all sorts of computer things at 12. By standardized tests, I'm also in the top 1% of ability for things like that. And my dad was a programmer then, so I had a leg up.
At some point, I realized I had a choice. I could feel smug about my (narrow) genius and focus on tools for my (narrow) cohort. While grumping, of course, about how stupid everybody else was. Or I could recognize my luck and use it to make things that were good for everybody.
You know what helped me make this choice? Realizing how bad I was at so many other things. And how generous other people were in not only putting up with that, but helping me along.
In my middle school (late 90's, the age of ICQ) all the self-described "non-technical" girls spent their breaks on mIRC in the computer lab gossiping or whatever teenage girls do. If we're talking about a developer audience (the readers of Hacker News) it really isn't difficult at all.
It was definitely IRC. As boys who had a prerogative to tease girls, we installed NetNanny to block launching mIRC (and then the trial period expired and the school computers got infested with registration reminders...). AIM had zero mindshare in Europe at the time, it was all ICQ and later MSN.
Our school had nothing blocked, and the computers weren't locked down at all.
Yep. It's not hard. People are pretty clever and will work things out if they need to. It's just that we hand feed them shit like slack and tell each other that they're surely too dumb to use anything else.
An effort is underway to standardize E2E encrypted group messaging in the IETF with the MLS [1] protocol. Open-source participants include Wire and Matrix. Commercial participants include Facebook, Cisco, Google and Apple.
How is Wire developed and funded? This was my biggest problem with Matrix (unsustainable funding model for the protocol and no proper standards body).
Why not just use XMPP? Yes, everyone hates XML, but the protocol is well designed, has sustainable funding (via the IETF and XSF), and there's lots of experience out there, and it's flexible enough to develop services like Slack on top of.
"XMPP is an example of a federated protocol that advertises itself as a “living standard.” Despite its capacity for protocol “extensions,” however, it’s undeniable that XMPP still largely resembles a synchronous protocol with limited support for rich media, which can’t realistically be deployed on mobile devices. If XMPP is so extensible, why haven’t those extensions quickly brought it up to speed with the modern world?
Like any federated protocol, extensions don’t mean much unless everyone applies them, and that’s an almost impossible task in a truly federated landscape. What we have instead is a complicated morass of XEPs that aren’t consistently applied anywhere. The implications of that are severe, because someone’s choice to use an XMPP client or server that doesn’t support video or some other arbitrary feature doesn’t only affect them, it affects everyone who tries to communicate with them. It creates a climate of uncertainty, never knowing whether things will work or not. In the consumer space, fractured client support is often worse than no client support at all, because consistency is incredibly important for creating a compelling user experience."
I don't think Moxie's right though; you can still do your own thing, and have it work best with your clients which support all the features, and then allow it to federate or optionally allow third party clients on your server with limited functionality. Naturally, you can also contribute back new extensions that you develop too so that other clients and services can adopt them if you want.
But I do tend to agree in general that we need fewer features and less complexity and to push more for basic profiles that everything should implement and that have a clear compliance label.
He wrote that after most messaging had already moved to proprietary networks. That happened primarily because Facebook and Google wanted to lock in users. The most popular desktop clients were multi-protocol clients that were slowly neglected. The most popular mobile clients were hobby projects.
Now we have uncertainty around which networks people use, which devices they use them on, and which features each network supports.
Because XMPP itself is not enough. If you want to deploy XMPP-based chat service in your org, and you want everyone to have same features (offline, mobile, images), you will have a hard time.
You cannot just tell people "go choose any XMPP client, and it will work fine". Instead, it is more like "get XMPP client, but make sure it supports XEP-1111, XEP-2222 and XEP-3333". And if you have multiple platforms (Android, iOS, Win, Linux), let's hope you can find a client for each.
I agree to a certain extent, but I don't think you need to support everything, just the subset of features that a particular user cares about. We should have some form of baseline that's more than the basic protocol, and the Compliance Suites will hopefully help there, but in general as long as basic chat works it should be fine. The first party clients can support everything and give you the best experience, the third party ones are juts in case you can't run the first party clients or need eg. better accessibility support or similar.
For example, I used to use Mcabber with HipChat at work. Mcabber doesn't support even basic modern XMPP things (history, for example), but it was plenty good enough for me to chat with my coworkers.
Its not user thing, it's a community thing. For example, if I have users who cannot see images, it means I cannot post screenshots and expect to get meaningful advice on it.
For your work: Are you connecting Mcabber to HipChat server? Do you use native HipChat client as well?
That seems like enough of a reason not to pick it as a good shared base protocol, even if technically it's good. It's nice that they're funding MLS though; looking forward to the results of that effort.
> It is not a goal of this group to enable interoperability/federation between messaging applications beyond the key establishment, authentication, and confidentiality services. Full interoperability would require alignment at many different layers beyond security, e.g., standard message transport and application semantics. The focus of this work is to develop a messaging security layer that different applications can adapt to their own needs.
I'm curious, have you followed those discussions, and have you noticed say Google or Facebook do anything to "nudge" the protocol towards being "more convenient to use" (read: less secure) and less privacy friendly than it was originally intended to be?
This is a software space that could really use more devs. IRC is fine but many people can't use it because it's too technical. We need more user friendly XMPP clients with features that non-technical people want. I hate Skype but damn if the non-techies I work with don't love it.
I tried to download and run Jitsi a couple months ago for a project and it's voice quality was terrible. Skype just works. I sometimes have weird quirky bugs with Adium, and it's getting harder to justify telling my team to use it.
WRT XMPP clients: Dino.im is getting there (although it's still too early and buggy to say it's there yet, I think). I'm still not aware of any decent web clients though, unfortunately. The ones that do exist tend to be developed by individuals and full of security issues, even if they are nice looking and easy to use.
I tend to think that we don't need more small community projects, we need one or two entire services like Slack to build themselves on the base protocols and federate. Even if they only allowed their own clients so that they controlled the entire experience, if they just federated with other servers it would give users a choice and largely solve the Slack problem.
I've heard Matrix might be a good IRC replacement. But it also still looks rough to me. I only tried it once, but didn't continue as I didn't need it for anything.
Matrix the protocol is pretty awful, and I'm not a huge fan of the "official" clients, but YMMV. The real problem with it though is that unlike IRC and XMPP the protocol itself isn't developed in a sustainable way by a standards foundation with a reasonable funding model. The protocol itself doesn't really matter that much though as long as we pick one that will be maintained and won't just go bankrupt (so IRC or XMPP depending on what you want to build) and then build nice services that support it. Remember, Slack is a service and a protocol, XMPP/IRC are just protocols. You still need good services like conversations.im or Freenode built on top of them for it to be usable. Unfortunately, we don't have many good services like Slack that have commercial backing but use an open protocol.
In all fairness to Matrix, this tends to be XMPP and IRCs biggest fault too. Although I tend to think the protocol needs to be developed by an independent standards body that really only focuses on that (which is the problem with Matrix, it can't go anywhere because it's fettered by a commercial entity that doesn't actually know much about protocol development). IRC and XMPP on the other hand have a standards body, but need to stop advertising them as if only the public network is usable: they need companies on board building their own services that use them (and possibly federate, or possibly allow third party clients).
It's ironic that Golang.org is not accessible from Iran because of app engine.also several non proprietary repos like sourceforge. The only way to get go lang's source code is through github.
It is only a matter of time untill Microsoft decides to block github for Iranians as well.I don't know why github is not currently blocked but I would not be surprised if it gets blocked.
None of the Google developer-oriented resources are accessible from Iran. For example, you have to use a VPN to download Android Studio or access Google educational materials. Golang is just yet another Google project that has blocked Iran.
My intention was to show that in reality it doesn't matter whether a software is open source or proprietary like sourceforge .golang has nit blocked Iran .I highly doubt anyone among go community and creators would think or know about this issue . it is only blocked because of app engine just like many other non-google websites which use app engine.
Try to propose running your own chat server at any medium to large company. No VP of engineering or CTO wants to worry about that and the possible security risks. If Slack messes up they can blame Slack but if you mess up and expose some Healthcare data to the outside world because of your chat server they are screwed.
I've seen that too, but it's usually the same people who just reject anything hosted somewhere else with statements like "we're not doing airquotes The Cloud" and think all tech companies are conspiring against us.
This is true. If you are in the EU you might not even legally be able to use a US hosted solution depending on what data you are sending over the chat...
I've had the opposite experience; at my last job (a medium sized tech company that you've heard of and probably use tangentially on a daily basis) they wouldn't hear of using anything cloud based because then someone else could potentially leak their data.
I wonder if part of the reason we don't have any great open source Slack competitors (yes I know about Mattermost, Zulip, etc.) is that so many open source developers (or at least commenters here) seem to be under the illusion that IRC is a reasonable alternative to Slack.
Just terrible UX in general, and a very bloated & power hungry client. Search is borderline useless, and it's difficult for me to find anything that was talked about a couple weeks ago (meanwhile I can easily grep IRC logs for things that were said years ago). People at work turned off mobile notifications because they sometimes work, but usually not when you want them to work. I wish we'd just switch to IRC.
What protocol does Mattermost use? I was under the impression that it was XMPP, but I can't find anything that says that now that I'm glancing at it. Did they invent their own as well?
There's a move to work on ircv3 as well. Not sure how far we are from these sort of changes, but I would love to see rich IRC clients. I've seen IRC clients that preview images and such, so Slack isn't any more special in comparison (in my opinion anyway). Since it's all things a client can just support.
Google for "Telegram Security" or "Telegram Moxie" to see why Telegram / mtproto might not be the best choice. This is repeatedly the topic on Hacker News as well.
That’s pretty much the point of sanctions, what did you think was going to happen, people of sanctioned countries getting a medal? The point is to put as much pressure on those countries as possible and there is no better way to pressure a country than to pressure its people to force a change. The question should be whether or not Iran should be sanctioned. But if you agree that it should then this is an example of a perfectly reasonable outcome.
Wait, so sanctions against a country should affect all people who share the common ethnicity in that country regardless of citizenship status or location in the world? So essentially it's a sanction against an ethnic group, not a state. Are you sure that's a reasonable idea?
How did Slack figure out this guy's ethnicity / citizenship / status? Why are they allowed to access that information and unilaterally act on it? Sounds like there's a valid question being asked here to me.
They didn't figure out anyone's ethnicity, according to their press statement they banned all accounts which were accessed via Iranian IP's. While seemingly a little heavy handed IMO, they are trying to comply with US laws. They also provided a way for people to send an email to address their specific accounts if they feel they were terminated improperly.
Slack is protecting their multi-billion dollar business and their investors which are both based in the U.S. If they do not, they could run into trouble and put far more at risk. This does not only affect Iran, it affects other countries too which the U.S. has active sanctions against.
Not just a little heavy-handed. If that's what they did, they probably picked up users that just happened to use the service from one of the countries at some previous point in time. And, at that point, the sanctions may not even have been in place.
Now, I admit that visiting the countries on the list aren't on my to-do-list, but if for example I decided to make a vacation trip to Cuba I really shouldn't lose my account at any US-based service just because of that.
That's a question for Slack how they found out and that is a great question, but there seems to be much conflation of that question with justification of sanctions in the first place, which I wanted to address. It's a question of nationality and citizenship if Slack determined one of those to be the case then they simply followed the regulations set forth by the sanctions.
The status of being a student does not expunge your status of being a citizen of your country of origin nor does it cut all your ties with said country. Part of sanctions is to pressure citizens of sanctioned countries in order for them to seek change in their governments.
Using a proprietary protocol that doesn't allow any form of federation is an unacceptable way to build a global community. Please consider using an IRC based service for group chat or an XMPP based service where 1:1, history, rapid reconnects, and other more complex chat features are required (yes, if you're a dev you have to use XML which is annoying, but overall it's a well designed protocol, so get over it). This lets you host your own, and (in the case of XMPP at least) if one person wants to use a U.S. based service and another is in Iran they can just sign up for a Belgian account (or wherever). We can't afford to let he internet splinter off into siloed tiers based on nationality.