Slashdot Mirror
Twitter Restricts Client Developers
New submitter atsabig10fo writes "Twitter has finally released the hinted-at changes to their API, which include limiting the number of users for third party clients, per-endpoint rate limiting, and restrictions on how tweets can be displayed and posted. Twitter's Michael Sippey wrote, 'One of the key things we've learned over the past few years is that when developers begin to demand an increasingly high volume of API calls, we can guide them toward areas of value for users and their businesses. To that end, and similar to some other companies, we will require you to work with us directly if you believe your application will need more than one million individual user tokens.' Third party app developers are certainly going to be sweating these changes, and it puts the future of new development in question."
Anyone know if this applies to the (otherwise quite separate) Search API as well, or only to the more full-fledged Twitter API?
Will slashdot get rid of all the "tweet this" icons?
Do you even lift?
These aren't the 'roids you're looking for.
and should not the new icon for Twitter here be a bird in a cage?
"Hey guys, I've been thinking that maybe we need some new ideas on how to make our product less popular. Yeah, I know that we have to contend with network effects and a fairly strong first-mover advantage; but so did Myspace, we can do this, people! The service we offer is technologically totally fucking replaceable, and its continued viability depends on a pleasant UX for all the non-bots in our subscriber base."
"Say, your mention of UX gives me an idea... What if we were to start fucking around with the 3rd parties who produce the most popular interfaces to our product? If I remember, AOL's endless game of cat-and-mouse over OSCAR clients totally helped them retain relevance in the IM space..."
"Man, that is Genius! If we do this right, the name 'twitter' will come to mean 'Just like xmpp, only far less versatile and run by assholes' within the month. Get to it!"
"To that end, and similar to some other companies, we will require you to work with us directly if you believe your application will need more than one million individual user tokens."
Sounds hard. They should develop some kind of interface for that which can handle stuff programatically.
Lets say you want to go over 100,000 users. Your application name is: Twitterextender. Just make Twitterextenderblack, Twitterextenderplus, SuperTwitterextender, etc etc. Make a new version for every 100,000 users you hit. Would this get around the arbitrary limit? They are different aps if you change the color and/or some trivial functionality.
I'm not sure why someone hasn't built a Twitter clone that just runs on top of IRC. Twitter is in many ways web IRC already.
"...we can guide them toward areas of value for users and their businesses..." = we can charge you money
. "To that end, ...we will require you to work with us directly..." =
therefore, we will charge you money
It's on the Internet, so both.
Violence is like duct tape. If it doesn't solve the problem, you didn't use enough.
Twitter is working to make their developer ecosystem not smaller but more selective.
I've been on imageboards for years and years, yet that diagram from TFA and the words beneath it are the most offensive things I've ever seen. I don't think I can look at either of them directly.
It sounds like this might be in response to all of the reports of massive amounts of spam accounts: http://news.slashdot.org/story/12/08/14/1851243/inside-the-real-economy-behind-fake-twitter-followers This might be one way to reduce the ease that the spam-twitter-herders work while at the same time providing a bit of income.
+1 This idea gets my vote!
Life is not for the lazy.
I bet Tim Berners-Lee feels a bit awkward about tweeting 'This is for Everyone' to about a billion people a couple of weeks ago.
1. What sites are out there that implement OStatus? I know of
http://rstat.us/
http://identi.ca/
http://status.net/
2. What good and complete tutorials are there for implementing OSTatus? The ones I tried broke my brain. I want less theory and words, at least initially, and more (pseudo) code. Let's start simple: What do I need to do to make my CMS "folllowable" from the three sites above, for example? Too much theory makes me impatient, I need something simple that works and which I can enhance/refactor. So far, I'm stumped. Help? Any other ideas?
One thing is sure, Twitter has never been anything but shit, same for facebook, and app.net is just another dead end, too. So let's skip to the non-bullshit part, even though it's tedious and scary (certainly for me ^^), and get to the actual protocols that are not just a waste of time...
Why shouldn't [blogging or forum software of choice] support OStatus? Why should you not be able to "follow" posters, threads, categories or tags -- ? And if OStatus isn't good enough for that, what is, or how can we make it? I say "we", though I'm a shitty coder, but you get the idea.
In other words, if you build something like TweetBot (or Tweetie, which is now Twitter's official mobile client!), you can't get bigger than 100,000 users. So no point in spending time building a better Twitter client: if it's good enough to get used, it can't get used. This seems ... counterintuitive ... if your goal is to have a successful platform.
It does give clarity. It clarifies that Twitter is angering the very developers who are both motivated and capable of building a system to replace it. Also, this means that client innovation (the same innovation that brought hash tags, @ references and tweet discovery) will slow dramatically, which in turn opens up niches for competing services to capitalize on.
All in all, this smells like a huge error on their part.
-- Two men say they're Jesus. One of them must be wrong. - Dire Straits
Alright, so this is the part that baffles me:
Nearly eighteen months ago, we gave developers guidance that they should not build client apps that mimic or reproduce the mainstream Twitter consumer client experience." And to reiterate what I wrote in my last post, that guidance continues to apply today.
Ok, so developers need to do something to differentiate. Got it.
We will require all applications that display Tweets to adhere to these. Among them: linking @usernames to the appropriate Twitter profile, displaying appropriate Tweet actions (e.g. Retweet, reply and favorite) and scaling display of Tweets appropriately based on the device. If your application displays Tweets to users, and it doesn't adhere to our Display Requirements, we reserve the right to revoke your application key.
Right! So developers shouldn't build client apps that mimic or reproduce the mainstream Twitter experience - and instead they should differentiate by building apps that adhere strictly to the UI requirements. These requirements provide explicit detail as to how to create a client that mimics and reproduces the mainstream Twitter experience.
Wait, how's that again?
Nonono, you misunderstand... My "SuperTwit" client doesn't require more than a million user tokens... SuperTwit A requires 900k, SuperTwit B requires 900k, and SuperTwit C requires 538k. Sure, they all look very, very similar, but hey, some people just don't like the letter "A" as much as "B", and so on!
Yeah, I don't suspect Twitter would fall for it. More to the point, however, if more than a million of your users want to use client-X, why the hell would you tell them "no"?
And this is why you should never base your business model atop someone else's product. Because that way your always at their whims.. I would only consider building atop another system if your life cycle (development and bringing to market ) is measured in months, and you have an exit plan ready to go.. otherwise get ready for restrictions once root company actually needs to make money and satisfy investors...
I've had two ideas so far that might help address this.
First: correct me if I'm wrong, but if you're using an open source Twitter client, would you be able to obtain your own API key and use that? So, in theory, open source clients should have no trouble with the "no more than 100,000 users per API key" issue. Could even set up infrastructure for automatically distributing and using sets of API keys, no?
Second: if it gets too bad, switch from using "the twitter API" to "SMS". Just use SMS forwarding, point it at something like your Google Voice account, and forget there is an official "API".
(Or are they talking about killing the SMS gateway function too?)
For people information, there is an prebuilt Adblock list for that: Antisocial
There may be something you are missing here. The "don't mimic or reproduce the Twitter client experience" applies to all apps. The UI requirements that seem to mimic and reproduce the Twitter client experience only apply to apps that display tweets. There would seem to be plenty of possibilities for Twitter API-based apps that don't "display tweets to users", but instead perform analytical functions, etc.
Well, at least this explains why the Twitter-released versions of Tweetdeck are utter garbage compared to the old versions released by Tweetdeck Inc. before they were gobbled up by Twitter..
no. a turd in a cage.
I wrote my first program at the age of six, and I still can't work out how this website works.
Having lots of users is pretty pointless if very few of those users are seeing any adverts (because they access via third party clients)
If Twitter integrates ads directly into the message stream how would third party clients be blocking ads?
I know Twitter does this today (in at least the Twitter iOS client), I just don't know if ads actually go into the message stream for third party clients - but they could.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
What prevents me from using the official client API keys in my application? That seems enough to get rid of the 100k limit...
prediction? a bunch of clients pop up that use the twitter website api/access and pretend to be a browser.
Prediction: More CAPTCHAs on Twitter.com.
You just need one open-source Twitter scraping library
In other words, one single point of failure for Twitter to sue. Who remembers bnetd?
And if something does break, it notifies the developer, and it's fixed in a few minutes.
Plus two weeks for the curator of the platform's monopoly application store to approve the fix.
And this is why you should never base your business model atop someone else's product.
Yet just about every single successful video game or other commercial application for home use is based atop one of ten products: Microsoft Windows, Microsoft Xbox 360, Sony PlayStation 3, Sony PlayStation Vita, Apple Mac OS X, Apple iPhone/iPad, Nintendo Wii, Nintendo DS, Google Play Store, or Adobe Flash Player.
I would only consider building atop another system if your life cycle (development and bringing to market) is measured in months
Thus we have an exception to "never".