Twitter’s Token Rush

August 27th, 2012

One of the developer-hostile aspects to Twitter’s announcement of upcoming changes in the 1.1 release of their API, is the imposition of new “user token limits.” Developers of traditional client applications will be limited to 100K tokens, or twice the number currently issued, for apps that already have more than 100K. What’s a user token? It gives a person like you or who downloads the app the ability to actually connect to and work with our Twitter account data. No token? No service.

Suddenly the total number of users any Twitter client developer can expect to support has a hard limit. Limited resources tend to rise in value, and we’re already seeing that play out in the client market. On a recent episode of Core Intuition, we welcomed Twitterrific developer Craig Hockenberry, who spoke candidly about the changes. During the episode, he pointed out that the ad-supported, “freemium” model adopted by Iconfactory and many other developers, may not survive this transition.

Tapbots, the developers of the popular Tweetbot client, announced today that they have pulled their Tweetbot alpha release for Mac, citing the new user token limitations. While exposure to a large number of users is undoubtedly good for testing and promotional purposes, they don’t anticipate it being worth the potential cost in “lost tokens.”

Matthew Panzarino of The Next Web reported on the Tweetbot news, taking care to emphasize that because user tokens don’t expire on any regular schedule, they can be used up even by users who download a client once, connect, and never launch the app again. The total number of oustanding user tokens doesn’t go down unless users log in to Twitter and explicitly revoke access to the client application.

During our conversation on Core Intuition, I pointed out that Twitter’s new policy runs the risk of invoking Apple’s ire, as well. Apple’s App Stores for Mac and iOS are host to dozens if not hundreds of Twitter API clients, many of which meet Twitter’s criteria for “traditional clients.” When a particular app reaches its 100K token limit, what happens to the user who purchases the app from Apple’s App Store a second later? I suppose it will be up to developers to anticipate their proximity to 100K, and start winding down the operation (and their business) by removing the app from the store, etc. But if they don’t? Apple’s just sold an app that, through no fault of theirs or the developers, is useless for connecting to the service it’s meant to support.

A Token Degree Of Control

It’s bad enough that clients will have to contend with a hard limit of 100K active users per application, but what must be particularly infuriating to developers is the knowledge that some of those 100K tokens may not have been used for years, and may never be used again.

The Tapbots announcement included an overt request that users of any Twitter clients should “help 3rd party developers out” and revoke any tokens that you’re not using. This underscores the doubly subservient position developers have been put in by this move: Twitter imposes a hard limit on the number of user tokens, only end-users can free up previously used tokens, and developers, helpless to address any of this on a meaningful level, are left to suffer the worst of the consequences.

At a minimum, Twitter should support developer-driven token expiration. Google, for example, supports an API endpoint for revoking OAuth 1.0 or 2.0 tokens. This gives developers the ability to improve the user’s experience when revoking a token makes most sense: e.g. if a user has opted to “Uninstall” an application. But it also provides some discretion and flexibility for the developer to revoke in other scenarios where it makes sense. A scenario such as the one Twitter is imposing, for example.

With the ability to programmatically revoke tokens, the particulars of doing so would be up to developers. For example, if I were the developer of a 3rd party client such as Twitterrific or Tweetbot, I might arrange for the client application to communicate token usage data to a centralized server. This would theoretically give me the ability to say “expire any user tokens that haven’t been used within the past year” and rest assured that I’ve freed up a bunch of tokens without inadvertenly inconveniencing an active user.

There are security issues at play here, and the unfortunate potential to seriously inconvenience an active user if a user token is revoked prematurely. But given the hard limits being imposed by Twitter, some hard coping mechanisms are due to developers. Tokens are precious, limited resource, and neither users nor developers can take them for granted any longer.

7 Responses to “Twitter’s Token Rush”

  1. DDA Says:

    First off, a minor typo: “imrpove” should probably be “improve.”

    Secondly, my understand is that Twitter said that the developer has to “get permission” to go over 100K (or double the existing number if grandfathered); while John Siracusa is correct in pointing out that Twitter never says how hard “getting permission” will be, why is there widespread belief it will be impossible?

    I’m a bit disheartened by the fact that the Tapbots folks can’t come to an agreement with Twitter for their beta but still; why assume the worst?

  2. Daniel Jalkut Says:

    @DDA: thanks for the typo fix. As for the question: “why assume the worst?” A few things spring to mind:

    1. Shutting down access to 3rd party “traditional clients” is line with other comments Twitter has made over the past year or two expressing their general distaste for such uses of the API.
    2. The fact that Twitter is imposing the limit at 100K by default strongly implies that they expect to maintain the limit for most clients. In other words, it will be an exception if the limit is raised.
    3. Any client developer who doesn’t view the 100K limit as hard-and-fast runs a serious risk of over-investing in a business that could very realistically meet a dead end.
    4. If pessimistic interpretations of these policies are out of line, then it’s in Twitter’s best interest to reframe their message to make it easier for developers to be optimistic. The ball is in their court.
  3. Aristotle Pagaltzis Says:

    And to make the converse point to DDA’s:

    Is there any indication that Twitter will not see this as contravening the 100,000 token limit – that they will condone attempts to maximise the yield of tokens in “proper” users by the use of measures that can be argued to recycle previously-used-up tokens?

  4. Homer Jones Says:

    This is the deal. Twitter is full of shit. It’s up to you all to decide if are you going to tolerate it or move on. If everyone moves on and Apple kicks out all the potentially offending Twitter apps, the onus goes back on Twitter to deal with the results of its greed. If you just passively take it you’re doomed anyway. If you think of Twitter as Hitler the situation and how you deal with it becomes obvious.

  5. DDA Says:

    Wow, only 4 comments to a Godwin’s Law violation; pretty impressive!

    Thanks for the comments explaining why to assume the worst but I’d still like to see someone (TapBots, Icon Factory, etc.) who makes a Twitter client actually ask Twitter and see if they get permission.

  6. Park Silkenson Says:

    @DDA
    Read Tapbot’s blog post: http://tapbots.com/blog/news/where-did-the-tweetbot-for-mac-alpha-go. They DID ask Twitter to see if they could wor something out:

    “We’ve been working with Twitter over the last few days to try to work around this limit for the duration of the beta but have been unable to come up with a solution that was acceptable to them.”

  7. DDA Says:

    @Park: See my first comment and note they are talking about “…for the duration of the beta…” We also don’t know what TapBots proposed or what Twitter really said only that it, “…wasn’t acceptable to [Twitter].”

Comments are closed.

Follow the Conversation

Stay up-to-date by subscribing to the Comments RSS Feed for this entry.