Tag Archives: api

I will return to Twitter when…

As I’m catching up on some news, two posts today about Twitter caught me eye. First, very big news via Federico Viticci, that full tweet search is available even to third-party apps. Twitter’s limited search was the main reason I originally built Tweet Library. It’s fantastic that this data is now more easily available.

But it was this opening paragraph from Jason Snell’s article on Macworld about Twitter neglecting the Mac version that got me thinking:

“Three years ago this month Twitter broke its covenant with the third-party developers who helped fuel its initial growth and create some of its most innovative features. The message was clear: Twitter was in charge of its own platform, and while other Twitter apps would be tolerated, it would only be in limited fashion and for a limited time.”

It was around this time, nearly 3 years ago, that I posted my last tweet. My bet with Daniel is over whether I will return to Twitter within 5 years. People ask if I’ll come back sooner, and if I did, what it would take. I’ve often struggled to articulate those conditions, because I think we are seeing slow but consistent progress to unwind the developer-hostile decisions made a few years ago. It may be that in a couple years the environment will be much improved, but there won’t be any single decision that “fixed” it, or it may be that Twitter is doomed to have changing leadership and there will never be any guarantees.

There is one thing, though. There is one change that was made while rolling out the version 1.1 Twitter API: they removed support for unauthenticated RSS feeds of user tweets or timelines. If they reversed that one decision, the next day I would be back on Twitter.

I can pick out a single feature like this, among every other improvement that third-party developers would love to see, because the combination of removing RSS and at the same time locking down the API — those changes together best represent the move away from the open web. Any other incremental improvement short of unauthenticated RSS, no matter how welcome, isn’t enough.

Ev on Twitter third-party devs

Business Insider quotes Evan Williams on the developer-hostile attitude of previous Twitter management:

“The API denial was, ‘One of our strategic errors we had to wind down over time,’ Evans explained. ‘It wasn’t a win/win for developers, users, and the company.’”

Just acknowledging this publicly is progress. It’s now been almost 3 years since my last tweet. I don’t expect to return to Twitter, but I’m still very interested in whether there’ll be a noticeable change in direction from the new CEO.

The risk of a small platform

Marco Arment responds to my comment that developers should have seen the potential of the App.net API as something much bigger than Twitter. I wanted my post to be short, but Marco makes good points that are worth following up on. He writes:

“Building an app on someone else’s API, rather than making your own, is a huge risk: it usually only pays off if the service provides a huge existing userbase and hard-to-duplicate functionality. App.net never offered either. They started out facing the typical social-network chicken-and-egg problem, put a huge paywall in front to prevent any growth, and tried to alleviate that by adding more chicken-and-egg problems to their offerings.”

Building entirely on App.net for Sunlit was indeed a huge risk, and one that we expected would take time to pay off. It was a bet on the future. We are incredibly proud of our app and the response it got in the App.net community, but our goal was always to make an app that appealed to everyone, not just a small niche of tech folks. We’ve actually been working for over a month on a new version of Sunlit that expands the reach of the app beyond App.net, and coincidentally it just went into review at Apple this week.

But I think the chicken-and-egg problem was solvable. The main issue with iOS apps is that they couldn’t sign up a new user directly in the app. This made sense when App.net was a paid-only service, because you’d run into in-app purchase issues with Apple, but it became more technically feasible when the free tier launched.

The App.net founders also seemed receptive to the idea. There just wasn’t time to make it happen. I believe this single roadblock prevented any potentially-mainstream killer apps built on App.net from getting off the ground. If it’s not easy to open a third-party app, create an account, and start using the service, too many people will give up. (Our numbers showed that only 40% of Sunlit downloads actually signed in to use the app for real.)

However, building our own backend for the app would also be very challenging and expensive. We are not syncing small bits of data around. It’s a photo sharing app, so right off the bat you’ve got big files that have to be hosted somewhere. On top of that there’s collaboration features, so you need not just user accounts but private sync channels that have specific read/write access to certain users. Plus all the metadata and formats to support syncing text, photos, and location check-in information. Not to mention publishing HTML, thumbnails, and maps. It’s daunting.

(In fact, it’s so daunting, I don’t think there’s a single app in the App Store that has feature-parity with Sunlit. The app simply could not have been built by a tiny team of 2 part-time developers if building a whole backend infrastructure first was a prerequisite.)

Marco closes with this:

“As much as App.net wanted to be — and eventually was — much more than a Twitter clone, it got the vast majority of its initial funding, enthusiasm, and developer support from people’s anger at Twitter’s dickification. But internet outrage doesn’t last long. Since App.net never became the new primary place where our friends all hung out, most of us never left Twitter — we all just accept that they’re dicks now, and we forgot about App.net.”

There’s an argument to be made that App.net’s core mistake was building the Alpha web interface only far enough to match Twitter’s features and then moving on to other things. Instead, they could have kept improving Alpha until it was significantly better than Twitter, so good that it couldn’t be ignored. By doing so, maybe they would have also more effectively demonstrated the power of the API underneath.

I assume that App.net chose not to do this so they wouldn’t compete with developers. After all, the service was founded on the idea that developers should be respected and given every opportunity to succeed. Finding the right balance to showcase the platform with first-party apps without stepping on developers is not always easy. We can argue about which missteps were the most costly, but the founders never wavered on their original principles and they promoted every app that launched on the platform. That means something.

As for outrage not lasting long on the internet, Marco’s totally right. I just don’t forget that easily.

Tweet Marker now paid-only

If you’ve read my blog posts about Tweet Marker over the years, including this one when introducing a paid plan, you might hear a little indecision on the right path forward. I’ve run it more like a community service and less like a business, and admittedly the window for turning it into a profitable endeavor has slipped away. But I still want to make the service work well and improve it.

After vacationing this week leading up to Thanksgiving, I finally realized I need to remove the support burden of giving out free access. Starting today, Tweet Marker will transition to a paid-only service. To make this easier, I’ve introduced a less expensive $25/month plan for smaller developers. (Previously the only choice was $75/month, which is now the top tier plan with unlimited active users.)

This solves the problem of automating access to the API. Instead of having to manually fulfill API keys so that developers could try out Tweet Marker, which usually meant weeks or months of delay until I could get to it, by signing up online, developers get immediate access to the API without having to wait on me.

In the short term, this change means that new apps must subscribe before using the API. In the long run, all existing apps should also transition to a paid plan. I haven’t set a hard deadline for existing apps yet, but will work with developers over the coming months to do so.

You can learn more at tweetmarker.net/developers/.

Update: To be clear, this post is only for developers. There’s a $1/month subscription for end users but it is optional.

Twitter API v1.1

My apps Watermark and Tweet Marker were recently updated to version 1.1 of Twitter’s API. I’ve also finished the coding changes in Tweet Library to support 1.1, but it has not yet been submitted to Apple. I expect it to be another week while I wrap up a new feature included in the update.

I don’t like having my release schedule dictated by others, but that’s life as a Twitter developer. And why I no longer post there.

This matters today because Twitter is running an API blackout test. Tweet Library will not be able to load new tweets this afternoon for about an hour (3pm PST) while v1 is unavailable. I’ll post again here and from @riverfold on App.net when the new version of Tweet Library is shipped off to Apple and live in the App Store.

Twitter lock-in

With every day since Twitter’s new rules were announced, my opinion grows stronger that this is the end of the platform as we’ve known it for the last few years. It hurts that so much of what was pioneered by the developer community has been co-opted and trademarked and turned against developers. Nothing will change tomorrow; we can expect new versions of Tweetbot, Twitterrific, and my own app Tweet Library. But in the long run it’s a dead-end.

Lex Friedman, writing for Macworld:

“Some developers are notably hesitant to speak on the record, lest they incur Twitter’s wrath; the fear seems to be that since Twitter is now exerting more control than ever over access to its API—which developers leverage to make their Twitter apps work—that irking Twitter too much might result in a developer’s API access getting revoked.”

I have less at stake than developers with popular mainstream apps, so in a way I feel it’s my duty to speak out when it’s warranted, where others can’t. I’m quoted in Matthew Panzarino’s article on the Twitter API change, and I was interviewed for a radio spot on San Francisco’s KQED.

I could live with some of the API changes. I could live with the display requirements, even the user caps. Maybe I could live in a developer-hostile environment, finding a market niche far below Twitter’s radar. Except for two things:

  • “Timeline integrity”: The display guidelines say you can’t mix other content in a timeline of tweets. You can’t easily have a multi-platform app that shows both App.net posts and Twitter tweets in the same view.

  • Trademarks: You are allowed to use “Tweet” in the name of your app, but only if Twitter is the only service you support. You can’t add Facebook or App.net or Heello support alongside Twitter.

These are anti-competitive and unworkable. So I’ve decided to spin off Tweet Marker Plus, my paid web-based app that builds on top of the Tweet Marker sync engine. I’ll relaunch it with a new name, slowly introducing new features that aren’t tied exclusively to Twitter. For a hint of where it’s going, you can follow me on App.net.

Tweet Marker Plus and API v2

Tweet Marker is going really well. It’s growing fast, users love it, and it has wide support in all of my favorite Twitter apps.

Today I’m announcing the next step for the service: Tweet Marker Plus. This is a paid subscription with additional features, such as a brand new search and a web-based timeline that syncs with Tweet Marker. Along with Plus, I’m rolling out version 2 of the API.

We’ve learned a lot over the last few months. Here are some of the things that I wanted to improve for the next version of Tweet Marker, both for the API and the business.

  • Consistent behavior across clients. It was fine at first for everyone to experiment with their own way to use the API, but now it’s time to come up with some best practices to guide developers.

  • More frequent sync. Mac and iPad clients in particular — where the app may stay in the front for some time — need to be hitting the server at regular intervals to catch changes from other devices. I believe this is the most common source of problems.

  • JSON-based API. The “v2” API should use JSON and carry more metadata, such as timestamps for the tweets and when it synced.

  • Profitable hosting. Although I’ve accepted donations since nearly the beginning, hosting costs are way up. I didn’t originally intend to turn this into its own business, but that is the clear way forward. It needs to bring in consistent revenue to cover hosting now and into the future.

With paid subscriptions, I can tackle the above bullets and also add more features. The first new feature to launch as part of Plus is a new search. Tweet Marker Plus indexes tweets from your friends so that you can find tweets later. It’s the solution to use when you don’t want to search all of Twitter, but you also want a large collection of tweets, not just the most recent ones that many clients store and filter.

Tweet Marker Plus is $2/month. You can sign up today at “tweetmarker.net/plus”:http://tweetmarker.net/plus. Also check out “the screencast”:http://www.riverfold.com/software/tweetmarker/.

The API documentation has moved to Github and is “also available now”:https://github.com/manton/tweetmarker/.

Twitter app chance

Five years ago today, I joined Twitter as its 897th user, though for some reason “my first tweet”:http://twitter.com/manton/statuses/1457463 wasn’t until a few months later. So much has changed in the meantime — the API always in flux, the transition from primarily SMS, to web, to apps — but in many ways the core of the service remains intact and stronger than ever. Short messages, distributed efficiently to friends.

I talked about some of the good and bad of being a Twitter developer “on the ATX Web Show last week”:http://atxwebshow.com/2011/07/05/episode-34-tweet-library-with-manton/. There have been a string of changes that cause developers to scramble: turning off basic auth, discouraging mainstream clients, disabling DMs for xAuth. With each step, Twitter loses a little goodwill, and that’s demonstrated in the tweets I “collected over the xAuth change”:http://tweetlibrary.com/manton/xauthtooauth.

Even as Twitter passes 1 million registered apps, there’s a risk that some developers will stick with the platform as users only, putting their apps in maintenance mode. In May, “Kiwi developer Isaiah stopped development”:http://yourhead.tumblr.com/post/5550105265/i-love-you-kiwi-i-know of his Mac Twitter app:

“I’m just going to take a break from Kiwi for a while. It’s still for sale. I still support it. I’ll still fix bugs when they crop up. But adding new features and playing catch up with the other guys/gals is off the table.”

Maybe because I don’t have to depend on Tweet Library sales, I tend to more stubbornly ignore what is good business sense. There’s so much I still want to do. As “I wrote in my previous take”:http://www.manton.org/2011/03/twitters.html on the state of the platform: “I’m a little discouraged, but not enough to stop.”

I think that’s doubly true today. More annoyed, but also more determined to plug holes in the platform, from archiving to syncing. I couldn’t be more excited about the developers who are building in “Tweet Marker”:http://tweetmarker.net/ support.

And there’s always a chance, a feeling that something big is just around the corner. That if I don’t add that one feature, or open up that new API, I’ll miss the tipping point that makes Tweet Library really take off.

FAQ for Tweet Marker

I mentioned in “my first post about Tweet Marker”:http://www.manton.org/2011/06/tweet_marker.html that there were some decisions still to be made about the service. I don’t know everything yet, but I do want to answer some common questions I’m hearing from users and developers.

Will Tweet Marker be free?

Yes, I do not plan to charge users directly to use the service. There will also be no charge to developers for the basic sync API. However, it will take on real hosting costs, so I plan to have a more advanced paid plan (with more features and stats) so that participating Twitter apps can help pay for the service.

How useful is it if the official Twitter app doesn’t support it?

It is still very useful for users of third-party Twitter clients. I couldn’t allow the official Twitter app to use the API even if they wanted to, because theirs is a free app and has such a huge number of users. I also like that Tweet Marker becomes a selling point and discovery tool for other apps.

Shouldn’t Twitter provide this service as part of their API?

That would be great, but Twitter doesn’t seem interested in providing such a service. They don’t encourage users to read everything in their timeline, and it would be a little at odds with their focus on only the latest tweets.

Why aren’t you using Apple’s new iCloud?

The primary goal with Tweet Marker is to enable different Twitter apps to work together. iCloud is designed for storage and syncing only between apps from the same developer, so it’s not appropriate as a replacement architecture for Tweet Marker.

Where is it hosted and what language was it written in?

It is hosted on Heroku, which also powers the web site for my iPad app Tweet Library. Tweet Marker is written in Ruby with the Sinatra framework, and backed by PostgreSQL.

What about sample code for building this into an app?

I’m working on an example project for Mac and iOS. In the meantime, remember that it uses OAuth Echo, which is what most Twitter apps should already be using to post to Twitpic and Yfrog. Just change the URL to use the Tweet Marker server and include the tweet status ID in the POST body. To retrieve the value, it’s just a GET request without authentication. “See the docs”:http://tweetmarker.net/ for more.

Update: I reworded the part above about whether the service will be free, since I don’t control how third-party clients will make this feature available to their users. I also updated it to reflect the service name change from Tweetmarks to Tweet Marker.

Twitter’s platform at 5 years

Twitter recommended upgrading to OAuth “for optimal security” and so developers don’t need to “worry about the user changing their password”. While I dislike APIs that break old clients, I saw mostly the good things about OAuth, framed around letting the user approve access to their own account.

Seven months ago, as Twitter was finishing the OAuth transition, “Buzz Andersen tweeted this”:http://twitter.com/buzz/statuses/21402358130:

“Twitter isn’t just enforcing OAuth for technical reasons: it’s a way of taking control of the platform.”

I’m not sure I got it at the time. Twitter was all about open APIs, right? They encouraged new clients, and the original Mac client Twitterrific had “brought a lot of innovation and standards”:http://furbo.org/2011/03/11/twitterrific-firsts/ to the platform. Why would they need this level of control?

“The email from Ryan Sarver”:http://groups.google.com/group/twitter-development-talk/browse_thread/thread/c82cd59c7a87216a/7dd46c26157c9e29 last week showed part of how Twitter is changing as a company, refocusing from building a network to selling a product. Reading between the lines, it seems that to effectively sell ads, Twitter feels they need to control the user experience. On Twitter clients:

“Developers have told us that they’d like more guidance from us about the best opportunities to build on Twitter. More specifically, developers ask us if they should build client apps that mimic or reproduce the mainstream Twitter consumer client experience. The answer is no.”

Disappointing. At a panel on the Twitter API at SXSW, that sadly no one from Twitter in Austin knew about, the mood was pretty dim. I said to the room that we expected more from Twitter.

Then over the weekend, Ryan clarified: “we are saying it’s not a good business to be in but we aren’t shutting them off or telling devs they can’t build them.” There’s still plenty of uncertainty, but that’s a more hopeful message. I collected some additional “related tweets on tweetlibrary.com”:http://tweetlibrary.com/manton/twitterapirules.

Many people during SXSW asked me what this means for Tweet Library. Is Tweet Library a mainstream Twitter client? It has all the basic features of a normal client, but no, not really. It’s meant to be something more, something unique that solves problems no one else is working on, least of all Twitter.

I’m a little discouraged, but not enough to stop. I owe it to my customers to finish what I started: to fix bugs, add new features, polish the rough edges, and make Tweet Library the best app on the Twitter platform.

Overusing the term REST

Jens Alfke, “commenting on the new Rdio API”:http://jens.mooseyard.com/2011/03/dudes-this-is-so-not-rest/:

“Maybe we should just give up on the term REST, since it’s become so diluted as to mean nothing more than ‘HTTP API that’s not as hard to use as SOAP’?”

Sounds right. “Pure REST”:http://en.wikipedia.org/wiki/Representational_State_Transfer was never strictly followed, and the advantage to consistent HTTP methods — being able to abstract parts of the client details away, as with “ActiveResource”:http://api.rubyonrails.org/classes/ActiveResource/Base.html — don’t seem like significant savings to me. Now that XML-RPC and SOAP are mostly dead, we assume that new APIs are going to be usable from any language without much effort. I won’t object to having one less acronym in the world.