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.

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.

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.

A while back a friend of mine mentioned that for programmers starting to learn Objective-C often have difficulty fully understanding how Objective-C handles memory management. Objective-C memory management isn't really all that difficult once you get the gist of it, but it can be confusing at first.

This short article covers the basics of the normal reference-counted Objective-C runtime. Garbage collection can wait for another day.

I participated in the Give-1 Get-1 program last month, and a few weeks ago I got my shiny new OLPC XO-1 laptop. I took a picture of myself using the built-in camera. As you can see, my cat Zahki never misses a photo-op.

After playing around with it for a few days, I have come to a few conclusions about the device. And, for my own amusement, I'm making this post entirely from my XO-1.

I've learned quite a bit over the past year or so that I've been developing darcness, but one lesson stands out above all others: It is just staggering how many ways there are to compromise the security of a dynamic website.

Making a website secure is a surprisingly non-trivial task that requires plenty of thought and discipline. What makes it worse is that it is all too easy to create gaping security holes without realizing it.

A few months ago I made a post telling the world that as of my birthday of this year I would no longer be using AOL Instant Messenger, MSN Messenger, Yahoo Messenger, or ICQ—and use federated IM services (Specifically those using the Jabber protocol) exclusively. Well, guess what: Today's my birthday.

For those of you who are still confused as to what exactly Jabber is, read on and I'll break it down for you one more time.