The publish/subscribe paradigm is commonly found throughout software engineering. In essence, a component of a system publishes events as it performs its tasks. For example, a video encoder would post an event when it has completed encoding.

Separate components register as subscribers, and receive notice when an event occurs. In our example, a content management system could take the encoded video and publish it to a website. Meanwhile, a separate component could email the director to inform him that his video is available online.

A broker in the middle (a “hub” in PubSubHubbub terminology) is responsible for delivering published events to any interested subscribers. This decoupling creates a flexible architecture, in which separate components are isoloted and can evolve independently.

There have been many attempts to define a standard publish/subscribe protocol in the past, including the XEP-0060 extension to XMPP, AMQP, competing WS-* efforts, and RestMS (which I’m unfamiliar with and need to research). None of these protocols have achieved widespread adoption. PubSubHubbub is an attempt which initially appears like it may have a better fate.

Architecturally, PubSubHubbub is decentralized and designed to scale to the size of the web. Because of this, it doesn’t suffer from any slow down or failure at a central point. I found the touting of this benefit quite humorous given the location of the meetup at Twitter’s headquarters.

One of the potential limitation of the protocol, however, is that it is server-to-server only. It operates on the backend, and is not attempting to reach the last mile to desktops or mobile phones. I suspect that this drawback could eventually work in favor of XEP-0060, which could act as a compliment to PubSubHubbub by filling this gap.

Interestingly, Brett remarked on how slowly the web actually changes. He revealed that the egress from the reference hub on App Engine is only 24Kb/second, including all of Blogger, LiveJournal, and FriendFeed. Taken at face value, this is a remarkably low figure.

To kick off the evening, Brad Fitzpatrick and Brett Slatkin (both of Google) presented on WebFinger and PubSubHubub, respectively. Brad stated that he “would like to totally decentralize social networking,” which is a common link between the two efforts. This post will outline Brad’s talk on WebFinger; PubSubHubbub will follow separately.

WebFinger attempts to solve the problem that we don’t have good identifiers for people. Over time, people have become accustomed to identifying themselves by an email address. They sign into websites with this as their ID and print it on their business cards. People instinctively recognize anything with an @ sign in it as an email address.

From an engineering standpoint, however, this is a rather stupid heuristic. Something that looks like an email address may, in fact, not be one at all. A Jabber ID is a common example. To distinguish between the two in a computer program, a URL must be formed with either a mailto: or xmpp: scheme to represent email and IM addresses, respectively.

However, it would run counter to usability to avoid “email address-like” identifiers, so a solution to this problem is necessary.

For its part, WebFinger has minted the new URI scheme acct: to denote a generic account. From this generic concept, the WebFinger protocol can be used to determine the capabilities of the account. For example, whether it can be sent email or instant messages (or both), or where that person’s address book is located.

It is important to note that this new acct: scheme imposes no burden on the user. Ideally, people will remain completely unaware of its existence. They will continue to use email address-looking strings as usual, and applications will simply treat them as account identifiers internally.

Of course, any new protocol hinges its hopes on adoption by other parties. Both Google and Yahoo! have deployed experimental endpoints. With the support of two of the big-cos, as well as independent implementations, WebFinger’s potential to become a key piece of enabling infrastructure is promising.

WebFinger derives its name from Finger, a protocol from the dawn of the Internet which was used to look up information about people on a network. One slide in Brad’s deck contrasting the two illustrated that Finger ran over TCP, whereas WebFinger uses HTTP (”the new TCP”, sigh), an aside which I found amusing.

For technical details, Eran Hammer-Lahav has a guide to implementing WebFinger, in addition to other useful information on the topic.