Every few weeks, some tech company is in the fire over changes to their rules. This week it’s Instagram, but who knows who it’ll be next week. They put out some change to their terms of service that claims new or changed rights over what they can do, someone notices, bloggers and headline-hungry tech reporters find it, and suddenly we have us a news cycle. In 2012, the truth is not the actual truth, but that which is tweetable. People circulate headlines speculating on what the new terms mean, a few rounds of telephone go by at the speed of light, and pretty soon the company in question is the most evil entity on earth for the next two or three days.

This nuclear chain reaction cascades, and eventually people get mad; so mad, they decide to pull off a move that could never have existed in the pre-Internet era: the ragequit. A ragequit consists of three parts – backing up your account data (usually), deleting your account, and then talking very loudly about it on social media. Usually this decision is made within hours of the change going viral public. Its intent is to send a message that says that these changes are not OK, and if you’re going to make them, I’ll just take my ball and go home, so you should fix them.

In a way, the ragequit is fascinating to observe in human nature. In just a few hours, someone can go from ignorance to apathy to fear to anger, and let this rush of emotions dictate a permanent decision. We’ve now moved to a point where software is so disposable that we will spend months and years putting our life into it and throw it away at the first sign of perceived injustice against ourselves. It’s equally curious how people think a few scattered deleted accounts will end up persuading the company to see the error in their ways, as opposed to all the monstrous bad press being simultaneously thrown at them.

One of the most infamous incidents of the ragequit happened in 2010 when Facebook announced a number of changes to their privacy options and policies. As with all things Facebook and privacy (hence Instagram and privacy), people got mad and deleted their accounts en masse. Did it work? Well, no. Facebook didn’t even bother to dignify the effort with a response. They likely picked up more new users that day than they lost from ragequitters. That was two and a half years ago, and it’s not like Facebook’s privacy controls have gotten any better. The whole thing was a futile effort that made some people feel good, and effected no change.

Nobody has ever been called noble or admirable for knee-jerk removing part of their online presence. Those who do it are never celebrated for it beyond the moment, and many times end up crawling back, tail between the legs, and resuming their use of the service. So remember, if you’re thinking of pulling off the ragequit, it probably won’t do anything but make you feel better in the moment. The company might end up backpedaling, the story ends, and suddenly you’re looking for a new photo-sharing app.

And yes, I am entirely guilty of the ragequit in the past.

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.

Two years ago, I began working on a new Twitter client for iPhone, named Streamlines. I hinted at it about a year ago, and has been a driving force in my development of MGTwitterEngine and a ton of open source projects. I’ve come to the conclusion that I won’t have time to finish and release it, as there’s still probably another 6 months of development needed to really ship it, and hostility from Twitter and from users of other Twitter clients make effort into building one unsustainable. However, I think there are UI concepts in there which are totally unique and have never been seen before, so I’d like to share them with you before this project is lost to the annals of dead projects.

Read More

For a little less than a year, I’ve been writing code built atop Twitter, specifically Matt Gemmell’s MGTwitterEngine. I’ve got a few things running on this code, which I’ve not talked about publicly (other than minor hints on Twitter), but have been well-received by the few people who have seen it. Still, these projects have needed to extend both MGTwitterEngine and related libraries to add functionality or fix bugs. I’ll spend this blog post documenting some of those changes across the different projects.

Read MoreLink