I created an account on Mastodon.social, you can find me on @stevestreza@mastodon.social. If you’re into that sort of thing, you can follow me over there.

Eventually I hope to create an ActivityPub setup that can publish directly to my own site and the Mastodon network. But until then, this is good enough. Between Twitter’s ongoing moral cowardice and their ongoing hostility towards the developers that made them what they are, I can’t continue siloing my data there.

But Mastodon is so far revealing itself to be much more pleasant than Twitter, and it has some interesting forward-thinking decisions that I’ll talk more about later. In the meantime, go find me on there. You can sign up on the instance I use, Mastodon.social, or you can sign up at any number of other instances, such as those found on instances.social or joinmastodon.org. Even if you sign up on a different instance, just search for my handle @stevestreza@mastodon.social and it should work just fine.

Link

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

Twitter recently introduced a feature on its website called “Who To Follow”. This feature presents you with a list of people you aren’t following already, but who are active in your social graph. However, I happen to be very proactive in finding new people to follow through a variety of means, and have no need for Twitter to point it out to me. I thought it was a bit obnoxious to see, especially considering both of my first recommendations were people I had blocked.

This Safari extension removes that box from the Twitter homepage, whether you have it turned on for you or not. It’s a simple CSS stylesheet that sets display:none on that box. You’ll never have to see it again.

You can download it here. I’m still a bit new at Safari extensions, but it should auto-update in the future if I ever release an update.

Update 9/18/2010: Follow Freely 1.1 has been released, with support for the new Twitter web client. It also fixes the issue where Safari would constantly say there was an update available.

Link

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

Twitter uses OAuth as its supported form of authentication. This is fine for some apps like clients where users need to authenticate themselves, but it doesn’t work well for bots or scripts run by one person. If the bot needs an access token, it can be a real pain to obtain without writing the intermediate code.

This application, OAuthery, serves a simple purpose. You supply it the consumer key and secret for your OAuth application. It creates a request token and the URL for authorizing it. You complete the authorization in a web browser and get a PIN number. You then enter that PIN number back into the application, and it spits out your access key and secret. At this point, the user authentication is complete, and you can add those credentials to your script, and access API resources.

This is largely intended as a developer tool for people developing applications with Twitter’s OAuth impelmentation. It also provides code to show exactly how to perform the authentication process with OAuth and Twitter, so that developers who wish to implement such functionality in their own apps can use this as reference.

Link