No Kyrie, and yet the Celtics nearly made it all the way. It was an impressive run. But LeBron, even without home-court advantage for round 2 or 3… Incredible. 🏀

→ 2018/05/27 10:15 pm

Rolled out a new setting to hide @-mentions to people you aren’t following on You can toggle it globally across all apps under Account → Timeline on the web.

→ 2018/05/27 1:34 pm

At this point I think I’d rather never send an email to customers again than bother them with a GDPR update email today.

→ 2018/05/24 10:34 am

I’m starting to jot down notes of things to do in San Jose. I try not to over-plan for WWDC, but there are a couple things I don’t want to miss. You can also now sign up for more info about our meetup.

→ 2018/05/23 12:05 pm

The Developers Union is a good idea. I’d love to see Apple incorporate some kind of discussion at WWDC each year specifically about what the union is advocating for. Kind of like the old WWDC feedback sessions, but with a very narrow focus.

→ 2018/05/18 3:45 pm

Twitter streaming API and

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, I said that I always want to encourage other developers building for It’s worth exploring how these Twitter API changes compare to 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. doesn’t actually have a streaming API yet. supports multiple APIs, but no persistent connection. The new app Icro doesn’t have push notifications, although the official 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 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 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. 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 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 servers, Apple and Google handle the persistent connections between devices and the cloud. 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, but is already doing similar processing when a reply comes through. For every reply to a blog post, 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 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. 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

WWDC is only a couple weeks away. We’ll have a 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.

Twitter executing on 2012 vision

I’ll have more to say tomorrow specifically about the technical side of Twitter’s streaming API, but for now I want to highlight where this all started. In August 2012, Twitter posted to their blog about upcoming changes to their API. This was the post with the infamous 4-quadrant chart showing which third-party apps Twitter wanted to encourage, and which apps (in the upper-right quadrant) they didn’t want third-party developers to work on anymore.

From the post:

In the upper right-hand quadrant are services that enable users to interact with Tweets, like the Tweet curation service Storify or the Tweet discovery site

Although it wasn’t clear in the blog post, Twitter later clarified that Storify and Favstar were fine. Nevertheless, Storify announced last year that the service would be shutting down… tomorrow, actually. Favstar is shutting down next month.

The post from Twitter continues:

That upper-right quadrant also includes, of course, “traditional” Twitter clients like Tweetbot and Echofon. 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.

It has taken nearly 6 years, but it feels like today’s API changes finally wrap up the work that started in 2012. The apps that are possible with the new Account Activity API are exactly the apps that were encouraged in those other quadrants. The pricing makes no sense because it wasn’t designed for traditional Twitter apps like Twitterrific and Tweetbot.

Two months after that post from Twitter, I quit the platform and stopped posting to @manton in protest. I only wish I had started working on immediately in 2012.

Today the first third-party Android app for is out in beta. This is a really big deal. Now to find where that old Android test phone is buried in my messy office.

→ 2018/05/15 1:11 pm

Trying out the Cappuccino feed reader. Looks like it has partial compatibility with JSON Feed too. (Works in some feeds, but not the timeline feed.)

→ 2018/05/15 12:17 pm

Since the day I introduced Tweet Marker, people wondered if Twitter would add an official timeline sync API. They never did and clearly never will. It’s been about 7 years.

→ 2018/05/14 2:00 pm

Thinking about Favstar shutting down. No doubt the first of several new casualties from Twitter’s latest rule changes. The end of the third-party Twitter era has a kind a “let the past die” feel to it.

→ 2018/05/14 9:12 am

IndieWeb Summit invite

I’ll be attending IndieWeb Summit next month. If you’re interested in indie blogging or what we’re doing with, consider joining us for the 2-day conference in Portland. I like how gRegor Morrill highlighted that the group should be more than just programmers:

You don’t need to be a programmer! In fact, I would love to see more non-programmers attending. We need writers, graphic artists, designers, UX engineers, and anybody that wants to reclaim some of their online presence with a personal website.

There’s a lot of overlap between the and IndieWeb communities. As we’re now in’s 2nd year, I expect the platform to become more mature, and I’ll be wrapping up a few loose ends with IndieWeb technologies. IndieWeb Summit will be a great time to reflect on what we’ve been able to do and look to what’s next.

Downtown today for a meeting and while I like getting out, there are so many little ways to get derailed and lose all productivity. It’s after lunch and just feel like I’m starting to get some stuff done. Now at Alta’s for coffee and work, overlooking the lake.

→ 2018/05/11 1:28 pm