When I released the first version of Ohai a few months ago, it had a simple goal – to have a simple, beautiful place to keep track of memories. As with all first versions, it was limited; you could only capture location-based check ins with a comment and a photo. And as it was released shortly after iOS 7’s announcement, it quickly looked outdated and needed some visual touch-ups. Today I’ve released the first new set of features for Ohai to make it a better and more beautiful journal, with some of the most heavily requested features.

About three years ago, I had a simple idea. I wanted an app to keep track of the places I’ve been. Naturally I’ve tried all the services for this, jumping from Gowalla to Foursquare to Path. But they all want you to broadcast your location, all the time. They’re focused on the experience of letting other people knowing where you are. There’s certainly value in sharing your location, but I wanted something that benefited me first.

I built a prototype of this app a few years ago, but it didn’t go anywhere. The secret sauce behind any check-in app is a database full of points of interest (or POIs, meaning places like businesses, restaurants, tourist attractions, etc.), and mine was no different. I didn’t want to rely on a free API of places that could evaporate at any time. Buying API access to one was prohibitively expensive. And shipping without one meant checking-in became a huge data entry process that was not fun. The project got shelved.

Then, a few months ago, my friends over at App.net announced a new API for finding POIs, and attaching metadata about places to posts and private messages. A few months before, they released an API for, among many other things, creating a private timeline of posts for individual accounts. I saw both a way to get a sustainable POIs database and cloud storage for check-in data.

And thus, Ohai was born.

At the last App.net hackathon, I unveiled Apparchy, a proxy server that converts your App.net timelines into data that looks like the Twitter API, which you could then connect to via Twitter’s official iOS apps to post and view to and from App.net. This was a really cool hack, but it suffered from many problems. It relied on a proxy server, which had issues relating to security and privacy, as well as being a single point of failure. If the proxy server went down, everyone’s app broke. Apparchy itself was built to work with Twitter’s official apps, which use a LOT of private methods on Twitter’s server API, and those private APIs changed often from release to release, meaning the app would break if you updated it. It was a big pain to set up, taking many steps that were easy to get wrong. But perhaps the most important and the most philosophical problem that plagued Apparchy was that the early adopter audience of App.net were not the kind of people who embraced Twitter’s official apps. They used Tweetbot or Twitterrific or some other app because it was better suited for their needs or looked better or some other reason.

Even with all these problems, it was fun and fascinating to make. Going into this weekend’s App.net hackathon, I wanted to top it. How? By building something that was just as mindblowingly cool, that also fixed all of those problems.

Since the last hackathon four or five months ago, App.net has been hustling on getting new APIs out, having added the Messaging API and the Files API, among other things. I’ve been dreaming for years of a better chat app with first-class, bulletproof file transfer support, and App.net has all the ingredients for a killer implementation. Similarly, for over a year, I’ve been sitting on the knowledge of the existence of the IMServicePlugIn framework, waiting for an opportunity to use it for something.

And thus, #ProjectAmy was born. App.net messaging integrated natively into Messages for the Mac.

When Twitter’s mobile apps were still Tweetie, they had a screen which let you change the API root. So if your API method is named 1/statuses/update.json, you add that to the end of the API root, giving you a URL that looks like https://api.twitter.com/1/statuses/update.json. If you change it to http://foo.com/bar/, then the API’s URL becomes http://foo.com/bar/1/statuses/update.json. You could use this if you were in a network where Twitter’s API was blocked, but you had a proxy server which wasn’t, you could still connect. Soon after, WordPress and Tumblr built versions of their API which supported the Twitter API, so you could use those services from within Tweetie. Then Twitter bought Tweetie and moved everyone to OAuth.

A couple weeks ago, I noticed that this was still present in Twitter’s official apps. I’ve been a big fan of App.net since it came out, whose API is different than Twitter’s, but not terribly so. I thought it might be interesting to try to build an “API translator” which pulled the App.net streams and posts into the Twitter app. The team behind App.net had a hackathon this weekend, and I had my project.

Today I shipped the first alpha of Apparchy, which turns Twitter’s official iOS apps into App.net clients. You sign up for a free account on apparchy.net, add your app.net account, and then log into the Twitter app with your Apparchy username and password. Then, the Twitter app will start loading data from app.net through the Apparchy API. You can view your stream, your mentions, your profile, your followers, and your friends, as well as post, reply, star, and repost. It’s not entirely complete, and some parts of the app will have no data or return nothing, but the core experience is pretty good.

Apparchy implements Twitter’s OAuth security, and sends all data over HTTPS, so the process is as secure as any other call through Twitter. Apparchy doesn’t touch the Twitter API at all, and so it’s not bound by any of Twitter’s terms of service, should they be applicable. The only way this will get shut down is if Twitter removes the ability to change the API root in an update to their app (which doesn’t sound likely, from what I’ve heard).

Apparchy is what is possible when you have open APIs like App.net’s and standards for how to handle server communication. It took a lot of research and trial/error to get it to work, but it works very well. I had a blast building this, and hope that it can be used for a long time. If you have an App.net account, give it a try for free at Apparchy.net.