Hacker News new | past | comments | ask | show | jobs | submit login
Slack closes account of an Iranian user living in Canada (twitter.com/a_h_a)
902 points by jwildeboer on Dec 20, 2018 | hide | past | favorite | 608 comments

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.

> 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.

Unless the technical skill of the average computer user has decreased substantially in the last 10 to 15 years, that shouldn't really be the case.

It has. Everyone uses computers now for less technical tasks, and some pretty much only use their phone or tablet.

Time to learn something then.

Sure... they learned Slack.

Nothing to learn there.

I don’t think you realise how well you just made the case for using Slack instead of IRC or XMPP with that comment.

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.

That's correct. Because it's the FLOSS devs who need to learn to empathize with the ordinary user.

Disclaimer - A FLOSS dev here.

> 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.

Have you ever worked a support role for an application?

Regular users have amazing blind spots. Also you’re not giving slack enough credit for their smooth onboarding process.

> Regular users have amazing blind spots.

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.

Slack’s performance issues have nothing to do with the people using it’s abilities.

As much as it annoys me too, it appears that people actually using it have enough tolerance for it that it doesn’t matter.

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.

I think the [Franklin Street Statement](https://wiki.p2pfoundation.net/Franklin_Street_Statement_on_...) is a good start.

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.

[1] https://matrix.org/docs/projects/try-matrix-now

[2] https://matrix.org/docs/projects/clients-matrix

[3] https://github.com/mujx/nheko

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).

Since multiple people asked this, I started a write up. I'll try to post it soon.

Matrix.org foundation is being founded. It has taken some time, but is quite close already: https://matrix.org/blog/2018/10/29/introducing-the-matrix-or...

The Matrix developers are familiar with XMPP, and have it covered in their FAQ: https://matrix.org/docs/guides/faq#what-is-the-difference-be...

> 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.)

Let's look at how Slack is used in my workspace:

- 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.

What technical need is that?

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.

[0] https://gultsch.de/xmpp_2016.html

[1] https://wiki.xmpp.org/web/index.php?title=Myths#Myth_Three:_....

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.

What are your pain points with the matrix proto?

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.

Off the top of my head...

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.

The other features are atm a work in progress.

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.

Slack is free for users in FOSS communities. So they beat IRCCloud by 5$. Why would people with a question pay those to get into your community?

I hate Slack for open communities as much as the next person, but IRC or fixes on top of it aren't really the solution.

>> you're paying them $5/user/mo instead of paying Slack $6.67/user/mo and you're right back where you started

Are we complaining about price or are we complaining about proprietary services?

I’ve honestly never found an IRC client with a sane UI. If it’s tedious for technical folks, why do you expect it to be preferable to slack?

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.

> persistence and access to history


> there are surely ways to solve that

Most common solution is to use something else.

Custom emoji.

You could say IRC could do anything any other chat program does, but it doesn't.

Slack's "persistence and access to history" seems questionable.

And re IRC, I gather that Sabu got doxed based on EFnet logs from the late 90s.

In general, IRC is no worse than Slack... What features are you talking about?

In general Windows is no worse than Mac and vice versa. Your argument reads in the same way.

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?

setting up, just getting started with IRC for a non-tech person is basically way too hard bordering on impossible from their perspective.

We can talk about all the other issues around persistence and UX but just getting started is something beyond the vast majority of computer users.

It’s really hard for us to remember and empathize with this.

I’m a tech person and I struggle. It’s a chat app; shouldn’t be so complex.

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'm not sure why people keep saying this. If all you want is a web client, it doesn't get much easier than qwebirc: https://webchat.freenode.net/

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.

But developers are not non-tech persons, they're techies.

Access to history and search



But mostly access to history and search. (Note that it's not coincidence that this is what differentiates the free from paid Slack.)

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.

As a tech guy, history is the biggest complaint. riot.im is great in this respect because I get IRC (with history!) and a great UI.

>They started out with IRC and XMPP bridges. But they eventually shut those down because they were a drag on improving the product.

No. They shut it down because they want people to use their (crappy) UI.

Slack doesn't really offer much more than could be offered over existing IRC with an updated client and some bots on a network.

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.

Even Comic Chat was based on IRC, and that's as far from "user-unfriendly" as you can get https://en.wikipedia.org/wiki/Microsoft_Comic_Chat

> admitting that Slack beat IRC.

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".

> Number of users? That's not even sure

As far as I can tell, Slack has an order of magnitude more users. They were at 8m DAU back in May: https://techcrunch.com/2018/05/08/slack-hits-8-million-daily...

IRC was in long-term decline even before Slack: https://royal.pingdom.com/2012/04/24/irc-is-dead-long-live-i...

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.

> IRC was always a terrible experience for novices

Who the hell cares? I figured out IRC when I was about 12 and I'm no genius. If that bar is too high for people in tech then we have serious problems.

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.

Are you sure that wasn't just AIM? AIM couldn't be port blocked like IRC. Most all schools had already blocked those ports.

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.

> If that bar is too high for people in tech then we have serious problems.

But Slack isn't solely used by technical people. Where I work, everyone is on slack - product people, lawyers, tech people, etc.

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.

[1] https://datatracker.ietf.org/wg/mls/about/

Wire is open-source today and usable by regular people, with E2E encryption and email-only accounts.

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.

Here's what Moxie Marlinspike has to say about the drawbacks of XMPP.


"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?

They are VC funded and sell services (Wire Pro, Wire Red) to large companies.

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.

Could you give some examples of acceptable funding models?

> 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.

From your link.

All the usual suspects. It'll die like the google chat thing(s).

Always possible. As a counter-precedent of success, https://www.opus-codec.org for WebRTC came from the IETF, Skype and others.

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?

We're all individuals at the IETF. I have seen people agree to changes that make their job harder because it was the right thing to do.

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.

Get hacking folks. This space needs better tools.

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.

Matrix is terrible in as it is purely focused on building a protocol. Everything else is underserved. People are into Chats because of the clients.

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 exactly those reasons by those people in those size companies to explain why slack could not be allowed.

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.

No, it's because all of the big chat applications are hosted in the US and this is a completely unacceptable country to have any data in.

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.

Interesting. Even something like AWS?

Is AWS not cloud-based any more?

Just curious how far they're extending this logic.

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.

What's wrong with Mattermost? We use it for our FOSS community (and I use another instance for our company), works well.

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?

Our company still have a lot of guys on irc so a bridge was put in place to mattermost :)

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.


What about mtproto (which is what Telegram is using)?

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.

Which is a good argument for cutting down reliance on American companies.

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.

"there is no better way to pressure a country than to pressure its people to force a change"

So you would make people suffer and think that they would blame their own government for that and not the US?

Don't you think that makes you and your country evil?

He's a Canadian student. How is this acceptable in any way?

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.

Ah, I read that wrong. It's different if he's on a student via I suppose vs having permanent residency

So it seems that Slack is going through their log files and closing down accounts that have used IP addresses that are considered to be in embargoed countries. I base that assumption on various comments here and on Twitter.

If true, it is definitely the worst way to do. It doesn't take into account any circumstantial evidence that could explain the use of such an IP address (vacation, VPN, BGP or a mistake in the geolocation data used) and Slack doesn't seem to offer any way to appeal or even inform other users about what happened to their contacts.

Slack should offer a configurable notification that could contain other contact methods to the banned user. Slack could also give those users at least sth like 48 hours to inform their contacts about what is going to happen. And it could offer banned users a downloadable archive of all content created to make sure no data is lost.

But the way Slack is doing it right now means that you can't trust them and one should really think about relying on their services in the future.

I am still on IRC and XMPP (Jabber) for good reasons ;)

This is very disturbing for ways that some folks might not realize. One of the servers I've leased was assigned an IP address range whose reverse DNS (i.e., PTR records) ended in .ir.

I only discovered this because I was trying to use Google's CLI tools and got blocked, with the shocking message that access from embargoed countries was not allowed. I was utterly confused given that my server, myself, and anything to do with my hosting was all contained completely within the US. After studying the message and finally figuring out after some time the problem, I reported it to my host and they promptly submitted a correction to that, and the issue was resolved.

But had I somehow used this host to access Slack, I would find my own account deleted, if what is being deduced here is correct.

Deleting or disabling accounts is completely the wrong approach. The absolutely maximum that could be done is BLOCKING ACCESS (i.e., actually embargoing) from these restricted IPs. Disabling or deleting accounts is stupid and shows that Slack has a profound MISUNDERSTANDING of how the Internet works, i.e., it's not perfect. This is exactly akin to using an IP address for identification. IP addresses, and hostnames, are not identification of people and cannot nor should be used for these kinds of heavy-handed, punitive punishments.

Wow. But yes. I recall news from a year or two ago, about hosting providers not cleaning up old PTR records. Also, I gather that there's quite the market now for IPv4 blocks, so geolocation is an iffy thing.

Yeah, and from jordank's comment about his wife, they're using logs from years ago. That is impressively stupid.

So the next time someone attacks BGP they should divert slack traffic through Iran to get all users automatically banned? Or just think if slack accounts are compromised and a hacker logs-in through a proxy in Iran.

> Slack should offer a configurable notification that could contain other contact methods to the banned user. Slack could also give those users at least sth like 48 hours to inform their contacts about what is going to happen. And it could offer banned users a downloadable archive of all content created to make sure no data is lost.

The government could argue that any of these options is "doing business with" an identified, sanctioned individual.

I'm not saying it's right, I could just see a company attorney wanting to minimize potential federal liability.

But sanctions do not just happen from one day to the other (usually). At least in the case of Iran my understanding was that there was a political declaration to withdraw from the Nuclear Deal and impose sanctions, but not immediately. So business did have the opportunity to prepare a transition.

Vacation isn't a valid legal reason to export crypto.

It also isn't a valid reason to ban an otherwise non-sanctioned citizen for life.

My wife’s Slack account was closed yesterday.

She created the account while traveling in Cuba (legally) years ago and hasn’t been back to Cuba or any other sanctioned country since.

She is a cofounder of an org that uses Slack heavily and has now lost access to all her messages and files from the past couple years of work.

There appears to be no appeal process here.

Cuba is one of the most popular destination for Canadians, can't ever imagine what would happen if they actually ban everyone that had their IP over there at some point in the last few years.

I suspect the fact that the account was created in Cuba is what triggered the action.

If Slack did this because of her trip to Cuba years ago it means they have kept records of her IP going back years.

This causes me to think about the metadata records they have held onto in addition to all the data.

And yet some people are wondering why GDPR has a data retention policy that aims at keeping personal data around for the least amount of time necessary.

Companies should be made accountable for such blatant abuse of user data.

Right, which should also indicate that this trip to Cuba wasn’t part of a pattern but rather an anomaly.

I understand the complex legal frames that this exists in, but they appear to have the data to be way more precise here.

They may have the data, but they have no incentive to care whether or not their inferences are correct. This is a common problem with ostensibly data-driven companies.

> If Slack did this because of her trip to Cuba years ago it means they have kept records of her IP going back years

Or they did an IP to country lookup back then and kept the result of that rather than keeping the IP.

i am starting to become scared that my accounts with different companies will be closed retroactively. I have, through work, toured most of the free and some parts of the non-free world (including Iran, Cuba and sudan). That apparently makes me fair game to have my US accounts closed. Had I been a slack user I, by the look of it, probably would have had my account closed today, even though I have lived within the EU for all my life.

I am pretty certain I have logged into my mail, PayPal account and Digital Ocean account from countries embargoed in the regions my providers operate. PayPal I could lose without much fuzz, but jeez how I'd hate to lose access to my email.

I worked in webhosting forever and I've never heard of a company until this post actively digging through a users access to services to block them. What we'd do is use products like Maxmind where if you tried to sign up and pay from Iran, etc, you'd be automatically denied. I've never, ever heard of audits to SSH logs to track this stuff down. We'd audit ssh logs if there was a server that was hacked, etc, usually to see if they hacked other servers so we could take them all down at once or find out (they'd often have irc running) what groups they were in to get more info on how they did it, etc.

This is absolutely ridiculous. I've opened up Slack while in Cuba to check on work things at my American company who does no business there. I don't have anything to do with our Slack bill and I'm a US citizen. So if someone goes to see their family in Iran/etc and just happens to open Slack they'll get banned? That's hamfisted as all hell.

While it's perfectly legal for your wife, a Canadian, to go to Cuba, it's still embargoed by the U.S., and Slack as a U.S. company must comply with the embargo (even though your wife has done nothing wrong per Canadian law).

That's true, but why does that mean they need to shut down her account just because she visited Cuba? Would that mean a grocery store would then have to refuse to sell you their goods because you visited the country once?

The guy's wife didn't do anything wrong. Slack broke the law by providing an embargoed service to someone in Cuba. I'll bet money that when this was discussed with their compliance officer, the lawyers and engineers and everyone else agreed to use certain metrics (like source IP) to determine whether someone fell under the embargo. Otherwise, Slack would have to spend a lot of time and money validating people's identity, etc., in order to comply. I don't really fault them for taking this path because their exposure is huge and compliance is hard.

Your analogy about grocery stores doesn't really work because logging into Slack isn't the same thing as walking into a grocery store, because buying from a grocery store isn't the same thing as exporting food across a national boarder, and because neither food nor medicine is embargoed.

They didn't shut down their account because she visited Cuba, but because her account was created _from_ Cuba. It's unfortunate but I guess it's the only way Slack has to "know" where an account is from.

It's the laziest possible way. They could've looked at most frequent login IPs instead.

They should never have allowed the account to be created from Cuba in the first place. Slack when it was younger, didn't have good policies in place to actually follow US law. As such, now that they are reviewing their old records they realized they committed illegal actions that they need to clean up.

Yes, it harms their customers, but that harm and the resulting damages to Slack' reputation (and maybe legal costs), is what they must pay for being negligent in the past.

Not a great analogy since you normally can't shop at an American grocery store from Cuba, but you can use an American web site from there.

That's a good point except that Slack shouldn't be banning people that are not violating sanctions.

In this case, if the account was actually opened from Cuba ... that could be a problem.

What they should do is offer recourse and a way to have this resolved.

They did offer an appeals process, but that can be safely assumed not to be a process for appealing the US law and their interpretation of it — it’s much more likely a process for appealing technical errors committed by accident during bulk work, such as “you identified my IP as Cuba when it’s Florida” or “I was hacked and we discussed that back then, please recheck your logs excluding the hacker’s activity”.

So they are absolutely offering recourse and resolution, but only where it is in their power to do so.

TLDR: Don’t expect Slack to be responsive to arguments that contain “please ignore US law for my individual circumstances”.

What other life-long punishments does she deserve for doing that horrible deed? Completely removed Google account with all her data? Permanent ban from any grocery store? Revoked driver license? Lifelong ban from Amazon, HN and other US services?

I've just opened all my slack workspaces from an IP Geolocated in Tehran to test that hypothesis. Let's see how it unfolds.

[EDIT] to be on the safe side, I've also created a new workspace from said IP.

So is it related to her ethnicity as this guy is claiming it is in his case?

If not maybe everyone can consider that maybe Slack’s actions for the Iranian guy have some basis other than “his ethnicity.”

It appears we are talking about place of origin of accounts, at least in my wife’s case.

Slack could just block access to IPs from banned countries. Why are they retroactively blocking accounts? Sounds like Slack is punishing regular people who visited those countries.

If the data is worth something, get a lawyer to write a letter to them and request the data back.

Lesson: keep backup of everything in multiple jurisdictions even if you are innocent like Jesus. You know what happened to him.

Was her account the owner of the workspace? What has happened to the whole workspace?

How do people export/backup messages from Slack?

Migrating to Mattermost from Slack and transitioning all the data is easy. My team at work transitioned to Mattermost a few years ago. https://docs.mattermost.com/administration/migrating.html#mi...

Thanks. This seems to be the important part:

> Generate a Slack “Export” file from Slack > Administration > Workspace settings > Import/Export Data > Export > Start Export.

If the account is already closed, this is not possible. And this is a major problem.

The appeal process is filing a lawsuit against Slack, provided the person wronged didn’t already agree to give up that right when accepting Slack’s TOS.

Even if it wasn't given up, what would the lawsuit complain be, and what would one gain from it if it succeeds? Isn't Slack legally entitled to shut down any accounts at any time?

IANAL but cutting you off your everyday job and crucial documents (causing stress, money problems, hopefully not: unemployment) only because you happened to open an account in a random country seems like a reason good enough for a lawsuit. What to gain: compensation, and that damn' account.

You are not entitled to Slack's infrastructure, no matter how much you came to depend on it for your day-to-day life.

Well that's not strictly true. Presumably there is a contract of some sort, and Slack must abide by it, entitling users to Slack's infrastructure to some degree.

It's not completely arbitrary. Plus there're notions of estoppel potentially at play.

I'd pretty much guarantee their terms of service stipulate they can terminate an account at any time for any reason. It's how most Internet services operate. The only likely addition to that, is a monetary refund if warranted based on the account context.

Pretty sure the contract is going to be in Slack’s favor. They had all the leverage when somebody agreed to it.


One, no, you are not legally entitled to shut down accounts on the basis of race or national origin, if that's what they're doing.

Two, they may have to at least return the data: if I let you use a desk at my place and you start doing business there, I am pretty sure I cannot legally refuse you entry and hold on to your papers.

Three, even if they are, we're also legally entitled to call Slack incompetent losers, and to tell our employers that we should not switch to Slack if we wish to continue being co-workers with Iranians. I will be telling my employer that shortly. (One fascinating aide effect of using Slack is thst the entire company must conform to Slack's policies. You cannot hire someone whom Slack won't create an account for, nor someone who won't agree to Slack's ToS, because if they're not on Slack they can't get work done.)

> no, you are not legally entitled to shut down accounts on the basis of race or national origin, if that’s what they’re doing.

That’s not what the parent comment said, you’re twisting it with an assumption. Slack is not legally obligated to provide Slack accounts to anyone, that was the point.

> they may have to at least return the data: if I let you use a desk at my place and you start doing business there, I am pretty sure I cannot legally refuse you entry and hold on to your papers.

Your analogy is rather confused. The data Slack has isn’t equivalent to your papers that you dropped on their desk. When you sign up for Slack, you enter into a contract outlined in their Terms of Service that detail explicitly what they agree to be responsible for. In particular, here’s the agreement relating to your data:

“Following termination or expiration of a workspace’s subscriptions, we will have no obligation to maintain or provide any Customer Data and may thereafter, unless legally prohibited, delete all Customer Data in our systems or otherwise in our possession or under our control.”


> "will have no obligation to maintain or provide any Customer Data..."

I have to admit that this case (and some others I read in recent days, e.g. MailChimp account deleted: https://news.ycombinator.com/item?id=18715866 ) made me aware that the terms of some popular services can be much worse than I would expect. I should really start reading those terms. Thank you for helping me reduce my naivety.

> Slack is not legally obligated to provide Slack accounts to anyone, that was the point.

And this point is untrue. As long as Slack provides accounts to the general public, they are required by law not to discriminate when doing so on the basis of race or national origin. They can stop serving everyone. They can firewall access from Iran, or identify actual persons covered by the sanctions. But they are legally obligated to serve Iranians as much as they serve anyone else.

> Following termination or expiration of a workspace’s subscriptions

One, this is an individual account, not a workspace. The workspace remains active.

Two, terms of service don't override law. There may or may not be law that overrides this and says that certain rights cannot be signed away. (For instance, if you're subject to the GDPR, my understanding is it would override it.)

> terms of service don't override law.

Correct, agreed!

> As long as Slack provides accounts to the general public

Slack does not provide accounts to the general public, in any legal sense. Slack is a private business, not a public service. Please read the terms of service to understand the terminology.

> they are required by law to not discriminate

Well, they are required by law to discriminate against traffic to Iran.

But, again, you've twisted my meaning to make your own separate point. I wasn't talking about discrimination. Slack is not compelled by law to provide accounts to someone. They can legally refuse service to someone who lives in Iran, or connects to Slack from servers located in Iran.

> But they are legally obligated to serve Iranians as much as they serve anyone else.

That statement is true in the sense that Slack is under no legal obligation to provide their service to anyone, outside of the agreement they created. That is separate from and irrelevant to whether or not they're allowed to discriminate against the people Slack agrees to provide service to, under their terms of service contract.

> they are required by law not to discriminate

BTW, what law are you talking about specifically? I'm aware of civil rights for US citizens, and anti-discrimination employment law in the US, but not of a specific law that bars online discrimination. I personally believe discrimination online would be wrong and bad, but are you certain that it's illegal?

Keep in mind we're talking about someone in Canada connecting to a US service, with a plausible decent chance that he connected from Iran or through an Iran server and just forgot about it. I'm not aware of specific US anti-discrimination or civil rights laws that would protect Amir in this case.

Slack doesn't even know someone's race or ethnicity, thus can't discriminate against that. They are just disabling accounts based on the IP they were created from, which was the best they had to go by to abide the sanctions. This is for sure inexact and bound to have false positives though.

It’s not quite that simple. A case could be made that other variables are a proxy for race or national origin, and travel to specific countries is one of them.

Of course that argument has an opposing side as well, but it seems prima facie plausible as a cause of action.

Exactly. Assuming ethnic discrimination seems pretty unwarranted.

> Slack is not legally obligated to provide Slack accounts to anyone

Slack is legally obligated to provide Slack accounts to people who pay, with 30 days notice for termination in most cases. There is this stipulation:

> We may terminate the Contract immediately on notice to Customer if we reasonably believe that the Services are being used by Customer or its Authorized Users in violation of applicable law.

However, if they are terminating accounts based on ethnicity that doesn't seem like a reasonable belief they can use to justify applying export controls.

> Slack is legally obligated to provide Slack accounts to people who pay

Rather, Slack agrees to provide accounts to people who pay and agree to the contract in return.

That little stipulation is exactly what is in effect here. Slack believes the users are in violation of the agreement, and under the legal rules that Slack established and controls, they enforce immediate termination.

> if they are terminating accounts based on ethnicity

This defending of the argument based on wild assumptions that Slack is ethnically profiling is a bad place to start from. That hasn't been shown, nor is it very likely.

On the other hand, Slack is legally obligated to block traffic to Iran, and it's within reason to assume an account that ever had any traffic in Iran broke the law. It's certainly possible that Amir forgot that he used an Iran proxy, or traveled there. It's possible that someone on his team broke the rule without his knowledge. It's also possible that Slack made a mistake, which can and does happen from time to time at many companies when trying to enforce international laws using only IP traffic logs. None of that points at Slack intentionally terminating accounts based on ethnicity.

Digital data is not paper.

(Maybe this a stupid question) Why should they be entitled if you are a paying customer? Do they give you a backup of your activity on their platform before closing the account?

Honest question: if I go to McDonalds and pay for a burger can they refuse to serve me? I understand that they can refuse to serve me before paying, but after I pay their service and goods too?

GDPR holds that you own your data and are entitled to be provided a download of it. Not sure what the Canadian equivalent is, if any.

And it applies to people who are in the EU. So all these people have to do to get their data is to book a plane ticket into any EU country.

Even if the GDPR applied in this situation, Slack is trying to obey US sanctions. I’d wager a guess GDPR can’t force a company to violate those laws.

GDPR has the force of law in its area of jurisdiction. If Slack can't comply with it, then they'd better not do business in that jurisdiction. That's how the law works; there isn't some hierarchy of one country's laws overriding others'.

/s Exactly. It’s why we never saw two countries going to war.

Are you suggesting the US go to war with the EU to force them to repeal the GDPR, so that Slack can do business in the EU? I know HN typically takes a pro-business angle politically, but that seems beyond even the most rabid line that I usually see here.

If not, I am totally confused about how your response connects to what I wrote.

Other way around. The EU is the one who bears the burden of forcing American companies like slack to comply with their laws. Though jumping straight to a shooting war feels like an overreaction. Maybe start with a fine and ban the company if they don't pay.

Do the US sanctions prevent them from giving the user a copy of their data?

So, uhh, just stop using Slack then? There are plenty of alternatives now.

I don't think this is about Slack.

Huh? This seems about Slack.

Wow the Twitter thread and the experiences which are mentioned here sound so extreme and crazy that I am seriously confused to what believe.

- Is this all made up to prove some point?

- Is this just how the US ticks right now?

- Is Slack just completely gone mad?

- Is this what companies believes is acceptable nowadays?

- Is this the future of the web?

The fact that I am not sure what to believe and that I wouldn't be surprised if this is all true or equally all made up is what really scares me. Ten years ago I would have had a lot more confidence and faith in the world that this must be either a big mistake or something fishy, but today I feel like anything goes and in a week's time nobody will care again :(

It's the dystopia of the film Brazil: someone makes a typo in a database, someone else's life is dramatically inconvenienced, and it's impossible for them to access any means of redress.

> Is this just how the US ticks right now?


Maybe Slack just proved that you actually don't have to pick between malice and incompetence.

"Sufficiently advanced incompetence is indistinguishable from malice".

My dad used to say: "Never attribute to malice what can adequately be explained with stupidity", but I love yours too.

Otherwise known has "Hanlon's Razor" [0]

[0] https://en.wikipedia.org/wiki/Hanlon's_razor

Which is great for politeness, but largely rubbish for working out what people might be up to, given that people not only regularly disguise malice as stupidity, but in some cases find it highly entertaining. Hence the existence of - https://www.reddit.com/r/MaliciousCompliance/

This is a play on Arthur C Clarke:

  Any sufficiently advanced technology is indistinguishable from magic.

“But don’t dismiss stupidity.” Is the ending of the better variation of that quote I think.

I love you.


This is also the future of blind faith in a few companies that control substantial things you depend on personally/professionally. You don't really think about how much damage something like Slack (or god forbid, Google) could do to you by shutting down your account until something like this actually happens.

Add to that the dark side of being "data driven," which is that stories like this one are just part of the 1% of edge cases. These companies also try to move away from actual customer service as much as possible because human labor doesn't scale as well as automation, so you'll fall through the cracks as long as the news that it happened to you doesn't get enough press to make it worth an engineer's or VP's time.

I know that sounds extremely cynical, but having been on the inside in situations like this, I saw how these dynamics converged despite good intentions. Stuff like this is why sending engineers through front-line customer support rotations tends to dramatically motivate engineering teams to make quality of life improvements. Once you lose the detachment that indirection from the user gets you, suddenly those 1% cases feel more important.

For more than a decade, Section 230 [1] has protected internet platforms from censorship of user-generated content. Why is Section 230 not applicable here, or is a similar law needed with wider scope?

[1] https://www.law.cornell.edu/uscode/text/47/230

> It is the policy of the United States— (1) to promote the continued development of the Internet and other interactive computer services and other interactive media; (2) to preserve the vibrant and competitive free market that presently exists for the Internet and other interactive computer services, unfettered by Federal or State regulation; (3) to encourage the development of technologies which maximize user control over what information is received by individuals, families, and schools who use the Internet and other interactive computer services;

Because this isn’t about content, it’s about OFAC designations. That’s the office in the US Treasury department that says who Americans can’t do business with. They’re the ones that enforce sanctions and Iran is on their list.

Penalties for noncompliance are stiff and there are no safe harbour provisions.

(IANAL but I have implemented systems to check OFAC lists at other companies and seen it result in similar situations)

Even if what you say is technically true, Slack appear to have interpreted that as saying that they can't do business with anyone who as ever in the past opened up the Slack app in a designated country, whatever their nationality and/or reason for being there. At the very least, that is a shoddy algorithm.

> ... who as ever in the past opened up the Slack app in a designated country ...

But they don't know that. They have IP addresses. And they do geolocation. But IP-based geolocation isn't reliable enough for that.

> But they don't know that.

They have information from which they conclude that; this information is fallible and conclusions are not certain, but that's true of virtually all “knowledge” about the material world.

Well agreed, which makes it worse.

One of the replies to the OP in tweeter says "anyone who is legally an Iranian citizen". That basically covers all naturalized American citizens who emigrated to US from Iran.

Iran does not recognize changes in citizenship.

Iran does not recognize changes in citizenship.

The U.S. government doesn't care what Iran recognizes. The correct quotation would be "anyone who is legally an Iranian citizen in the eyes of the U.S. government."

When an Iranian citizen becomes a naturalized U.S. citizen, their Iranian citizenship is no longer valid in the U.S.

There is a limited number of nations that have dual citizenship agreements with the United States, and Iran isn't one of them.


Maybe it's time for Congress to help companies differentiate between:

(a) the objectives of laws prohibiting large commercial flows to sanctioned countries and

(b) the objectives of laws encouraging many tiny information exchanges on the internet, taking place outside of sanctioned countries

Is it worth burning down Internet commerce in the hope of catching a few individuals? Did Congress intend to create a Do-Not-Speak list, or one such list for every Internet company? Should Internet UGC platforms now relocate outside the USA, when Congress is also encouraging companies to repatriate assets to the USA?

Is it worth burning down Internet commerce in the hope of catching a few individuals?

What's happening here isn't an attempt to catch a few individuals. The goal is to put pressure on the entire government of Iran. This is done by making doing business hard for large businesses, as well as individuals, so that pressure to change is put on the Iranian government from above (businesses) and below (the people).

I don't think this is the future of the web.

This sort of thing is a temporary blip before everybody figures out decentralised solutions for everything.

Decentralisation is clearly the end game as long as politics causes problems like this. A decentralised solution will continue to "just work", while centralised solutions continue to boot people off. It's pretty obvious which one is going to win.

Except looking at the past 20 years or so it seems clear that the trend is going the other way around. Slack itself is an example of that, not long ago it would've been a set of self-hosted tools. People have ditched IRC in favor of Discord and friends, they've ditched decentralized forums, BBSs and mailing lists for social networks, everybody hosts everything using the same four or five cloud providers, streaming and direct download is much more popular than BitTorrent etc...

Maybe this trend will reverse eventually but I don't really see the signs yet. The Cryptocurrency crowd keeps shouting "decentralization" but they still fail to create applications that can compete with the centralized alternatives in terms of usability, performance and cost. There have been many attempts at making decentralized social networks but they failed to gain mainstream adoption. IPFS works pretty well but again, hardly anybody uses it.

I'm all for decentralization but there's no denying that there seems to be a path of least resistance towards centralized solutions. They're easier to develop, easier to maintain, easier to upgrade and often easier to use.

So for me decentralization is the objective, but unfortunately it's not "clearly the end game".

Exactly. I understand the desire for decentralization. There is certainly a lot of hype, and in the cryptocurrency world it verges on religious belief. But I haven't yet seen any examples of the trend reversing.

Even most of the very technically competent people I know are gradually moving toward central services. I'm part of a co-op of people with collocated servers. We started in 2000. We haven't had a new member in years, and we are gradually losing them. I'm at the point where I should replace my server, and I'm having a hard time coming up with reasons to justify the large capital expense and significant time cost versus moving it to somebody's cloud. And that's not even considering the benefits of moving to hosted services. Not worrying about spam, email deliverability, security patches, et cetera, ad nauseam.

I think part of the problem is that the "decentralize!" crowd is willing to put up with a lot of practical inconveniences as long as something conforms to their ideological desires. Their ideology may be perfectly correct, but until it has practical consequences, most consumers won't shift. So they're going to need to come up with competitive services that are better than the existing ones. Better not just to them, but to regular users.

This is a bit of a shameless plug, but I just made a Show HN post about Glowing Bear, which is a web front-end for the WeeChat IRC client: https://news.ycombinator.com/item?id=18725038. It's entirely implemented as client-side javascript, and you can easily self-host it without any requests being made to other servers. For me, it solves the problem of accessing IRC wherever I am without having to fumble with ssh on my phone or monospace text. And it doesn't have the limited functionality of these modern web IRC clients implemented in node because it's just a front-end for WeeChat, which is one of the most powerful IRC clients around.

Regarding your note on the path of least resistance leading to centralized solutions---Glowing Bear/WeeChat is definitely more work to set up than just signing up for Slack. You need a machine that runs WeeChat and get a TLS certificate so that the browser will let you connect securely. That definitely limits it to a somewhat nerdy demographic, even among the HN readers ;)

Weechat (with weechat android and glowingbear), IRCCloud, and Quassel (with Quasseldroid and quassel-webserver) are indeed awesome solutions for IRC.

(Personally, I’m ofc biased, as I’m the dev of https://quasseldroid.info/).

But I think for these solutions to gain more mainstream appeal, we’d need to make the setup much simpler, and work on ideally making it a single-click solution for an organization to set this up for their members. And maybe even provide hosted services (similar to IRCCloud) for the many users that would rather pay than run their own servers.

Yes, you're absolutely correct. Setup is indeed more complicated than it should be for Glowing Bear. I would love to have an automated solution for it, I just don't want to be the one to build it :)

20 years is a small timeframe in my opinion. Every new technology you exemplified is better in almost every way to the predecessor except for the fact that they hand the keys to the castle to a small group of people which the ordinary users don't care about until it starts hurting them, which has already started.

Now I suspect we'll start seeing clones of facebook / slack etc but with a decentralized backend while offering all the features users care about seamlessly. This might take a while but it'll eventually come.

It needs to be as close to convenient in order to catch the masses.

Even on the technical side, most tech products have convenience as a selling point to being more productive/effective/agile, etc.

It will take time before decentralised services become mainstream. It's slow right now and we are still learning, we need things to be easier. The backend is basically figured out at this point and we need to focus a bit more on UX.

Regarding torrents, many game clients will use torrents for their downloads, the user simply doesn't see and deal with the torrenting.

Don't confuse self-hosted with decentralised, not the same :)

>It will take time before decentralised services become mainstream.

Again, this is looking at things backwards IMO. You seem to imply that there's a slow momentum from a centralized web to a decentralized one when in fact there's been a rather fast momentum in exactly the opposite direction over the past decades.

To me what you're saying sounds like "horses are about to become a very common way of moving goods". Maybe you're right but merely looking at the trend it's clearly not going that way at all.

>The backend is basically figured out at this point and we need to focus a bit more on UX.

You'll have to tell me more specifically what you have in mind there because that sounds very optimistic to me. We've had decentralized "backends" for as long as we've had the internet. The web is mostly decentralized by design. Even DNS is distributed across plenty of authorities for the various TLDs (even if each of them is effectively centralized and not anybody can become an authority).

Email is decentralized. BitTorrent is decentralized. IRC is decentralized. We're collectively moving away from these technologies, not towards them. I'm personally still a heavy user of all three of these things but it definitely feels niche now (email obviously isn't but self-hosted email is).

>Regarding torrents, many game clients will use torrents for their downloads, the user simply doesn't see and deal with the torrenting.

Which is pretty much irrelevant in this conversation then. It's about the technology people use to share content with each other, not about how Blizzard chooses to update your WoW client. It's a locked-down, vendor-approved way of distributing software from a centralized authority.

>Don't confuse self-hosted with decentralised, not the same :)

It's not the same but it's related. In general if something is truly decentralized then it becomes self-hostable otherwise it's more distributed than decentralized. Anybody can host their Bitcoin node, their Bittorent peer or their email server. I can't host a Facebook node.

Until taking part in a decentralized system is a crime by itself due to potentially illegal content and your possession and distribution of that content.

The distributed system does not stop to work then, but the user might risk punishment for using it, which might be even worse than not being able to use it.

I've been thinking about running a Mastodon server so I'm in control of my social media, but I'm worried about letting anyone use it because of the GDPR.

When decentralized systems are illegal, only criminals will use them. Anonymously. And very likely, using your devices as botnet slaves. But pretty much, you get what you select for.

It will also drop the userbase below a useful threshold. Sure, there will be the technical possibility of still managing to use it illegally and undetected--but there will be no herd immunity, there will be no effects of scale that make the system particularly useful or affordable compared to proprietary, centralized, and more performant alternatives. People can and do still use bittorrent illegally, but it doesn't have even close to enough market share to make centralized streaming services nonexistent or non-competitive. Basically the same idea.

The fact that you can't decentralize legislation and physical governance is not insignificant. You can't block the influence of preexisting powerful actors. Those factors do have the power to destroy the decentralization movement, and most likely will.

Some of us don't particularly want the "herd". The Internet was a better place before Eternal September. And it arguably would have become a far better place, without commercialization.

Maybe those "powerful actors" could prevent decentralization from becoming mainstream, but they can't kill it. Consider marijuana, for example. Use has been demonized for decades by the US and its allies. But that didn't stop an appreciable fraction of the US population from using (or at least, trying). And now it's becoming legal in more and more states.

For Internet decentralization, the driving factors will almost certainly be porn, gambling and prostitution. To the extent that they're driven off the clearnet, demand for them will fuel growth of alternatives. Freedom of expression is essential, of course, but it will be just a side benefit.

The more decentralization is suppressed by "powerful actors", the more it will be dominated by other "powerful actors". That is, by organized crime.

That was the same with the cryptography export restrictions during the 90s.

"..decentralised solutions for everything"

It will never happen, at least not on a scale that will affect significant web traffic.

There is another model, not decentralised but a practical middle-ground: the WordPress model.

Consider the following: Wordpress is an example of a profitable open source app that can easily be installed on countless shared hosting platforms or on a VPS. It's easy to switch hosting providers when you want to (and to take your data with you). It's popularity means that one-click installs are widespread.

Unfortunately, there is no common standard for software installation on the server side, and this lack of an easy installation process for everyone else severely limits self-hosting websites and apps.

Many developers think deploying a server-side web app is a non-issue, or they erroneously think that installing Cloudron/providing Docker instances/typing command line instructions are all "easy". Have you seen the server deployment instructions for "web friendly" languages like Ruby and Python? It's ludicrously complicated. And still developers seen nothing wrong in such install procedures. It's so frustrating.

I wish there was some momentum or traction in making server-side web app installation as universally simple as a one-click Wordpress install. It would also unlock countless opportunities for developers to reach more users or customers. But maybe some developers secretly prefer the complexity? It certainly makes selling a SaaS solution much more attractive over the stupidly complicated self-hosting option.

Decentralisation has costs, and note that booting off ""disruptive"" users (however defined - spam, abuse) is an absolute necessity of running a communications service. These costs are part of why USENET died.

> Decentralisation is clearly the end game as long as politics causes problems like this.

Only techies care about decentralization. Most people would rather follow a Twitter feed rather than an RSS feed. Most would prefer a mega forum like Reddit rather than multiple, standalone forums with separate accounts. There are also network effects that give centralized platforms more of a competitive advantage.

I keep hearing people talk about the need for decentralized social media, but nobody knows how to make it an attractive, viable option for the masses...especially when such a solution wouldn't be as profitable (or as frictionless) as Facebook, Twitter, etc.

> I don't think this is the future of the web.

This is the future of a centralized web with products, services and companies that people salaries to develop products and services.

The decentralized internet utopia is dead. Stick a fork in it. It is a fringe populated by the modern equivalent of the grey beards of 1990s.

Controversial opinion incoming: decentralization isn't going to be a silver bullet that fundamentally solves anything. These services are still going to depend on large amounts of expensive hardware and infrastructure that must exist in the real world, much like cryptocurrency. That hardware is still vulnerable to control and influence from strong corporate or state actors, so the decentralized stuff running on them is always going to be under influence as well. Even with strong crypto, methods to manipulate it either directly or through side channels will be developed. It's absolutely inevitable. Somebody controls the power plants generating and pricing all that electricity, somebody owns the internet backbone hardware, somebody can afford a much higher hashrate, somebody controls tech legistlation, and somebody is on the bleeding edge of cyber-warfare with a DOD budget. Sure, some of the hardware will be in private ownership, but not the majority. If it ever becomes widespread enough to be of great significance, traditional power structures will absolutely contrive a way to seize it.

What this all really does in the end is create a technical caste system and obfuscation of ownership. People fortunate enough to have access and be up to speed on the latest technology (or hire people who are) will reap the rewards of decentralized systems which still belong to authoritarian actors, yet it will be extremely difficult to prove that ownership--especially to laymen. It will always have a nice hazy deniability, and it will be almost impossible to hold anyone accountable for their actions, or prevent or even identify exploitation.

This is absolutely the future of the web. Perpetual and stealthy non-neutral manipulation by the technically advanced and financially powerful is here to stay. I think that as engineers our tunnel vision and intellectual hubris have given us a false sense of security as we developed this hideous system, because we thought it was some kind of purely digital realm where we have real control and real comprehension of what we are doing. But nothing is purely digital. Everything is built on top of the real, analogue world where strong actors have already divvied up and taken ownership of everything.

I wish you were right. But so far the winner takes all effect and commercial benefits pushed most things to big companies. Even the archetype of decentralization, email, is being pushed to big players by spam control.

I'm an Iranian-American and Coinbase did something very similar to me in 2017. Here is the notice they sent me: https://i.imgur.com/xnJe0kd.png

We were very convinced it was name/ethnically based as I hadn't been to Iran for a few years before. The general counsel at my last job sent a strongly worded email suggesting they may have been using names to do this (thanks AA!). The email quickly resulted in my account being reinstated without any commentary on their methodology.

This is what centralized silos are like, have always been like, and will always be like.

Unfortunately centralized silos also allow unprecedented convenience and ease of use. Nobody's figured out yet how to duplicate that in a decentralized or federated system.

I mean, Slack recently announced that they would give employees complete access to employee's private conversions.

When a company starts thinking this way, you know there's no turning back, and more such (censorship/surveillance-friendly) actions will be taken in the future.

What's there to be unsure about in terms of belief? Hundreds of people are having their accounts closed and that's a fact.

Did he visit Iran and forget to uninstall Slack before he went?

It's not about visiting a country, it's about where your Slack account was created. If you created your Slack account from an embargoed country, regardless of your citizenship or ethnicity, they will probably disable it.

He states that he created the account in Canada [1], though may have used it from Iran.

[1] https://twitter.com/a_h_a/status/1075691620081623041

>- Is this just how the US ticks right now? >- Is Slack just completely gone mad? >- Is this what companies believes is acceptable nowadays? >- Is this the future of the web?

Iran has sanctions against it right now. Slack, and other companies that have done this sort of thing with Iran, Cuba, etc the past few years, are trying to stay on the right side of the law. To avoid imprisonment, fines, etc. If you think what they did is wrong, start a company and risk serving prison time to stand up for your what you believe in by creating a similar product and offering it to customers that have direct geographical ties to sanctioned and embargoed countries. I'm serious, imprisonment is a very real risk with dealing with sanctioned and embargoed countries.

Doing business with Iran, or a citizen of Iran, can open the door for all sorts of government investigation from fines, to being shut down for an investigation, to having data from other users compromised, to criminal prosecution of employees/officers of the company.

It's a lot easier to just immediately sever ties with anyone that has had dealings with an IP geographically connected to Iran than to go one by one "hey, you an enemy of the state? You sure you aren't? Promise? Cross your heart and hope to die? Ok, we believe you, we'll just hope you're telling the truth!"

Then there's the fact that Slack uses encryption at rest and in transit, there may be a LEGAL REQUIREMENT not to allow users with ties to Iran to use the product under CFR title 15 chapter VII, subchapter C. Or they may at least suspect they are at risk of running afoul of the cryptography export laws as they stand and simply decided, they don't want to risk it to protect the company and other users.

I highly doubt this is some Islamaphobic/Iranaphobic move on Slack's part, this is simply a cover-our-ass move so we can stay in business and not risk prison time.


- 15 CFR chapter VII, subchapter C.

- 31 CFR Part 560 and Appendix A to Chapter V

- Public Law 115–44 (the CAATSA)

Heh. Seems everyone has decided to shoot the messenger.

You may disagree with the policy, but ryaymercer isn't wrong. Living in startup land where everything is light, you move fast, and things get broken, it's very easy to overlook that there is this 500 lb gorilla in the corner just waiting to smash you into pulp for doing the wrong thing.

My guess is that something internally at Slack has triggered this. It seems likely that they're in the midst of contracting with a Federal agency, or something of the sort. When you do business with the Federal government, all manner of hell is unleashed on you in the form of paperwork and due diligence. "Negotiation" boils down to litigation, and litigation is god damned expensive.

I am not saying what's happening is right. I'm simply pointing out that this is the culmination of decades of policy and momentum within our government. Wagging our collective fingers at Slack isn't going to change a thing. What can Slack do? Let's say they pass on whatever opportunity is driving this ridiculous witch hunt. So then what? Some Federal agency doesn't get to use their messaging platform? Who cares? Nothing changes.

It all starts with asking the right questions, and ryanmercer's post likely contains the answers to a number of questions that few people are asking: what's motivating this change, who is responsible for the policy, and how can our community affect change to prevent it in the future?

It's always been like that. The US sanctions are not new and many countries have equivalent.

Established businesses simply block connections/signup/login from sanctioned countries. It's part of the checklist for new apps. It's really basic.

Slack is just another startup to discover that there are regulations to follow. They did very poorly on the interpretation though.

Just because he said that he has no connection to Iran does not make that true. If you carefully read the tweets, Amir says that he travelled to Iran. It might be that Slack did something ridiculous, but that can't be seen from the data.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact