I’m writing this just before heading into f8 ’08 (the Facebook Platform conference). Normally, I’m content to just sit back and analyze things and recommend how to adapt. But today, I think I know what’s going on (based on my recent work at Ringside Networks trying to integrate an external web site into our own platform). In the interest of being clear, I do NOT have any form of “insider” information. This opinion is based totally on my own work and the work of the Ringside team. Also, I’m trying a new format with sections, which is discouraged by the WordPress UI, but I have a lot to say today!

APIs and Clients

An important part of the social Web is the fact that applications can call APIs on social services like Facebook and one of the many OpenSocial social networks. If you have an existing property, you build an application that can be used in the context of the social network. This doesn’t necessarily mean that the application runs inside the social network (REST APIs allow a stand-alone application to play), but important parts of the context, like authentication, belong totally to the social network. There are two inefficiencies with this model:

  1. A web site is not necessarily an application, and it might just want access to the user profile services, and
  2. A successful web site with an existing user community probably already knows how to authenticate users and do interesting things with that identity

Users as Services

Lots of folks are probably now thinking, “sounds like OpenID” (okay, I’m assuming a lot about my readership, but bear with me). OpenID is great for letting users really take ownership of how they are authenticated. It’s taken me a while to be a believer, and, well, I’m not fully converted yet, but it is pretty cool. The problem with OpenID as it is today is that it isn’t as valuable as a Facebook login (yet). An OpenID lets a user of your web site or application confirm they are who they say they are. So what? That tiny bit of information is basically just an identifier that you can now use to store information. It doesn’t spawn a dialogue with the user, which is kind of the whole point of being social, isn’t it?

The real value of a Facebook user is that ample set of APIs that the application (or web site, once Facebook Connect launches, I’m pretty sure) has to communicate with the user and to enable them to bring their friends along for the ride. An authenticated Facebook user is a lot more valuable in this case than the equivalent, say, authenticated WordPress user. Technologies such as OAuth, OpenID, and XRDS (big parts of the DiSo project) will dramatically improve things, given time. The point I’m trying to make is that, from the perspective of the application (or web site) operator, the User is a set of services used to communicate in different ways with that User and with that User’s friends (insert your own privacy disclaimer here; I don’t have one handy).

Prediction Time

Here is my prediction for Facebook Connect: In the same way that Pages were introduced to have something just like a User, but without all the User “baggage” (like an identity, etc.), with additional features (like delegated authority to update the “profile”), and with modified features (Fans instead of Friends), I predict that Facebook Connect will enable Sites to connect to their APIs in the same way that Applications connect today, but without all the messy Application bits (like lists of developers, canvas pages, etc.).

Update: Okay, Facebook Connect was announced, and it is both more and less than I predicted. Yes, you use an API key to connect, but there is nothing special about a site calling an API. There appear to be some Connect-specific APIs, but they don’t yet appear in the distributed client (even in the sample app!). In addition, Facebook Connect provides some simple JavaScript APIs that activate some widgets that provide access to some of the built-in Facebook functionality. The most notable absence is any mention of running actual apps. I suppose it’s a good start, but it is really just inverting the relationship between the application and Facebook. Instead of Facebook being “in front”, the “app” (web site) is “in front” of the user. Of course, at times, Facebook is in front again (via those widgets). I think more can be done here, and I’ll be tracking this as things emerge.