buzzbird

I spent a while today trying to get auto-complete of friend names working.  I tried several different mechanisms:

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.

Okay, so here’s the deal.

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.

By now you may have heard that Twitter will be disabling basic HTTP authentication on API calls on June 30, 2010.  Twitter even made a pithy countdown page for it.  After June 30th, all Twitter clients will need to use OAuth to continue making authenticated API calls.

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…

…I’m not sure what I’m supposed to use for the API URL? Apparently, the http://identi.ca/api root is broken.  So… what am I supposed to use instead?  Just for yucks, I tried http://identi.ca/api w/ wget at the command line.  Lo and behold, it doesn’t work, just as advertised.

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*

Version 0.7 of Buzzbird is now available!

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

A lot of people are seeing 401 authentication errors w/ Buzzbird right now… I’m not sure what the source is just yet, and I apologize profusely for the inconvenience! It’s not currently happening with the latest code in master, so it must be either something that was fixed between version 0.6 and the latest version, or something different about my credentials than everyone else’s (which isn’t as crazy as it sounds … developers get whitelisted so that the API limits don’t apply to us, so it’s possible that there’s some difference in API limiting that is causing the problem).

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!

I recently added the notification pane to preferences, and while I was in there, I spiffed up the Accounts pane a bit. Just a few more bug fixes, and I hope to start putting another release together. Thanks for your patience – work has been pretty busy lately and I haven’t had as much time to devote to Buzzbird as I’d like!

New Notifications Preference Pane

New Accounts Preference Pane

I just got back from a family vacation in San Diego, so there hasn’t been a lot of progress lately. However, I now have notifications working on all three platforms. I may need to make some more tweaks to the Mac flavor, but right now DMs and mentions get sent to Growl (Mac), libnotify (Linux) or a built-in firefox native alert (Windows). The hardest part was downloading the avatars to send to the notification, but that’s working too.

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 fixed a nagging bug last night w/ the friendship dialog. It turns out it was behaving differently based on whether you visited it from the “got to user” dialog, or if you clicked an avatar, or if you clicked a name. Fixed in master.

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…

…here’s what I’ve been up to lately:

Let me start by saying that, when I began writing Buzzbird, I did not know Javascript. At all. And I barely knew any CSS. By trade, I was what you might call a “back end” guy. I’ve tended to write yucky stuff like “enterprise solutions” that run in “containers” with “highly scalable frameworks” and bla bla bla ick.

Since then, my career has taken a bit of a different tack. I’ve started doing more front-end web stuff. So in addition to futzing around with the Buzzbird project, I’ve been exposed to the work of a lot of top-notch Javascript geniuses and CSS cowboys.

Now, when I look at Buzzbird’s source code, I’m kinda embarrassed. Seriously, don’t look at it. It’s repulsive. If you saw it, you might even consider installing an AIR app instead of using Buzzbird (okay, I’m kidding, I guess it’s not THAT bad).

So right now I’ve started “refactoring” … I’ve started by making a clean API for the Twitter stuff. In the long term, this should make it easier to add support for identi.ca, tumblr, and other social services that support APIs that are similar to Twitter’s. Supporting additional services has always been a pie-in-the-sky goal for this project, and it won’t be possible until I clean house with the service code.

And working on this non-sexy drudgery means that I haven’t yet gotten a chance to work on cool frequently-requested features like Lists or Notifications. But it’s coming, I promise. Stay tuned.

Tweet on.