Comment by electic | Hacker News Reader

Comment by electic | Hacker News Reader

A big history lesson and a big WARNING for anyone who is thinking of building anything with Twitter's APIs. Once this company, long ago, encouraged developers to use their APIs to build products and utilities.

Developers heeded the call and flocked to the company's APIs. They built new clients and innovative solutions to make Twitter truly useful. Twitter grew fast with the developer's help and the developer's themselves did well. Many raised millions of dollars in VC funding to make vibrant companies around the Twitter ecosystem. Things were going well.

Then Twitter became greedy. Twitter decided to destroy the very companies that grew Twitter's user base. They changed their TOS monthly outlawing various product categories. They banned clients. They put restrictive quotas on their APIs to starve out companies so they could reap their revenue for themselves. Hundreds of products fell. Millions of developer hours were lost. The Twitter ecosystem shrank and so did Twitter's user growth.

So if you're thinking about building anything with this company then be warned. If anything you've built is remotely popular, then it is only a matter of time before they come to pillage whatever you've built.

Twitter also did something that I find particularly interesting: they somehow convinced developers that you needed them to bless your app and provide APIs to build a client that accesses their service, even though those credentials must be distributed to the public with your client. To people like me who are old enough to have dealt with AOL, the idea that developers are willing to buy into this fiction is absolutely insane: if the official Twitter client can do it, then so can your client, and there is nothing Twitter can do to stop you that doesn't also break their client (which they are generally less willing to do than change their API on short notice!).

As far as I can tell the only thing that enforces this is what should amount to an antitrust level of collusion between the mega-companies to restrict access to products (via services such as the Apple App Store) that do things that the other mega-companies dislike, as it is in all of their best interests to maintain this same fiction. The reality is that client-side API keys are totally meaningless and make no sense: in an attempt to believe they make sense some developers then start to believe other crazy things like "if I compile a token into my program other people can't read it as it is compiled" or to insist "there must be some way to encrypt my binary to make sure that other people can't get my API key", but this kind of broken thought only happens due to a broken premise :/.

(That said, it isn't 100% clear to me that if someone released a true Twitter client Apple would remove it, so if someone disagrees with that premise I am all ears: that is simply the only theoretical mechanism I can see that would seem to enforce this, and I feel like I have heard of this happening before, but AFAIK the random apps in the App Store for abusing Tindr are all based on reverse engineering the true API for the service, but it is also possible that Apple cares less about helping Tindr or that Tindr has a different internal mentality and culture surrounding this kind of thing; or it could even be the case that these now have been removed and I haven't noticed yet as I don't really pay much attention to track them, or even that I am wrong and they are somehow more indirect in their implementation.)

Once I considered writing a Twitter client and the only reasonable option was to implement a proxy that would hold the API key... Hopefully I ended up not wasting time building this!

> As far as I can tell the only thing that enforces this is what should amount to an antitrust level of collusion between the mega-companies to restrict access to products (via services such as the Apple App Store) that do things that the other mega-companies dislike

Actually, at least in the US you could be having legal problems... you're circumventing access controls, which may or may not be a "hacking crime". Also, by using the Twitter API you consent to its Terms and Conditions, so they have legal grounds to sue you (for example via trademark law; you most likely will advertise that your app supports Twitter login, but then Twitter can sue you as you advertise Twitter compatibility while violating their T&C).

It's IIRC never been tested in court so it remains an effective FUD, even without the Apple/Google store banhammer.

Where would someone even see these terms of service unless they have already bought into the fiction? The terms of service on usage of the official Twitter client could apply (saying you can't reverse engineer it), but if you are reverse engineering something for straightforward interoperability there is a lot of precedent, including for extremely similar services (such as the AOL Instant Messenger Client); I think they would be hard pressed to do anything more than ban you, just you personally, from Twitter.

It's the US government I'd be afraid of. Other governments even extradite people like Kim Schmitz into the US, who never even set foot into the US, for copyright infringement. Their justification is "he had used US servers".

Who says that this cannot be done with a 3rd party client developer? The precedent is there, circumstances may be seen similar, all it needs is a clueless DA and judge and boom you have a load of problems on your head.

I wonder if a clean UX could be constructed around users signing up for their own API key and providing that to the client.

It's not necessarily that API consumers feel they must be blessed, it's that it's less hassle. And less likely to land them in a courtroom for for violating API terms of service. "Stealing" someone else's API key sounds like a great way to prove intent to do so - not good!

Baked-in client keys still have some non-security uses: The ability to control rate limiting and help trace bugs/performance issues back to their original "well behaved" clients. It also adds some minor friction for badly behaved ones (more so if everyone's obfuscating it in their clients.) EDIT: Some API docs request that you self-report about your client in e.g. your User-Agent string for similar reasons, when no "blessing" is desired.

Server-side keys don't actually magically solve any problems anyways. You're just shifting the problem from "how does Twitter prevent API abuse by unauthorized clients" to "how do I prevent API abuse by unauthorized clients". You may be in a better position to solve that problem post-shift (e.g. "I'm okay with unofficial clients - but authorized user must individually auth against their paid account!) but you might not ("I just wrote my own twitter client - I'm in no better position to prevent API abuse than twitter.")

> That said, it isn't 100% clear to me that if someone released a true Twitter client Apple would remove it

The way I see it working is Twitter's lawyers sue the author of the unauthorized user of their APIs for intentional ToS violations & circumventing protections (where all those wonderful anti-hacking laws come into play) when they ignore the cease and desist - and either nip the problem at the source when they show up to court, or get a default judgement and a court order they can deliver to Apple.

It's a meatspace solution instead of a digital one, but it works.

Many things that make Twitter special were invented by the developers you mention:

http://furbo.org/2011/03/11/twitterrific-firsts/

> First use of “tweet” to describe an update

> First use of a bird icon.

> First to support replies and conversations (in collaboration with Twitter engineering.)

I think that's why this discussion thread is so negative, Twitter benefited immensely from the work of third party developers and then told them to go pound sand.

This! And I should know. My Twitter to Facebook client. http://2fb.me was crippled by Twitter for trying to distribute tweets. The main purpose of Twitter and a Twitter api is distribution or so I thought. Facebook on the other hand has been a great friend. And the Facebook page gets a few new followers everyday even though the app has been reporpused. Facebook.com/toTwitter

This is why I coined the phrase "Those who don't know history are doomed to repeat it" j/k

So having a big release and advertising these 3rd party tools could be completely motivated by a need for someone else's innovation? Or are there businesses left standing who are innovating and successful with their services? They've worked great for me in the past, but I've never done anything beyond using them for OAuth or showing a hashtag list of tweets.

As much as I agree with you, I wonder if the changes in leadership at the company since then might mean a different direction. Reading their blog posts, it seems like a "reboot" of sorts.

I am in the camp that still thinks Twitter is an important tool: both as a communication medium, as well as a competitor to Facebook/Snapchat/etc. Whether or not this vision for the API platform plays out as history repeating itself, or as a way for Twitter to continue to grow - remains to be seen. But I definitely root for them to try and try again when they fail.

To OPs point, definitely tread lightly at first, and don't bet your whole company on Twitter's APIs. I'm excited to see where this goes.

@replies and hashtags (one of the most successful features of twitter) came from third party apps,

I agree with your sentiment, but it applies to a lot of popular companies, especially debt financed companies that don't charge their users. When they stick their hand in the VC cookie jar, the necrotic hand on the other side, grabs them and pulls them in.

I have heard rumblings about this from a few old salty dogs, but I never heard such a detailed explanation of what actually happened with Twitter + developers.

While this API does seem exciting, I'm way more hesitant to create anything given the company's history.

Reply on news.ycombinator.com