March 04, 2010

Designing Buzz for a Google-Free World

If you haven't seen a lot of applications built in the last few weeks that leverage the Google Buzz API, it's because there aren't any. In fact, Google hasn't yet rolled out any API for Buzz. According to the company, this isn't due to any backroom dealings where they plan to introduce proprietary code and hooks that tie activity to their platform, but instead, because they wanted to be sure they could first build a product that in fullness leveraged open Web standards, and start with that foundation to deliver an interoperable system that could continue to function even if Google were to "disappear off the face of the earth".

In a presentation to the Silicon Valley Google Technology Users Group last night, held at the Google campus, DeWitt Clinton, a software engineer for the company, talked to developers and other tech enthusiasts about the company's API strategy and approach to Buzz, and explained that Buzz is designed not to increase lock-in to Google, but instead, to leverage open technologies that will let data flow to and from sites without central ownership. While a Buzz API will eventually be released, it will leverage the same open standards that power it today.

"The first principle of Buzz is that we can build this on protocols that are open and free, but not centralized," DeWitt said. "Can Google disappear off the face of the earth and Buzz still works? We need to make this data federated and distributed."

On the day Buzz launched, I referenced much of the foundation for Buzz in a quick article about the open tools and APIs that "make Buzz hum". But last night, DeWitt expanded that story to include 9 major open APIs, briefly outlined below.

1. Atom

DeWitt called Atom "the lingua franca of the programmable Web today", explaining that Atom contains entries that are "well structured", and include source entry, GUIDs that enable deduplication, and specification of the content type. He said, "You are able to pass rich data in that Atom feed in a way that is more specific than other feed types."

2. AtomPub

DeWitt said AtomPub "has become the most popular paradigm for restful APIs on the Web." AtomPub expanded the original Atom format to include the ability to both create and update feeds, not just passively read.

3. ActivityStreams

ActivityStreams essentially watch users' activity and can specify rich verbs and actions within those feeds. This enables feeds for all comments posted on Buzz, all likes, or even alerts that one person following you on Buzz also follows you on another network. DeWitt's examples hint at future developments for the platform, as these specific feeds are not yet clearly visible.

4. Pubsubhubbub

Much discussed here on the blog, Pubsubhubbub reduces the need for sites to poll for updates, and powers real-time updates between services. DeWitt reiterated "the hub is decided on by the publisher" and "there is nothing Google-specific about that.", saying that the infrastructure and plumbing for Buzz has been laid for the last few years. Pubsubhubbub has been pioneered by Brad Fitzpatrick and Brett Slatkin, both Google employees.

5. MediaRSS

Developed by Flickr, MediaRSS syndicates rich media through both RSS and atom feeds, creating a structured namespace inside RSS for content and a thumbnail. Buzz leverages MediaRSS, letting you pull rich content, like Flickr photos, into the platform. Of course, PicasaWeb, a Google property, also supports MediaRSS.

6. OAuth

The product of engineers from all corners, including Twitter, OAuth was engineered "to solve a vexing problem in the industry," Dewitt said, explaining OAuth prevents the need to ask users for their name and passwords on third party sites, acting as a delegated authorization protocol that gives permission to the application. Google Buzz, like Twitter, leverages OAuth to provide authenticated access to your data.

7. WebFinger

A new-age version of the old command-line prompted, text responding Finger protocol, WebFinger aims to be a way to get public information tied to an individual, through their identity, assigned to an e-mail address. "We want people to identify themselves, and we want people to discover people," DeWitt said.

WebFinger is similar to the strategy of OpenID, but OpenID hasn't had massive adoption by end-users who have found it unwieldy. WebFinger, aiming to be less arcane, enables the independent nature of Buzz, helping to federate the data and distribute it by domain, owned by the end user. DeWitt said, "The profile lookup and notification mechanism can be in the hands of the user being addressed."

8. Salmon

Still in earliest stages of development, Salmon is an extension or replacement for the old PingBack model that had blogs informing the other about references or links. This "flawed" model only provided minimal data, and could not be verified, letting me send PingBacks anywhere I wish if I chose. Salmon's goal is to leverage what's being called "Magic Signatures", signed with a public key to prove and verify linkage.

The first approach for Salmon will be to migrate comments from aggregators to originating posts, as covered a few times on this blog. But DeWitt said that "Likes" are similar activities that could flow back with Salmon, or be used to notify users of "following" or other activity. DeWitt forecast that sites like Blogger and StatusNet would rapidly adopt and federate Salmon to transmit data updates.

9. Portable Contacts

Simply described, Portable Contacts show your information and that of the friends who you follow, providing users a secure way to get access to address books and friends lists without having to request credentials or scrape the data.

DeWitt also noted XFN, the XHTML Friend Network, and FOAF (Friend Of a Friend) as being key contributors to the Buzz technology stack today, adding that he was "glad smart people were working on this ten years ago because we are all benefiting from it now."

DeWitt, on his Buzz feed, has been talking a lot about open standards and their importance to the Google team at large. See @Jesse Stay A few points of clarification to your most recent post [1], because I believe getting the details right matters. and "The thing I find most attractive about Google Buzz is its stated commitment to open standards.", as well as his first post from February 21st, which thanked the standard developers: Standing on the shoulders of giants—a look at the people behind the protocols behind Google Buzz:

Given Google's size, there is a good amount of distrust on the Web from people who think they own too much of your data, know too much about you, or have goals that run contrary to your own ideals on privacy, communication and sharing. Not even DeWitt's detailed presentations and explanations and promises of openness and data portability will convince everyone that they are on the right path. But I personally believe the frankness and detail that is being shown here is not just promising a strong future for this individual product (Buzz), but also in extending the groundwork done for the entire Web, for products and services we haven't even seen yet.

DeWitt adds: "All of these protocols are open. They are literally also all free. They are intended to be used by everybody, with or without Google being involved. You don't have to ask us if you can use Salmon or Pubsubhububb. We have a liberal and permissive patent license."

Is Google going away? Not today, and not this year. Is Buzz perfect? No. Of course not. Can it do all the things I can do on other sites, like FriendFeed? No. Not yet. But it seems that the Buzz team has opted to make tradeoffs that favor fast shipping and openness over completeness and individual features. And if you don't trust Google, it sounds like you can do something about it.

"We are pretty adamant about not building this on proprietary technology," DeWitt said last night. "If any of you feel that it is not going in the right direction, you have the power to change its direction and Google will not stop you."

You can find me on Buzz here and can follow DeWitt Clinton on Buzz here.