MarsEdit has supported Squarespace for years, and a number of our mutual customers have come to rely upon the app as a convenient means of managing content for Squarespace sites from the Mac desktop.

It came as a surprise when Squarespace 6 was released earlier this year, that support for 3rd party editors such as MarsEdit was dropped from the service. I had some cordial correspondence with staff at Squarespace, who explained that because of the laudable flexibility of the new version, it’s difficult to provide access to the content with one of the standard blogging APIs that MarsEdit uses to connect to Squarespace 5 and dozens of other services. Of course, as a developer with customers who depend on this support, I was disappointed to learn this.

I have been holding out hope that Squarespace will eventually address the shortcoming. The two possible solutions that leap to my mind are:

1. Somehow get support for one of the standard APIs working with their new engine.
2. Implement an entirely new API, unique to Squarespace, that I could consider implementing support for.

I lean strongly in the direction of #1. Obviously it would be a lot less work for me, and I’m generally cautious about taking on the burden of developing support for yet another all-new, custom API with all of its own nuanced behaviors.

But option #1 would also be better for Squarespace, in that support would be instantly restored to MarsEdit and any other 3rd party clients using the Squarespace 5 API. These XMLRPC APIs, based on the venerable MetaWeblog, are not great. But they are ubiquitous, and implementing support for one of these standards opens the doors to dozens if not hundreds of clients on every conceivable platform.

So I’ve been waiting, and when disappointed customers ask me what can be done to help, I encourage them to drop a line to Squarespace requesting restored support for their XMLRPC-based API. I don’t know if this has had any real impact, but in any case it doesn’t appear to have shifted the status quo. On Twitter today, customer Rob Wells asked Squarespace about the status of such support, starting a conversation that culminated in Squarespace underscoring that they don’t have any near-term plans:

@redsweater @robjwells It is not on our roadmap to provide XML-RPC.

— Squarespace (@Squarespace) September 18, 2012

To Squarespace’s credit they have been polite and receptive to feedback about this. In a follow-up tweet, they gave some cause to remain optimistic about future developments:

@redsweater @robjwells We’ll keep you guys up to speed on any new developments.

— Squarespace (@Squarespace) September 18, 2012

Whatever the future holds for Squarespace, it’s safe to assume that 3rd party editors will not be supported by Squarespace 6 in the near future. In the mean time, users who already have Squarespace 5 sites should keep their site as it is if they want to continue using MarsEdit. New customers who are intrigued by Squarespace but want MarsEdit support can still start a new Squarespace 5 site by signing up at the classic site.

And although Squarespace has given a pretty definitive answer for the time being, if you ask me it’s always worth letting them know how you feel. If Squarespace 6 support for 3rd party editors is something you’re dreaming of, let them know how important it is to you.

It’s been two months since Tumblr surprised me by suddenly dropping support for MarsEdit and countless other clients that connect to their service using a previously approved technique with their 1.0 API. This reduced MarsEdit’s functionality to posting only, eliminating the ability to download and edit existing posts. Two weeks ago, they finished the job, by dropping support completely for the 1.0 API. MarsEdit ceased functioning with Tumblr completely.

I’ve been spending a good portion of the past two months reorganizing MarsEdit so that it can accommodate all the new requirements of Tumblr’s API changes. It’s not all “wasted on Tumblr,” so to speak. I’ll gain benefits from having robust OAuth authentication support, for example. In fact, I’m already reusing that support for Flickr’s new preference to authenticate with OAuth. But it’s been an unwanted, unexpected shift of my priorities, and I’ll be glad when it’s over.

It’s almost over.

I’ll be honest: there were times along this latest sprint to support Tumblr when I thought of throwing in the towel. Why should I continue to shed proverbial sweat and tears for a service that has shown little concern for me? I’m not doing it for Tumblr, I’m doing it for my users. I sold MarsEdit to many, many people who rely upon it to connect to and edit their Tumblr blogs. It’s within my power to restore that functionality, so that is what I feel compelled to do.

On a side note: although Tumblr as a company has shown disdain for its API clients, I have recently received great support from one of their employees, John Bunting, who responds fairly diligently to developers on the Tumblr API Google group. He doesn’t always have great news to share, but he often does what he can to help.

I’m finishing up MarsEdit 3.5.6, which will restore support for Tumblr. While I was in there I was able to shore up a couple other long-standing shortcomings with MarsEdit’s Tumblr support: you can now edit completely private blogs and private posts, and MarsEdit now works around a Tumblr API behavior where editing a post would always change the publish date to now.

If you are interested in trying out the latest changes before 3.5.6 officially ships, I would be pleased to have some sanity checks on the fixes that are in place. Some folks have already been testing a previous beta release, but this one should be even more solid and full of goodness.

Click to Download MarsEdit 3.5.6b3

Let me know how it goes, and thanks for your patience while I worked out the various issues that were preventing me from adopting Tumblr’s latest API.
 

Gus Mueller of Flying Meat is a good friend who, for a short time, even worked on MarsEdit. Much to my chagrin, Gus doesn’t actually use MarsEdit for editing his own blogs. When I’ve asked him why, he explains that he’s too tied to a particular setup involving VoodooPad, his desktop wiki app.

To make things worse, he’s finally made his blogging solution public! You can read all about static publishing with VoodooPad on the Flying Meat site. There goes the neighborhood.

Although MarsEdit supports static publishing, I have to confess it’s pretty minimal compared to the support for hosted blog services such as WordPress and Blogger. MarsEdit support is all built around the old “Blosxom” publishing convention. If you’re interested, Dan Weeks has a good write-up about how he used this support to connect MarsEdit with Octopress.

Although static publishing isn’t a top priority for MarsEdit today, I’ll be considering enhancements that would give more flexibility and power to these setups. In the mean time if MarsEdit doesn’t fit your needs, I strongly encourage you to check out Gus’s new stuff in VoodooPad!

One of the developer-hostile aspects to Twitter’s announcement of upcoming changes in the 1.1 release of their API, is the imposition of new “user token limits.” Developers of traditional client applications will be limited to 100K tokens, or twice the number currently issued, for apps that already have more than 100K. What’s a user token? It gives a person like you or who downloads the app the ability to actually connect to and work with our Twitter account data. No token? No service.

Suddenly the total number of users any Twitter client developer can expect to support has a hard limit. Limited resources tend to rise in value, and we’re already seeing that play out in the client market. On a recent episode of Core Intuition, we welcomed Twitterrific developer Craig Hockenberry, who spoke candidly about the changes. During the episode, he pointed out that the ad-supported, “freemium” model adopted by Iconfactory and many other developers, may not survive this transition.

Tapbots, the developers of the popular Tweetbot client, announced today that they have pulled their Tweetbot alpha release for Mac, citing the new user token limitations. While exposure to a large number of users is undoubtedly good for testing and promotional purposes, they don’t anticipate it being worth the potential cost in “lost tokens.”

Matthew Panzarino of The Next Web reported on the Tweetbot news, taking care to emphasize that because user tokens don’t expire on any regular schedule, they can be used up even by users who download a client once, connect, and never launch the app again. The total number of oustanding user tokens doesn’t go down unless users log in to Twitter and explicitly revoke access to the client application.

During our conversation on Core Intuition, I pointed out that Twitter’s new policy runs the risk of invoking Apple’s ire, as well. Apple’s App Stores for Mac and iOS are host to dozens if not hundreds of Twitter API clients, many of which meet Twitter’s criteria for “traditional clients.” When a particular app reaches its 100K token limit, what happens to the user who purchases the app from Apple’s App Store a second later? I suppose it will be up to developers to anticipate their proximity to 100K, and start winding down the operation (and their business) by removing the app from the store, etc. But if they don’t? Apple’s just sold an app that, through no fault of theirs or the developers, is useless for connecting to the service it’s meant to support.

A Token Degree Of Control

It’s bad enough that clients will have to contend with a hard limit of 100K active users per application, but what must be particularly infuriating to developers is the knowledge that some of those 100K tokens may not have been used for years, and may never be used again.

The Tapbots announcement included an overt request that users of any Twitter clients should “help 3rd party developers out” and revoke any tokens that you’re not using. This underscores the doubly subservient position developers have been put in by this move: Twitter imposes a hard limit on the number of user tokens, only end-users can free up previously used tokens, and developers, helpless to address any of this on a meaningful level, are left to suffer the worst of the consequences.

At a minimum, Twitter should support developer-driven token expiration. Google, for example, supports an API endpoint for revoking OAuth 1.0 or 2.0 tokens. This gives developers the ability to improve the user’s experience when revoking a token makes most sense: e.g. if a user has opted to “Uninstall” an application. But it also provides some discretion and flexibility for the developer to revoke in other scenarios where it makes sense. A scenario such as the one Twitter is imposing, for example.

With the ability to programmatically revoke tokens, the particulars of doing so would be up to developers. For example, if I were the developer of a 3rd party client such as Twitterrific or Tweetbot, I might arrange for the client application to communicate token usage data to a centralized server. This would theoretically give me the ability to say “expire any user tokens that haven’t been used within the past year” and rest assured that I’ve freed up a bunch of tokens without inadvertenly inconveniencing an active user.

There are security issues at play here, and the unfortunate potential to seriously inconvenience an active user if a user token is revoked prematurely. But given the hard limits being imposed by Twitter, some hard coping mechanisms are due to developers. Tokens are precious, limited resource, and neither users nor developers can take them for granted any longer.