Twitter streaming API and Micro.blog

The writing has been on the wall for years. Now that Twitter plans to move ahead with deprecating APIs that apps like Twitterrific and Tweetbot use, it’s even more clear that there’s no overlap between Twitter’s priorities for the API and what traditional clients need.

When I wrote about Icro, the first third-party app for Micro.blog, I said that I always want to encourage other developers building for Micro.blog. It’s worth exploring how these Twitter API changes compare to Micro.blog and how we can improve.

The streaming API is a big part of this. Twitter apps currently use the streaming API to deliver tweets in real-time without polling, or to notice when someone is @-mentioned so that a push notification can be delivered. Losing this API is especially frustrating because it means developers need to rewrite a bunch of code only to make their apps a little worse instead of better.

Micro.blog doesn’t actually have a streaming API yet. Micro.blog supports multiple APIs, but no persistent connection. The new app Icro doesn’t have push notifications, although the official Micro.blog app does. For a brand new app like Icro, it would be a lot for the developer to also run a server just to do push notifications.

As I think about how we solve this, I remember a discussion in the Twitter developer community when the iPhone first got push notifications. It was an open question: should Twitter third-party developers run their own servers for push notifications, or should Twitter itself deliver push notifications on behalf of third-party apps? Obviously third-party developers have had to run their own servers.

I think a goal for us with Micro.blog should be that third-party developers get access to the same basic tools that we use to build our own apps. Rate-limits should be the same for an app like Icro as they are for the official Micro.blog app, for example.

With that in mind, I’ve mentioned before that I’d like to offer a push notification service for developers. iOS and Android developers could upload their push notification credentials from Apple and Google. Micro.blog would store them and deliver push notifications directly to third-party apps.

This has a few pretty big advantages:

  • Third-party developers won't need to run their own servers. This levels the playing field so that any Micro.blog app, no matter how small, can offer basic features like notifications.
  • Push notifications are more capable now than at their introduction in 2009. They can be used not just for an alert message but for silently sending data to an app in the background, such as when new posts have been added to someone's timeline.
  • It's more efficient. Instead of keeping persistent connections open to Micro.blog servers, Apple and Google handle the persistent connections between devices and the cloud. Micro.blog can simply forward @-mentions to the clients that have requested them via Apple and Google infrastructure.

This is a little bit of extra work for Micro.blog, but Micro.blog is already doing similar processing when a reply comes through. For every reply to a blog post, Micro.blog checks if there is a Webmention endpoint so that it can forward that reply to an external site, such as one hosted on WordPress. Opening up push notifications feels like a natural extension to that.

Some developers might not be comfortable outsourcing this to Micro.blog. That’s fine. In particular I’d like to hear any concerns over security or features where this approach would be too limited. (To be clear, we’d offer this for free. Our business is blog hosting.)

Back to the Twitter news. John Gruber summed it up this way:

Twitter isn’t explicitly saying that they’re shutting down third-party clients, but I don’t know that it’s feasible for them to exist if they don’t have access to these APIs. It’s like breaking up with someone by being a jerk to them rather than telling them you’re breaking up.

That’s a great analogy. Micro.blog is barely a year old, so there is plenty still to do, and there are parts of the API that aren’t as mature yet as they will be. But I think we’re transparent about what we’re trying to do and how we can support developers. We’re not going to be jerks about it.

I’m really excited by what I’m seeing from the community. Icro is in the App Store. Slate is another iPhone app currently in beta. Dialog for Android is in the Google Play Store as a public beta. And then there are all the apps following IndieWeb standards that are compatible with Micro.blog.

WWDC is only a couple weeks away. We’ll have a Micro.blog meetup on Tuesday (June 5th) at lunch. I’d love to talk to developers at the meetup or anytime that week in San Jose to get feedback on how we should handle streaming and notifications.

Manton Reece @manton