Yesterday, Twitter, Inc. announced that they were making changes to their authentication logic. The short story is, third-party Twitter clients (i.e., those not written by Twitter, Inc) will now need to send users through a web browser to authenticate if they want to have read access to direct messages.

I was going to post a reaction to this, but the author of Kiwi expressed my feelings so perfectly, I’m just going to link to them here:

http://yourhead.tumblr.com/post/5550105265/i-love-you-kiwi-i-know

I threaten to quit working on Buzzbird every other month. Every time I do, I’m encouraged by how many people turn out on the blog and ask me not to, because they actually like my little client. I’m glad it was useful to folks.

Like Isaiah (the Kiwi dude), I wrote Buzzbird for fun and never had any anticipation to make money on the thing. I did it primarily as a way to teach myself Javascript – a language that I wanted to get a lot better at. Now, it’s fulfilled that goal.

If anyone else wants to fork the repo and start their own build of Buzzbird – have at it. That’s the beauty of open source. It’s under the MIT license, so you can basically do whatever you want with it. Maybe someone will be ambitious and write the OAuth authentication piece – it shouldn’t be that hard, as XUL is already a quasi web-browser. But I don’t have the time or energy to turn on a dime and rewrite stuff every time Twitter decides to make a non backward compatible change that hurts the third party clients that they’d be content to not have around.

If you’re looking for a decent FOSS client to replace Buzzbird, I recommend Spaz. The guy in charge of the project is really cool, and he’s dedicated to open source. Yeah, it’s written in Adobe AIR (*shudder*). But I think Ed Finkler (a.k.a. funkatron, the aforementioned guy in charge of Spaz) has plans to re-implement it in other platforms (perhaps Titanium Desktop?). Another bonus is that Spaz doesn’t treat Identi.ca like a second-class citizen. So if open source is your thing, check Spaz out.

Hey all, I’d like to give you an update about the state of the Twitter Platform and hopefully provide some much requested guidance.

Since this time last year, Twitter use has skyrocketed.  We’ve grown from 48 million to 140 million tweets a day and we’re registering new accounts at an all-time record.  This massive base of users, publishers, and businesses is a giant playground for developers to build their own businesses on, and this means the opportunity has grown for everyone.

With more people joining Twitter and accessing the service in multiple ways, a consistent user experience is more crucial than ever.  As we talked about last April, this was our motivation for buying Tweetie and developing our own official iPhone app.  It is the reason why we have developed official apps for the Mac, iPad, Android and Windows Phone, and worked with RIM on their Twitter for Blackberry app. As a result, the top five ways that people access Twitter are official Twitter apps.

Still, our user research shows that consumers continue to be confused by the different ways that a fractured landscape of third-party Twitter clients display tweets and let users interact with core Twitter functions.  For example, people get confused by websites or clients that display tweets in a way that doesn’t follow our design guidelines, or when services put their own verbs on tweets instead of the ones used on Twitter.  Similarly, a number of third-party consumer clients use their own versions of suggested users, trends, and other data streams, confusing users in our network even more.  Users should be able to view, retweet, and reply to @nytimes’ tweets the same way; see the same profile information about @whitehouse; and be able to join in the discussion around the same trending topics as everyone else across Twitter.

A Consistent User Experience

Twitter is a network, and its network effects are driven by users seeing and contributing to the network’s conversations.  We need to ensure users can interact with Twitter the same way everywhere.  Specifically:

• The mainstream consumer client experience.  Twitter will provide the primary mainstream consumer client experience on phones, computers, and other devices by which millions of people access Twitter content (tweets, trends, profiles, etc.), and send tweets.  If there are too many ways to use Twitter that are inconsistent with one another, we risk diffusing the user experience.  In addition, a number of client applications have repeatedly violated Twitter’s Terms of Service, including our user privacy policy.  This demonstrates the risks associated with outsourcing the Twitter user experience to third parties.  Twitter has to revoke literally hundreds of API tokens / apps a week as part of our trust and safety efforts, in order to protect the user experience on our platform.
• Display of tweets in 3rd-party services. We need to ensure that tweets, and tweet actions, are rendered in a consistent way so that people have the same experience with tweets no matter where they are.   For example, some developers display “comment”, “like”, or other terms with tweets instead of  “follow, favorite, retweet, reply” – thus changing the core functions of a tweet.

With this in mind, we’ve updated our Terms of Service: http://dev.twitter.com/pages/api_terms.

The Opportunity for Developers

Developers have told us that they’d like more guidance from us about the best opportunities to build on Twitter.  More specifically, developers ask us if they should build client apps that mimic or reproduce the mainstream Twitter consumer client experience.  The answer is no. (emphasis added)

If you are an existing developer of client apps, you can continue to serve your user base, but we will be holding you to high standards to ensure you do not violate users’ privacy, that you provide consistency in the user experience, and that you rigorously adhere to all areas of our Terms of Service.  We have spoken with the major client applications in the Twitter ecosystem about these needs on an ongoing basis, and will continue to ensure a high bar is maintained.

As we point out above, we need to move to a less fragmented world, where every user can experience Twitter in a consistent way.  This is already happening organically – the number and market share of consumer client apps that are not owned or operated by Twitter has been shrinking.  According to our data, 90% of active Twitter users use official Twitter apps on a monthly basis.

In contrast, the number of successful applications and companies in the Twitter ecosystem that focus on areas outside of the mainstream consumer client experience has grown quickly, and this is a trend we want to continue to support and help grow.  Twitter will always be a platform on which a smart developer with a great idea and some cool technology can build a great company of his or her own.  And, with record user growth, there has never been a better time to build into Twitter.

Some key areas where ecosystem developers are thriving:

• Publisher tools.  Companies such as SocialFlow help publishers optimize how they use Twitter, leading to increased user engagement and the production of the right tweet at the right time.
• Curation.  Mass Relevance and Sulia provide services for large media brands to select, display, and stream the most interesting and relevant tweets for a breaking news story, topic or event.
• Realtime data signals.  Hundreds of companies use real-time Twitter data as an input into ranking, ad targeting, or other aspects of enhancing their own core products.  Klout is an example of a company which has taken this to the next level by using Twitter data to generate reputation scores for individuals.  Similarly, Gnip syndicates Twitter data for licensing by third parties who want to use our real-time corpus for numerous applications (everything from hedge funds to ranking scores).
• Social CRM, entreprise clients, and brand insights.  Companies such as HootSuite, CoTweet, Radian6, Seesmic, and Crimson Hexagon help brands, enterprises, and media companies tap into the zeitgeist about their brands on Twitter, and manage relationships with their consumers using Twitter as a medium for interaction.
• Value-added content and vertical experiences.  Emerging services like Formspring, Foursquare, Instagram, and Quora have built into Twitter by allowing users to share unique and valuable content to their followers, while, in exchange, the services get broader reach, user acquisition, and traffic.

A lot of Twitter’s success is attributable to a diverse ecosystem of more than 750,000 registered apps.  We will continue to support this innovation.  We are excited to be working with our developer community to create a consistent and innovative experience for the many millions of users who have come to depend on Twitter every day.

As always, we welcome your feedback and questions.

Best, Ryan

@rsarver

So, that’s it then. Twitter grew and thrived in a flourishing ecosystem that encouraged active, open development. Hundreds of competing client apps were created to support the platform. Somehow this undesirable “inconsistent user experience” managed to shepherd in a new era of microblogging. But now Twitter doesn’t want us anymore.

And suddenly I really don’t feel like working on Buzzbird.

Basically, Windows is a nuisance and I’m barely able to keep up with Buzzbird as it is, so I’m killing it to keep my sanity. If there’s a Windows user out there who wants to check the source out from git and make a package, go nuts! I’ll post it on the site if you want.

OK, so the good news: I couldn’t totally leave Buzzbird broken and bruised. There aren’t many features in this release, but I did fix the issue w/ the 53 bit Javascript integer ID overflow – what this means is, retweets and clicking on replies should behave a lot more normally and a lot less randomly.

I also added filters for Paper.li (The ____ Daily is out!), and GetGlue.com (‘cuz I really don’t give a crap what you’re watching on TV). And I fixed that nagging bug where Buzzbird was truncating native retweets and didn’t need to be.

An intrepid Buzzbird user, PotHix, was awesome enough to contribute a .deb building process for people on a Debian variant in Linuxland, but unfortunately I’m too much of a putz to figure out how to make it work. I sent him a tweet to ask him help me out, hopefully he sees it and we can have a nice deb for you.

You can snag version 0.9 on the Downloads page.

Happy tweeting! Or ‘denting! Or whatever it is you do!

Anyway, I know about the problem. I might have a fix eventually – or if you have one, submit a patch.

I did this project for a few reasons. First, I didn’t like the Adobe AIR clients. I didn’t like having to install a separate runtime, and I didn’t like how “foreign” the apps always looked on my desktop (I’m a Mac user, and I think Mac people tend to be fussier about this than others). When I started out, incredible as this might sound, there were actually very few desktop clients. There was Twhirl and Tweetdeck, and Seemic didn’t even really exist yet. I thought I could build my own cross-platform app that didn’t need AIR.

I also did it to learn Javascript. I’m a server-side web developer by trade, and wanted to do more client side stuff, but my lack of familiarity w/ Javascript held me back a bit. XUL + Javascript + Cross-Platform Twitter Client seemed like a perfect match for me!

Since I started, I’ve come a long way learning Javascript. There are lots of clients to choose from now. I’ve done pretty much all I can with it, and maintaining it is more of a chore for me now than a labor of love.

I’m proud of how it turned out. There are plenty of Twitter clients out there with more features than Buzzbird, but it holds its own and does just about everything I need. I’m surprised by how many Linux users there are – I used to be a Linux-on-the-desktop guy, so that makes me happy. I was also surprised by the number of people out there running OSX 10.3 and earlier who have few other choices than Buzzbird.

So, I’m sorta calling it quits. I say “sorta,” because I know I won’t be able to put it down entirely. There are still tiny tweaks I’ve made in master that aren’t in a general release, and there are a couple of bugfixes that I’ll feel guilty about if I don’t try to correct them, but I wouldn’t expect much more from me with Buzzbird. I’m happy with what it is today. I hope you are too.

And, it’s 100%, MIT-license, unadulterated open source. Feel free to fork it in Github if you want to keep it going yourself.

New Features

• Support for identi.ca
• Support for OAuth/xAuth authentication on Twitter.
• New Feature that allows you to filter tweets by service.  Hate Foursquare and Blip.fm updates?  Filter ‘em out!
• Support for web proxy servers.
• Indicator for protected updates.
• Indicator/link on updates that provide location information.
• Separate Quote and Retweet actions – now you can decide on a case-by-case basis whether you want to do a “native” re-tweet, or just quote someone else’s update.
• Reduced the amount of data that is stored in the DOM, which should improve performance a bit when switching between home timeline/mentions/direct messages.
• Newer, slightly-more-attractive action buttons.
• Moved the character counter to be closer to the tweet authoring section.

Bug Fixes

• Buzzbird will no longer display the direct message action button for users that do not follow you.
• Buzzbird will no longer display the retweet action button for users that have protected their updates.
• Mentions by people who you do not follow will now show up in your home timeline.
• Fixed a bug that causes the quote and reply button to not always work when viewing conversations or single-user timelines.

Visit the download page to get it while it’s hot.

1. I added jQuery to Buzzbird, and tried to use it on XUL documents directly.  I hoped that XUL and HTML were similar enough that I’d be able to use a jQuery autocomplete plugin to do the autocompletion, but had no luck. I patched up jQuery a bit, and tried out two different plugins, but ran into too many roadblocks to ever make it work.
2. XUL has auto-complete text fields, so I tried using one, along with a custom component that allowed me to populate the valid auto-completions programatically.  Unfortunately, the XUL widgets that support built-in autocompletion do not support multi-line entry with word-wrap, so even though I managed to get the completion drop-down list to work, it’s not a viable solution.
3. I tried making my own popup using XUL popup menu elements, and I made the popup appear when the user hit the @ sign while typing.  Unfortunately, XUL popup menus appear to be modal, and forcing the user to choose from a list when a list item may not even be applicable won’t work

I did manage to get the Twitter API call to fetch all your friends’ screen names working, but because I can’t get the UI to do what I want, it’s kinda useless right now.  I’m pretty bummed and frustrated.  I’ll probably have to release 0.8 without this feature.

I might be able to build in a sort-of “address book” feature that a user could bring up if they forget the name of a friend, but that falls short of my original goal of username completion by quite a bit.

OAuth sucks. Why does it suck? Because it was not designed for desktop applications. It was definitely not designed for open source desktop applications.  What do I mean by that?

Suck.

One of the things that OAuth tries to do is verify that the application requesting access to Twitter really is the application that it says it is.  This is a good thing – e.g., if you give Buzzbird permission to access your timeline, then you don’t want some malicious application pretending to be Buzzbird accessing your data in Buzzbird’s name.  That would suck. It would suck for you (the user whose trust was betrayed), and it would suck for me, because Twitter could mistakenly think Buzzbird is being malicious.

How does OAuth ensure that an application is really Buzzbird, and not some impostor?  Well, the application making the API calls has a “shared secret” that is assigned to it by Twitter.  The application stores this secret, and sends it along with every request to Twitter (this isn’t exactly what it does, but you can think of it that way).

That’s the crux of the problem.

The secret is embedded in the application.  This works just fine for web-based applications where (hopefully) a copy of the application doesn’t end up in the wild, but when you’ve got an app sitting who-knows-where on who-knows-what machine, it breaks down.  For open source apps, it’s obvious – if you grab the source code from github you can see the application key.  Okay, so let’s say you don’t put the key in the source repo.  Well, in Buzzbird’s case, the application is distributed as a bunch of plaintext javascript files.  You can easily read through them and find the key.

This is pretty much the worst place to keep your keys (CC Image Courtesy woodlywonderworks)

Okay, so what about compiled files? Well, any semi-competent hacker wannabe can run the strings command on your binary and probably find your key.  If not, if you relish the tedium, you might be able to tease it out by dumping the image in a hex editor.

Even the most astute of developers who try to hide the key in the binary, by whatever clever means they have at their disposal, will still leave behind a trace of their key in the app. It will be on the potential hacker’s computer, and he has plenty of free time to find it.  There’s no way around it, OAuth is flawed when it comes to desktop applications.

OAuth isn't clever enough to stop this malicious application.

Buzzbird Status

Regardless, I’ve implemented OAuth in Buzzbird (well, actually I implemented Twitter’s browser-free version of OAuth called xAuth, which is even sillier for its own reasons that I won’t get into here).

As you can imagine, a few programmers are griping on the Twitter developer group about OAuth’s shortcomings.  Lo and behold, Twitter has announced that it has a solution to plug this hole, and that they will reveal this solution “soon.”

Twitter has even been kind enough to delay the cutoff time after which OAuth would be the only permitted authentication mechanism.

Meanwhile, I’ve got a new version of Buzzbird kinda-sorta ready, and it has Proxy support and identi.ca support.  Unfortunately, I’m sitting on it while I wait for Twitter to share their latest idea on how to fix this. Hopefully whatever they announce won’t take me a few weeks to implement, like OAuth did.

I’ll keep you posted.

I like to refer to this date as the Oauthpocalypse.  Or even “Opocalypse”.

Rest assured, Buzzbird will be prepared to do battle on the side of good during the end times of basic authentication.  I have a vision (a “revelation,” if you will) of the souls of Twitter clients being expelled from the kingdom of Twitterdom.  They were cast asunder for callously hoarding the credentials of righteous users.  Yet I don’t judge (lest I be judged), for I too was a wayward spirit.  But I have seen the virtuous path.  Yea, I have seen the promised land, and brothers and sisters, that promised land is OAuth.

Now if only I had some icons that didn’t look like they were chiseled on stone tablets…

Ultimately I’d love to be able to support all kinds of status.net services, but I think it makes the most sense for identi.ca to be the first.  Can anyone help me out here?  What’s a working root of the API URL for identi.ca?

I suppose if I were feeling really ambitious I could look at the source for Gwibber. *sigh*