Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Slack closes account of an Iranian user living in Canada

twitter.com

Post reply on HN
Print view View original

611–620 of 638 posts

Re: Slack closes account of an Iranian user living in Canada

#611

Post by painlord2k »

jordank wrote: post #80

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.

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.

Re: Slack closes account of an Iranian user living in Canada

#612

Post by SamWhited »

mst wrote: post #604
SamWhited wrote: post #549

Earlier quoted context omitted.

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…

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.

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.

Re: Slack closes account of an Iranian user living in Canada

#613

Post by SamWhited »

Argorak wrote: post #478
ChrisClark wrote: post #345

Earlier quoted context omitted.

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

Re: Slack closes account of an Iranian user living in Canada

#614

Post by SamWhited »

ummonk wrote: post #590
theamk wrote: post #569

Earlier quoted context omitted.

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

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?

Re: Slack closes account of an Iranian user living in Canada

#615

Post by SamWhited »

theamk wrote: post #569
ptman wrote: post #562

Earlier quoted context omitted.

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

Re: Slack closes account of an Iranian user living in Canada

#616

Post by SamWhited »

ptman wrote: post #562
SamWhited wrote: post #448

Earlier quoted context omitted.

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 pr…

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

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

Re: Slack closes account of an Iranian user living in Canada

#618

Post by gregknicholson »

dkarl wrote: post #575
adriand wrote: post #378

Earlier quoted context omitted.

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…

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 manufactu…

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

Re: Slack closes account of an Iranian user living in Canada

#619

Post by theamk »

SamWhited wrote: post #615
theamk wrote: post #569

Earlier quoted context omitted.

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

Re: Slack closes account of an Iranian user living in Canada

#620

Post by theamk »

SamWhited wrote: post #580
theamk wrote: post #573

Earlier quoted context omitted.

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,…

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 thi…

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?

Post reply on HN