Thoughts on Facebook Chat

Monday, February 15, 2010 by darco
Posted in ,

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.

Features

Here is a list of what is supported via the XMPP interface:

  • Logging in (DIGEST-MD5 or X-FACEBOOK-PLATFORM)
  • Downloading the roster
  • Sending basic instant messages to other people on your roster
  • Marking yourself as idle (via the presence show setting of "away")
  • Viewing other user's profile picture via the vcard-temp mechanism
  • Typing notifications

Notable things NOT supported:

  • Marking yourself as anything other than "available" or "idle"
  • Setting a status message with your presence
  • Federation with other XMPP services, such as Google Talk
  • Adding, removing, or reorganizing people on your roster
  • Obtaining information other than name and avatar from other user's vCards
  • Logging in via XMPP with more than once device at a time
  • Sending anything other than a <message> stanza with a <body> element (or a chat state element) to another user. Which means...
    • No file transfer
    • No Audio/Video chat (via Jingle or otherwise)
    • No rich-text messages
    • No whiteboards

JIDs

A while back Facebook added support for usernames. The official reason was to simplify the look of your Facebook URL, but at the time I hypothesized that a possible additional motivation would be for XMPP support. After all, who wants to have a roster full of numbers? I was imagining something like this:

darco@facebook.com

This is not what happened. Facebook chat JIDs are cryptic:

u87502869245@chat.facebook.com

Having JIDs which are so human-unfriendly is, to say the least, unfortunate. It makes them nearly impossible to remember as well as difficult to quickly identify. However, if you are using an XMPP client which makes heavy use of the "name" roster item attribute you will be mostly insulated from this ugly truth.

I am also disappointed that they chose the "chat.facebook.com" domain instead of simply "facebook.com". It harkens back to the days when people's email addresses were "username@mail.example.com"—it's unnecessarily verbose, and it implies that the only thing the connection could ever be used for is chat.

Roster

The roster exposed in Facebook chat is entirely managed automatically. Your Facebook friend groups are exposed, but only the ones which you have exposed for chat. Despite this, the roster contains every one of your friends. Friends which are not on one of the friend groups you have enabled for chat will appear as not belonging to any group. Roster versioning support appears to not be implemented. Combine this with the fact that there is no stream-level compression (either via TLS or actual XML stream compression), some users may notice a significant delay when they log in as their rosters are fetched.

I am really disappointed that you cannot add, remove, or organize users in your roster. Dragging users around in iChat is so much easier than manipulating your groups via the Facebook website, and the XMPP presence subscription model seems like such a natural fit with the Facebook friend 'invite/accept' model.

Preventing your friend list from being modified in this way may actually be due to security considerations. Facebook apps can actually use the XMPP connection if you give them permission to, and perhaps enabling roster manipulation would be giving a bit too much power to Facebook apps. This could be easily remedied by adding additional permissions or simply disallowing roster manipulation if the client authenticated via X-FACEBOOK-PLATFORM.

Hope

Overall, while I am a bit underwhelmed, I think this is a great first step. All of the problems that I've described are far from fatal, and most can be fixed over time.