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*

Originally I had planned on holding off until I had a chance to finish implementing lists. As it stands, lists are currently half-implemented in the back-end code, but I’ve disabled it from being usable in the UI. Unfortunately, recent changes to the Twitter API were causing version 0.6 to have “401 Unauthorized” errors when attempting to login. Obviously, having a working application is more important than squeezing one more feature in.

So here’s what’s new in Version 0.7:

• No more 401 errors.
• Notifications! You can now configure Buzzbird to notify you when mentions, DMs, or plain old tweets come in.  On Mac, the Growl framework is used.  On Linux, I’m using the notify-send utility that comes with libnotify.  Windows doesn’t really have a de-facto notification system, so I’m using the Mozilla notification system that comes with XULrunner on that platform.
• Issue 41: The Post button is now disabled when it should be.
• Issue 40: Implemented a pooling mechanism for XMLHttpRequests so the app won’t get constipated when network timeouts happen.
• Issue 32: Don’t truncate retweets at 140 characters in the post window – let the user decide how to truncate.
• Issue 31: Auto-close the post area after posting (this behavior is configurable)
• Issue 30: Added keyboard shortcut for “Post” action (accel + return)
• Issue 29: Focus should be on post area when user clicks Post button.
• Issue 7: Press Return to Post is now configurable.

Get it while it’s hot!  Link

I’ll keep y’all posted – and sorry again if this bug is affecting you!

UPDATE 5-APR-2010 1:34 UTC: I’ve reproduced the problem in v0.6, and it is indeed something that I’ve fixed in the latest code. Mulling over whether I should press on and try to get 0.7 released tomorrow, or try to back-port a fix to 0.6.

I’m still waiting to hear back from @twitterapi to confirm that I’ve identified the problem. Thanks again for your patience!

It’s still not configurable, so obviously I need to do that before I can bake up a new release. Perhaps some time next week?

Tweet on.

I also began experimenting with notifications on Mac. As always, I’m going to get it working on Mac first before I venture onto other platforms. Linux will likely be next. I might not even get to Windows before the next release. I’m not sure how I’m going to do Windows notifications yet… I’ll probably require WIndows users to install Growl, which is kind of a drag, but I can’t come up with a more “native” way to do it just yet. For all three OSes, I basically need a way to send a pop-up “toaster” notification from the command line.

Anyway – back to the salt mines! Tweet on…