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

12 of 96 comments (clear)

  1. Re:Time for a boycott! - and icons by Anonymous Coward · · Score: 5, Funny

    and should not the new icon for Twitter here be a bird in a cage?

  2. *In a blandly chic conference room* by fuzzyfuzzyfungus · · Score: 5, Funny

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

    1. Re:*In a blandly chic conference room* by ledow · · Score: 4, Informative

      Provide API keys.

      Revoke API keys of programs that abuse the system.

      Not really that hard. I should think API DDoS is the least of their worries, to be honest.

  3. RIP Twitter, 2006-2012 by Anonymous Coward · · Score: 4, Interesting

    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.

    1. Re:RIP Twitter, 2006-2012 by tgd · · Score: 4, Insightful

      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.

      Simple. You can be assurred that 99.999% of Twitter's users don't care in the slightest about this, and the value of Twitter is its user base.

      Its the exact same reason none of the "free" social networking projects have made even a tiny blip in the public awareness, and will never overtake Facebook.

      Twitter and FB have done something that MySpace never did -- transitioned out of a finnicky group of users (kids who try new things all the time) and got broad usage among the pool of people who don't. (Adults who have better things to do with their time then chase the latest trend.)

  4. Translation by ortholattice · · Score: 5, Insightful

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

  5. Re:Why not make several applications? by larry+bagina · · Score: 4, Informative

    Twitter has to approve third party applications and can revoke your access at any time.

    --
    Do you even lift?

    These aren't the 'roids you're looking for.

  6. Stopping Spam? by hazzey · · Score: 4, Interesting

    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.

  7. Could have been thought through better by medcalf · · Score: 4, Insightful
    They are requiring authentication at all endpoints, at least in part to prevent mass public reading of data. But this can be done through the web interface without authentication, and a programmatic web interface is not difficult to write. All that's needed is a burner user (or set of them, if Twitter is going to be diligent about shutting them down). Since it's all automatic, the real-time services are impacted, but the spamming, data mining and other potentially nefarious uses which do not require real-time data would be unimpeded, beyond a few days to put together a client to get this information differently and the effort of automating account creation. In other words, major inconvenience for legit app developers, but minor inconvenience for those who are looking to abuse the system.

    Additionally, if you are building a Twitter client application that is accessing the home timeline, account settings or direct messages API endpoints (typically used by traditional client applications) or are using our User Streams product, you will need our permission if your application will require more than 100,000 individual user tokens.

    We will not be shutting down client applications that use those endpoints and are currently over those token limits. If your application already has more than 100,000 individual user tokens, you'll be able to maintain and add new users to your application until you reach 200% of your current user token count (as of today) — as long as you comply with our Rules of the Road. Once you reach 200% of your current user token count, you'll be able to maintain your application to serve your users, but you will not be able to add additional users without our permission.

    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.

    We hope that all of this information gives you more clarity around where we are headed with API v1.1.

    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
  8. 2 - 2 = 4? by thePowerOfGrayskull · · Score: 5, Insightful

    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?

  9. Never stand on shoulder of midgets. by Anonymous Coward · · Score: 4, Insightful

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

  10. Re:Why not make several applications? by ZorinLynx · · Score: 4, Insightful

    That's not going to work. Web scrapers break when you make the slightest changes to the way the web page is delivered.

    If Twitter notices a lot of scraping going on? Tweak the page slightly. Then 573 scraper developers have to update their code. How many times will this happen before they give up? I'm betting not many.

    I'm extremely pissed off at the way Twitter is trying to push away third party clients. TweetBot is AMAZING, and FAR superior to Twitter's own client. If they put as much effort into developing their client as they are restricting the API and whining about this, it could probably better. But of course they don't.