I own a 2003 Toyota Prius, and it is the best car I have ever owned. The only car I want more than my current Prius is the 2010 model. And, yes, I have even experienced the "sudden unintentional acceleration" issue several years ago that so many people are up in arms about these days. Why am I still a loyal Toyota fan?

It was quite startling not having the gas petal bounce back to my foot after pressing down on it hard, but I survived because I am familiar enough with my car to know how to put it into neutral. At highway speeds the Prius requires you to hold it to neutral for a full half-second to engage. I was able to stop the car and figure out what happened.

I was quite excited last Wednesday to discover that Facebook has finally delivered on their promise of exposing an XMPP client interface to their integrated chat system. After the initial euphoria wore off, I started to realize that there is still a lot of work to be done.

In terms of duplicating the chat experience that already exists via the Facebook website, the XMPP implementation they have set up does a wonderfully adequate job.

The problem is that the XMPP interface to Facebook Chat is really only a gateway. It is similar in concept to how XMPP transports allow you to use closed IM networks via XMPP, except they are exposing a client interface (C2S) instead of a server interface (S2S). While this approach is adequate for simple chat, it means that the only features supported are features that already exist in Facebook chat—which is pretty much bare bones chat.

I was just able to connect to chat.facebook.com using an XMPP client with username and password.

When I logged into all of my accounts this morning, I was greeted with a message from chat.facebook.com: "You were marked as Online because you signed on with Jabber."

UPDATE: Official Announcement: Facebook Chat Now Available Everywhere

UPDATE: Added some commentary on Integrating with Facebook Chat

With less than 10% of IPv4 addresses remaining unallocated, IPv6 has been getting a lot of attention lately. As such, hardware vendors and ISPs (like Comcast) are now starting to figure out how best to deploy IPv6 connectivity to residential customers.

IPv6 would effectively make the use of IP masquerading (A form of Network Address Translaton used in practically all residential gateway routers) unnecessary. Unfortunately, the current ubiquity of IP masquerading has caused vendors and ISPs to be suspicious of allowing proper end-to-end connectivity to residential customers. I have even heard that some are even considering using the same IP masquerading mechanism for IPv6—for security reasons!

This would be a very bad thing for the future of the IPv6 internet, so I wanted to elaborate on the motivations people have for doing this and ways that it can be avoided altogether.

I just learned that m0n0wall now supports IPv6, which is great news. Lack of IPv6 support is actually why I stopped using m0n0wall years ago. Since that time I've come to miss it dearly. Now that my only gripe has been addressed, I might consider giving it another try.

In case you are wondering just what m0n0wall is, here is an excerpt from their website:

m0n0wall is a project aimed at creating a complete, embedded firewall software package that, when used together with an embedded PC, provides all the important features of commercial firewall boxes (including ease of use) at a fraction of the price (free software).

If you need a router and have a spare machine, give m0n0wall a try.

Here are a few teaser pictures from my next hacking project.

This is where I list some of the cool and interesting projects I've been actively involved in. My current professional projects may or may not be listed. I also have many smaller projects/hacks that I haven't listed yet.

Why can't sending an event invitation to someone be as easy as sending an email? Why can't I check a friend's availability if they aren't using the same calendar server? Why can't I share a calendar with my friends who don't have an account on my calendar server?

For some reason or another, the concept of Calendar Servers has captured my imagination over the past year or so. I believe this technology could change how people think of time management, but I think it needs three things before it can get to that point:

1. Ability to invite someone to an event who is using a different calendar server.
2. Ability to view availability of someone who is using a different calendar server. (And, as a corollary, the ability to control who can see your availability)
3. Ability to share calendars and events with people who don't have an account on my calendar server.

The key to make all of this possible is something I call Automatic Federation.

UPDATE: After writing this post, individuals have brought to my attention RFC-2446, RFC-2447, and the iSCHEDULE Technical Committee. At first glance, it looks like this may make the stuff I was proposing here somewhat irrelevant, but some investigation is still warranted. I'm not yet sure how these specs prevent abusive things like spoofing and who is allowed to see free-busy information.