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.
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.)
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.
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.
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.
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.
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.
While this API does seem exciting, I'm way more hesitant to create anything given the company's history.
Not just talking about their API. Twitter never knew what they were doing, and that used to be fine, but the difference now is people finally figured out that Twitter doesn't know what they're doing.
They keep releasing all these new features that are all over the place (AND worse than before). They should really stop, step back, and think about only a few core fundamental problems and work on those instead.
I'm personally really excited about this, and this is probably the most cohesive a strategy I've seen for the API platform. We're very focused on fundamentals right now.
Polls were introduced in October 2015. There is still no public API to create them, view them, or vote in them -- for users using third-party clients, polls are simply invisible.
I was just criticizing about the company itself. It's great that you the API team is doing your best to tackle this trust issue but I think this needs to be dealt with on a company level. Otherwise it's just you guys working really hard to see it not pay off.
"A plan to replace the public statuses/filter, statuses/sample, and search/tweets endpoints with a streamlined API that provides increased access when rate limits are reached."
Some kind of pay-as-you-play model? Appreciate any help - building a product to help smaller businesses leverage the power of Twitter and would like to see how, in return, can help Twitter.
I never used Fabric even though it was extremely useful exactly because I knew Twitter will pull something like this.
It's really not any single person's fault. The problem goes really way back when they made the decision to become a media instead of platform. Back then it could have become anything but now it's already been decided what Twitter is, so it's near impossible to change the direction. That's why little things like this is just waste of time and money.
The APIs have been open and usable all the time.
I'm sure you're very excited about these new APIs for #brand #engagement, but don't pretend that Twitter has been a great steward of its public API over the last few years.
Like "this will be available for x months/years, you can make x requests per minute/hour/day, you can buy a plan offering x for $x dollars" and so on.
Yes, that can limit some better offer in the future? Perhaps. But that make things more stable, and people would commit more to twitter.
Can you change your terms in the future? Of course. But for newer customers. The ones that sign up right now will have that promises kept. Good for everybody.
We draw down a lot of data from Twitter. Obviously, we always want more data, so we got in contact with GNIP to see what we could afford (which, in itself took a long time). As it turns out its incredibly expensive, and as a very early startup, we couldn't afford any of their plans. We had no option but to fall back to their standard, free APIs and make do.
There are plenty of people who would happily pay good amounts of money for access to more Twitter data - there really are a million uses for it - however Twitter's current prices are far too high for anything other than a VC funded Silicon Valley startup to afford. I hate to think how many potential startups and cool projects have been killed off instantly simply because Twitter's prices are insane. You can get real-time global stock market tick data for a year for less than Twitter charge per month for access to the decahose.
So, I'm glad to see Twitter being more open about their future plans, and really happy to see they're moving towards a more self-service paid API for those than want and can afford it. I just hope they make it affordable and don't kill off too much in the process. The last thing they need is to upset a lot of developers, again.
Twitter's API has always been something they've not leveraged enough. All they had to do was keep it open, find a way of serving adds through 3rd party clients, and I suspect there would have been an explosion of good clients that could have made Twitter much easier to use for people who just can't figure Twitter out. Twitter shouldn't be complicated, but it is, and by trying to hold onto the brand as tightly as they have, they've prevented good developers from making easy to use clients that could have brought in users.
I really want Twitter to succeed. I hope this is the start of a turnaround for Twitter.
https://scraperwiki.com/2014/08/the-story-of-getting-twitter...
That aside, our treatment as potential partners was really bad. There just wasn't a process for new ideas to be brought to Twitter management attention. I wouldn't risk using their API for a business again.
And the funny thing about datasift is you can not sign up for the monthly plan and they charge you annually which starts from $60,000 for their basic plan.
...
Can't get fooled again.
Basically, Kafka over Websockets would be ideal.
I want to get excited by this API change, I really do. But I can't help but quash my own shower-thoughts about what I could do with this API, because what's to say they let their 3rd-party devs down again?[0]
[0] - http://www.theverge.com/2012/8/23/3263481/twitter-api-third-...
If the only focus is on "customer experiences", why would I want to use this network as a regular user? I don't want endless brands and marketing.
Does that mean that a 3rd-party app will need a server to handle activity notifications to replicate what twitter does on their activity page?
* Tweet count on a URL
* Read a tweet feed without auth
Also - the HN title is super misleading. The actual title is: "New APIs to power the future of customer engagement in Direct Messages".
This can increase their growth and possibly, if a company bot goes over their future non specified limits, they can cash in. Sorry, could not help myself :)
