Hacker News Reader

Comment by Mandatum | Hacker News Reader

Ripcord survived C&D letters because it didn't charge. I feel bad for OP for putting all this work in, because it's really cool - but you're going to get sued.

View on HN

I'm of the opinion that using unofficial clients for any online service should be a legal right (unless those unofficial clients cause harm to the respective service, but existing laws/regulations around that would already cover such cases). That doesn't mean the service has to specifically support the unofficial client, but they just can't intentionally block it (or forbid its use).

I am pretty certain that I can prove any client as harmful. I have been on the receiving end of apps misbehaving plenty of times, no matter which platform (JS, iOS, Android). And these were official apps with dedicated development teams.

Endless loops which flood you with API calls are a common issue, managing state is hard. Rate-limiting does not completely solve this.

Plus you can land in a situation where a user might associate bad experiences with an unofficial client with the actual service and thus leave with a bad impression overall.

I dont imagine that most users start with the unofficial client.

This is the same argument AT&T used to forbid third party telephones on their network. It didn’t convince then, and it does not convince now. Tolerating third party clients should just be part of the cost of doing business and part of the design of robust protocols.

Doesn't your API have a problem if it can be misused that way? In other words, shouldn't your backend by default distrust the client using its API, no matter whether it's the official one or anything else? Even the official client can have bugs that bring down your backend.

That's what the "zero trust" philosophy is about.

couldn't this be addressed to some reasonable agree by requiring someone to register their client and providing a fee schedule for "misbehavior"

eg. if you send more than X requests per day per user you need to pay us $y per 100,000 requests over the limit (or whatever).

the only requirement would be registering and providing billing info, which wouldn't be used if they behaved.

Yeah, I was thinking as I wrote it, "official clients can probably fulfill that bullet point" hahaha

it sucks that you could be sued if you are using a "public" api like this to write a client.

I would like to think that as long as you do not brand yourself as slack or violate any trademarks, you should be able to write an app like this. Things like email clients would fall into this category.

It's not public as in an utility. It has its own Terms of Service.

The point is it's not fair that Terms of Service can impose that restriction. Just like it wasn't fair when you were only allowed to use phones that you rented from your phone company.

Why isn't it fair? They run the service. What gives other people the right to tell them how to run it? If you don't like their terms, there are about 100 alternative projects you can use.

There are pretty clear, practical reasons you might want to control the client of a commercial network service.

What part of your argument wasn't true of the phone company too?

Phone companies are different in that they were monopolies with special legal status. Slack, on the other hand, is just one of many private companies offering roughly equivalent services.

You can still argue your case, of course, but phone companies are a bad analogy here.

The phone company is the sole-source provider and you couldn't opt for another platform. The more relevant analogy is soda fountains in a restaurant - the provider chose Coke, but I want Pepsi. (My OSS founder wanted Slack, I want discord.)

If Slack isn't the sole-source provider, then neither was the phone company, since you could also communicate by sending letters.

That's a different medium, although I understand your point: Slack is the sole source provider of communicating on the Slack network. Personally, I don't think this is a problem or should be fixed because of how I see the tradeoffs and side effects. Similarly, I want Apple to run their own app store and not allow sideloading because I prefer the set of tradeoffs that come with that, versus the other reality.

There are reasons, but it's also not smart. Organizations that pay for Slack pay for the service, not the shitty client.

You want to reduce Slack Inc to an API provider. They want to be a client provider too and they own the API server. Do you see where this won't work?

The value of Slack Inc is their API, which is currently de-facto locked to their client. People would still pay for Slack if they could use alternative clients, because the client is not the value.

You can argue that their client is not as good as it could be, that you have greater skills to deliver a better product, etc. But it has value, otherwise we'd all be using curl to access the Slack API with no downsides. That's clearly not the case by far.

> But it has value, otherwise we'd all be using curl to access the Slack API with no downsides. That's clearly not the case by far.

Only because it's next-to-impossible to call the API, because of the way they lock features to their client!

Author of Ripcord. You’re wrong, and creating and using software compatible with services is fair.

i do agree it's fair, but it's also true that the service provider could argue that they are supposed to be in total control of the service, including the front-end.

It's by societal consensus that this can be made fair, and to convince people that it is fair, there needs to be a logical, indisputable argument that it's fair. Otherwise, the service providers can always just hide behind the counter-argument of being in control and TOS etc.

In the case of Discord, for example, the terms of service doesn't even mention third-party clients. Also, these services are accessible from web browsers, which are made by third parties. There are more reasons, like users being able to run whatever they want on their own computers, but just the ones above are enough.

"You may not copy, modify, create derivative works based upon, distribute, sell, lease, or sublicense any of our software or services"

This seems to make it pretty clear they don't want you to create 3rd-party clients for their service.

Ripcord isn't a derivative work, both practically and in the legal sense. It's implemented from scratch. Ripcord isn't a resell of their service or a sublicense of their service.

If I rephrase it like this, does it make it clear?

"You may not create derivative works based upon any of our services"

In the imaginary world where that's what the terms of service says, that's still fine for Ripcord -- Ripcord isn't a derivative work.

If the terms of service allow it, then it doesn't matter what it's fair or not: you're allowed to make a client for it. The discussion is moot.

I don't agree that fairness requires service providers to provide open APIs. Open APIs are better, ceteris paribus, but that's as far as it goes.

I assume your argument is that Slack has the "freedom of contract", the right to create and offer you contracts of their choosing (and you are free to accept or decline them). That right is not absolute. Workers rights limit it, sanctions limit it, cartel and competition laws limit it. There is no reason society can't agree to limit the options of keeping an API locked down in such contracts, especially for well established companies like Slack.

And I think the advantages of such a law are very clear: More competition on front-ends could very likely create much better user experience (better organization of chats, better message and image editor, better notifications, show users whether messages have actually been sent).

Laws are made to serve the public [1]. Being nice to companies is a means to an end, not the goal itself, and the discussion about whether API should be legally accessible to third party vendors (or devices/cars/… should be legally repairable by third party repair shops) should focus on whether we get better user experience, service, and so on, and have the question of whether companies will still want to offer backend-service like Slack under such a law as a facet.

[1] At least they should be and everybody complaints when they aren't.

IMO lawsuits are less of a concern than your end users getting banned, especially since slack is typically used for work. If your existing customers are loudly angry about you in public it's gonna make it hard to get new ones

If I got banned, I don't know what I'd do first -- open a bottle of champagne or dance a little jig?

Sued for what, exactly?

Violating the API Terms of Service [1]?

> [...] Further, you will not: [...] (C) access our APIs or documentation in order to replicate or compete with the Services;

[1] https://slack.com/intl/en-au/terms-of-service/api

I would be confused as to how an add-on service such as a premium Slack client would compete with Slack. It seems it would be complementing it and the use of the client would not compete but fundamentally cooperate with Slack as a service.

Sincere question: is an alternate app competing with Slack’s services? We pay for each user who uses Slack, whether it’s by phone, desktop, or web. The client is 100% free; the right to connect to their service is what costs money. Slack makes exactly the same whether I use their app or an alternative.

I’m definitely not a lawyer, but it’s not clear to me that this would violate the ToS.

Can they actually sue, or can they just terminate the service for this one account?

I’m not a lawyer, but I believe Slack would have to show they were harmed in some way to successfully sue.

They can certainly attempt to block 3rd party clients, though. Or threaten to / actually sue, even if they’re unlikely to be successful.

Unlikely to be successful? This app has near zero chance of surviving a legal challenge from Slack.

Author of Ripcord. You don’t know what you’re talking about and shouldn’t broadcast your assumptions as fact.

You keep commenting one-line sentences without any argument supporting your sentence. You may even be right, but am I supposed to blindly trust you, a random commenter from the internet?

I mean, you don't have to. I appreciate the skepticism. I am the actual author of Ripcord. I've had an account here for many years. You will not find someone with better firsthand knowledge about Ripcord surviving or not surviving legal challenges.

I'd be interested to hear more about what sort of challenges you have faced, and if/how you responded to them, if you have the time.

Regardless of the upthread "well, just switch [your company/government/entire friend network] to an open/permissive service" non-answer, I think there's going to be ever-more need for unofficial clients for some of these services, and a big part of that is going to be how to avoid having them shut down immediately by service providers...

I would like to say stuff about it, but can't just yet.

Oh, you have a law license too?

They are based in Germany. They would need to be sued in Germany. Germany has legal insurance where you can get insurance and it will cover your legal bills and liabilites. On top of that Germany has legal restrictions on how much a case can cost. Slack/Saleforce would not have much benefit in a legal challenge due to their size and legal costs. Furthermore, Slack would have to have a legal case. Which they most likely won't have.

I was trying to remember the name of ripcord while reading this. Thanks. I used it for a while for both slack and discord and it wasn’t bad. However they did sell licenses. I just don’t think they required them. I just double checked and I bought a $20 license for it. Good software and definitely worth it as far as I was concerned.

hopefully people at Slack are smart and they hire the dude

but since they spit buggy electron shit for decade already, i think you are right, they'll do everything possible to shut this down and keep with their inefficient and bloated electron way

Slack is no longer a small private company. They are owned by Salesforce

It does, though. You need to buy a $20 license to use Slack's features.

I wouldn't be so sure. IRCCloud offers Slack connectivity (using Slack's API, not the IRC bridge that was closed long ago) and it costs money. I've used it for a couple of years now.

To be fair, I'd love to see a case like this brought to court. I'm not sure there's great precedent here. I think a case could be made that Slack was not harmed through this work.

I'd like to hear a lawyer (HN has several) corroborate this "Slack must articulate harm" claim, because there is a whole branch of civil law that exists to enforce contracts in the absence of torts; as I understand it, it's called "contract law".

This is true, and not all contracts are valid. It's why I'd love to see a good case brought. I feel like every time this happens the little guy just folds instead of doubling down.

But agree, would love to see some lawyers weigh in.

The closest precedent might be something like https://en.wikipedia.org/wiki/Lexmark_International,_Inc._v..... or whatever laws make the aftermarket parts industry legal.

This is just wrong lol. Cancel has never received C&D orders for Ripcord, and it does charge $20 for the Slack features. Please don't spread misinformation you're not even informed correctly on, dude. If they were going to order a C&D order to Cancel, then they would've done it around the project's start (around 6ish years ago). Actually research this stuff before posting posts like these, plz.

From this user's top post on HN:

> Over the years I've found writing on HackerNews, Reddit and other online sites has given me an outlet to get creative and engage with folks in a way that will shift discourse towards something I'm more interested in. I regularly lie and pretend I know about topics and areas I have zero experience in. I began noticing I received more upvotes and engagement

Should clarify: the comment above me by @amedvednikov is referring to this comment chain's original poster -- @Mandatum -- not the parent or link submitter, and the post mentioned is: https://news.ycombinator.com/item?id=30838788

Big yikes. Thanks for clearing this up. I totally misinterpreted the accusation.

My apologies, I should've made it clear and added a link.

..yikes.

someone admitting to that behavior on HN should be banned. that's actively hostile to the discourse here.

How do you see top posts?

Click on the username => submissions

Ah, ok, I would call that a “submission” but it’s an “Ask HN” so I see where you came up with “post”.

Note that the submission page is sorted chronologically, not by karma. So the concept of “top” is really more like “first”.

It seems you meant to point out that @Mandatum admitted to lying but the way you phrased it really made it difficult to verify the claim and came across to me like you were accusing @jessefied123.

There were some very strong responses [1] to your accusation and I’m concerned that anger may be directed at the wrong person. When making these kinds of accusations you should try to be more clear. Use names and provide links. Also consider if the benefit of the accusation is worth the risk of misunderstanding.

[1]: https://news.ycombinator.com/item?id=31928612

My apologies, I should've made it clear and added a link.

And indeed, the submissions are sorted chronologically. So I should've used "latest", not "top".

Reply on news.ycombinator.com