Last week, Shawn Blanc started a trend called Blast from the Past Link Day. That was on the 20th, so I'm pretty late to the game on this one. Nonetheless, it seems like the perfect excuse to make a post while I bide my time waiting for more circuit boards from BatchPCB.

Here are a few of my favorite posts from deep darc, in chronological order:

• Trip Report AKA: The Tick
• Making the Voria Logo
• Bad eBay Experience he called me 'Meh'
• ^_^ post about meeting my future wife
• Goodbye Legacy IM follow up post: Full Time Jabber
• Stowaway a story about a kitten
• Thoughts on Prius Acceleration
• Hacking Christmas Lights crowd favorite

Here are some posts related to projects that I am proud of:

• Synfig Developer Preview Announcement open-sourcing my baby
• Teredo for MacOS X a small utility to make it easier to use Miredo on MacOS X
• ybox2 the second electronic device I designed

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

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.

From the Android SDK M5 API Changes Overview, Dave Cridland pointed out the following:

The com.google.android.xmppService package has been replaced by the com.google.android.gtalkservice package. This is driven by the fact that the GTalk API is not XMPP compliant, and will be less so going forward. The reason is that XMPP is too verbose and inefficient for mobile network connection, and the GTalk API will be moving to a binary encoding for the protocol between the client and the server.

I'll enumerate the implications and conclusions:

1. XMPP is verbose.
2. XMPP is inefficient for mobile networking.
3. A proprietary binary protocol would be more efficient for mobile devices.
4. The former Android xmppService API will diverge away from XMPP.

I think that this direction is unfortunate, and the reasons misguided. Read on, and I'll elaborate...

NOTE: This post seems to no longer be fully inline with my current position—which is that a new (as of yet undefined) UDP-based C2S protocol using EXI would be best suited for mobile devices. Such a thing would however still be XMPP. Edited 2009-07-13.

NOTE: Most of the issues pointed out in this post have been addressed and corrected. Thus, this post remains available for historical reasons.

I don't want to seem unappreciative, so I'll start out with some good points. Google Talk has energized Jabber/XMPP to a level of activity that is unprecedented. Think about all of the things that have happened since Google Talk went beta: how much of it is a direct or indirect result of Google choosing to use XMPP as the protocol for their IM service? I don't want to minimize this point. Google Talk has been one of the best things to happen to the Jabber community in recent memory. And kudos to them.

Ever since Google Talk flipped the switch to enable server-to-server communications, Google Talk has become my default recommendation for anyone looking to get a ‘jabber account’. Back then, jabber.org was still having stability problems (as it was still running jabberd 1.4), and my own server was also less than reliable. Google Talk also came with several useful features, such as the chat client built right into gmail.

However, I have recently realized that Google Talk is not the ideal, stable jabber server that I thought it would be. Read on to find out why.

UPDATE: (2006-11-01) Google Talk now supports offline message delivery!

Ok, ok... I know this isn't new... But it's new to me. It would seem that Livejournal now runs their own Jabber server!

LJ Talk is what they call it, and they apparently have big plans—all of them revolving around interoperability and freedom of choice.

There are many Jabber clients out there for just about every platform imaginable. This is often cited as one of the strengths of Jabber, but it does have serious drawbacks; namely end-user confusion and (for open-source projects)duplicated developer effort. I'm starting to think that the approach that nearly all Jabber clients take is sub-optimal.