Marco.org

Twitter has posted some of their upcoming API-policy lockdowns and restrictions in this post from Michael Sippey, euphemistically titled “Changes coming in Version 1.1 of the Twitter API”.

First, from Twitter’s Display Guidelines, which will become requirements for all apps:

“Individual Tweet” section

Embedding tweets in a blog post in any way other than their dynamic embed code is effectively prohibited:

[3a] Reply, Retweet, and Favorite action icons must always be visible for the user to interact with the Tweet.

[5b] “The Twitter logo or Follow button for the Tweet author must always be displayed in the top right corner.

I’m pretty sure this means that I can’t just display a tweet as a link and blockquote when I want to quote it here.

Sending links to Instapaper or its clones, viewing a tweet on Favstar, and certainly sharing links to tweets on other social services is probably prohibited:

[3b] No other social or 3rd party actions may be attached to a Tweet.

Whether email clients (“Email link”) and web browsers (“Open in Safari”) count as third-party actions is yet to be determined.

Zooming full-sized pic.twitter.com images in their own windows or screens is probably prohibited:

[6b] pic.twitter.com images may not be detached and displayed separately from the Tweet.

That also seems to prohibit apps that render only photos, such as gallery or photo-browsing apps. And it might create a Twitpic-ownership-like issue.

“Timelines” section

Rule groups 1–4 dictate tweet layout with very little flexibility. Timelines in all conforming clients will look extremely similar.

Rule 5a is far-reaching:

[5a] Tweets that are grouped together into a timeline should not be rendered with non-Twitter content. e.g. comments, updates from other networks.

In other words, apps cannot interleave chronological groups of Twitter posts with anything else.

This is very broad and will bite more services and apps than you may expect. It’s probably the clause that caused the dispute with LinkedIn, and why Flipboard CEO Mike McCue just left Twitter’s board.

Closer to home for me, it affects Instapaper’s “Liked By Friends” browsing feature, which will need to be significantly rewritten if I want it to comply. (If.)

Naturally, this also prohibits any client from interleaving posts from Twitter and App.net, or any other similar service, into a unified timeline.

“Requiring developers to work with us directly”

The rest of the “Changes” post is full of bad news for developers:

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.

How, exactly, will Twitter “guide” developers who are required to “work with them directly”? What exactly are “areas of value for users and [our] businesses”?

Translation: “Once you get big enough for us to notice, we’re going to require you to adhere to more strict, unpublished rules to make sure you don’t compete with us or take too much value from our network.”

And “big enough” might not be as big as you think:

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.

Instapaper’s “Liked By Friends” feature reads timelines and will need more than 100,000 tokens. And that’s a relatively minor feature in a small web service run by one guy.

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.

Got a successful Twitter app or Twitter-integrated service already? Either “work with” Twitter quickly and make whatever changes they require before you get too many more users, or shut down.

Finally, there may also be additional changes to the Rules of the Road to reflect the functional changes in version 1.1 of the Twitter API that we’ve outlined here.

There will definitely be more rules that we’re not ready to discuss yet, possibly because we haven’t decided what they are yet, or possibly because we know you’re not going to like them.

For instance, I bet this is finally how clients will be required to display tweet ads. That requirement, probably worded roughly as “you must display every tweet in a timeline, and display them all consistently”, will also kill any clients’ filter and mute features.

Twitter for Mac and iPad

Twitter for iPhone has been thoroughly gutted of any traces of its Tweetie origins, and it’s clearly Twitter’s premiere client. (It probably gets more usage than their website.)

But Twitter’s own Mac and iPad apps, both also acquired as versions of Tweetie, haven’t been meaningfully updated in many months. Both lack significant features and have glaring bugs, and neither of them comply with the Display “Guidelines”.

Twitter’s inaction on these apps suggests that they’re probably going to be either discontinued entirely (most likely for Mac) or gutted and replaced with an interface more like their iPhone app (most likely for iPad).

Subjectivity and uncertainty

Twitter has left themselves a lot of wiggle-room with the rules. Effectively, Twitter can decide your app is breaking a (potentially vague) rule at any time, or they can add a new rule that your app inadvertently breaks, and revoke your API access at any time.

Of course, they’ve always had this power. But now we know that they’ll use it in ways that we really don’t agree with.

Anil Dash wants us to compare this to Apple’s App Store review process (while not using App.net if we’re white geeks, or something like that). The amount of power Twitter has over developers is similar to the App Store setup, but the incentives are completely different.

Many uses of Twitter’s platform compete with Twitter on some level. Twitter doesn’t need a lot of its nontrivial apps, and in fact, they’d be happier if most of them disappeared. Twitter’s rules continue to tighten to permit developers to add value to Twitter (mostly “Share on Twitter” features) but not get nearly as much out of it (e.g. piggyback on the social graph, display timelines, analyze aggregate data).

By comparison, Apple needs its apps much more than Twitter does, and Apple’s interests conflict much less with its developers’. Even its famous anticompetitive rules, such as the prohibition against “duplicating existing functionality”, have been minimally enforced and have actually diminished over time.

Furthermore, we know pretty well how Apple will behave and what sort of rules we’ll need to follow in the future. They’ve been consistent since the App Store’s launch. But Twitter has proven to be unstable and unpredictable, and any assurances they give about whether something will be permitted in the future have zero credibility.

I sure as hell wouldn’t build a business on Twitter, and I don’t think I’ll even build any nontrivial features on it anymore.

And if I were in the Twitter-client business, I’d start working on another product.