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.