Tag Archives: push

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.

Prompt for push notifications

David Smith says to not bother the user with alerts on first launch:

“I have just sorted through the App Store and settled on trying out your app. I open it up and you immediately ask if you can send me Push Notifications? I have no context about what these are going to be used for or why they might be useful to me.”

I agree. For Sunlit, we only prompt to enable push notifications after you’ve chosen to enable sharing for a story. While it might be useful to have push notifications for everyone, by waiting until we really need it, most users are never bothered with the alert. And it forced us to focus on specific and valuable uses of notifications, such as sending a push notification when someone subscribes to your shared story.

Push-based sync

“Guy English writes about iCloud”:http://kickingbear.com/blog/archives/202 and the magic glue (Push Notifications’ persistent connection) that makes it work:

“Each of these new features tickle the persistent ‘push’ connection and trigger some action on the device. The short-form state may be transmitted immediately and set on any connected device within moments. Document syncing is likely to trigger a negotiation process to compare the state on any one device with The Truth stored on Apple servers and replace the document on the device with the latest revision — this has the advantage of limiting the window between syncing where conflicts are most likely to occur.”

Sync speed matters. The first note sharing server I built for VitalSource years ago assumed a lot of offline time, and despite “my blogging in 2007 that it was”:http://www.manton.org/2007/01/bookshelf_note_sharing.html “magic”, in practice it could take 5-10 minutes before all your computers got their act together to get a set of highlights completely synced. With that kind of lag, note edits might happen on a client in the meantime, so we remembered conflicts everywhere and had a UI for resolving them.

Too complicated. The new system, recently rolled out in Bookshelf for iPhone and iPad, syncs so much more efficiently and quickly that conflicts don’t need the same emphasis. We can throw away a bunch of code and simplify the user interface.

I’ve yet to do anything with iCloud except read the release notes and sit through a couple WWDC sessions, but we’re going to have a fantastic platform if it can deliver the same speed and reliability of Push Notifications. Guy’s post is the first I’ve seen to connect the dots, capturing how well-positioned Apple is to use this plumbing for all sorts of stuff.