It’s easy as a technologist to think about openness solely in terms of technology, but openness is broader than that. Openness of technology means that others can build using the same tools that you do. Openness of data means that developers can build innovative products based on APIs that weren’t previously possible. And openness between people is what happens when when all of these things come together to give people better ways to share information.

Sure, some things Facebook launched are more “open” than others, but here is what’s exciting me:

1) No 24-hour caching limit: Developers have found that one of the most annoying policies was only caching data from the Facebook API for twenty-four hours at a time. At Six Apart this meant that we had built infrastructure that allowed us to comply with this restriction in a way that wouldn’t impact site performance. Today developers can store data from Facebook’s API as long as they’re keeping it up to date and agree to remove it at a user’s request.

2) An API that is realtime and isn’t just about content: Part of why it’s possible to remove the 24-hour caching limit is because Facebook’s API now supports the ability for developers to subscribe to changes. This means that developers do not need to continuously fetch data from Facebook to see if it has changed, but rather will have those changes pushed to their applications in realtime.

Now the first question you’re probably asking is if Facebook used PubSubHubbub; at least that was my first question to our engineering team a few months ago. Given that PubSubHubbub models a feed of public entries, it doesn’t work for subscribing to arbitrary social data (and doesn’t support JSON either). I think this is another example of how Google thinks so differently from Facebook. The web started as a collection of documents, but people are becoming even more important.

So instead, Facebook’s realtime API uses WebHooks and borrows from PubSubHubbub where possible. This is a first step toward a World where I no longer need to manually update my mailing address at every site I buy stuff from!

3) The Open Graph protocol benefits the web, not just Facebook: At f8, Facebook made two technology announcements using the term “Graph”, in addition to talking about the Open Graph as a bi-directional combination of many different social graphs. The first is Facebook’s Graph API and the second is the Open Graph protocol.

Here’s what I wrote yesterday when Chris Messina asked me what “open” meant in regards to the Open Graph protocol:

First of all it is designed to increase openness between people based on being able to connect with things all around the web. Within Facebook this means that people can like any web page anywhere, not just those on facebook.com.

Second, the Open Graph protocol increases the amount of semantic data on the web in a manner that isn’t specific to Facebook or any single social network. While we can all disagree about where the quotes and angle-brackets should go, at the end of the day I think we all can agree that this sort of metadata is good for the web.

Third, it was created and implemented by more than one company. We’re now broadening that group of people (right here) and are interested in evolving the spec in a meritocratic fashion.

Finally, it’s licensed from day one under the Open Web Foundation Agreement. As Jesse Stay wrote, this means that it, “is under a completely open license agreement that other platform creators can adopt, use, and freely distribute.”

While the technology is still evolving, it dramatically increases the amount of semantic data on the web and does so in a fashion which builds on RDFa and Microformats that anyone – including Google, Twitter, and the OpenLike project – can make use of.

4) OAuth 2.0: Back in January I wrote What’s going on with OAuth? where a few of us laid out the path toward OAuth 2.0. Last week Twitter used OAuth 2.0 under the covers of @anywhere. At f8, Facebook shipped OAuth 2.0 as the only way to interact with the new API. Earlier today the chairs of the OAuth working group within the IETF asked for a consensus call to publish the first official draft.

While I was involved in creating OAuth 1.0, I’m even more excited about 2.0. It’s so simple! No signatures. No request tokens. And distinct flows for web browsers, traditional web applications, living room devices, etc versus one flow that tries to do everything. Want my public data, fetch http://graph.facebook.com/davidrecordon. Want private data, just switch to using SSL and add `access_token` as a parameter. That’s how it should be.

I don’t think we could have picked a more interesting time to work on the web than during its transformation to being about people at the core.

The OAuth protocol enables users to provide third-party access to their web resources without sharing their passwords; kind of like a valet key for the web. To date, OAuth 1.0a is the most successful such protocol deployed on the web. The origins of OAuth date back to late 2006, when a small group of web engineers, tired of reinventing the API authorization wheel, came together to find a common, open solution.

The protocol was derived from several existing API authorization protocols, including AOL, Flickr, Google, Microsoft, and Yahoo!. By developing a unified approach to API authorization, the goal was to reduce the burden of implementing any one of these protocols, and provide third party applications a more convenient and secure way to access user data. It is also well-established that security protocols are hard and often suffer from potential exploits. By focusing on an single, open protocol, the community could reduce the likelihood of an attack and respond faster when one occurs.

In the past two years, the number of services that require users to divulge their passwords to enable third-party access — the so-called password anti-pattern — has decreased dramatically. Today the most well-known and used deployment of OAuth 1.0a is the Twitter’s API. (If you’re interested in a more detailed explanation of OAuth, check out The Authoritative Guide to OAuth 1.0.)

Last year OAuth transitioned to the IETF as a new Working Group to produce version 1.1 which would be suitable for publication as an Internet Standard. The working group was tasked with reviewing the security and interoperability properties of the protocol, while maintaining as much backwards-compatibility as possible. As is sometimes the case in such efforts, there was little interest among the community in such a minor cleanup.

Introducing WRAP

At the same time, new use cases emerged as well as a significant amount of hands-on experience about the shortcomings and gaps in the 1.0a version of the protocol. A small group of developers herded by Dick Hardt started work on simplifying the protocol, inspired by the OAuth Session Extension proposed by Yahoo!. Originally dubbed “Simple OAuth”, it was later renamed to WRAP (Web Resource Authorization Protocol) to reflect the fact that it is a different protocol. It is now known as OAuth WRAP.

WRAP attempts to simplify the OAuth protocol, primarily by dropping the signatures, and replacing them with a requirement to acquire short lived tokens over SSL. It is not an even trade-off, and the new proposal has a different set of security characteristics, benefits, and shortcomings.

In 2007 when OAuth 1.0 was being created, SSL was used sparingly for APIs. As CPUs have become faster and more specialized SSL hardware has been deployed, it has become increasingly possible to operate APIs over SSL. Some APIs, like the Google Health Data API or Yahoo!’s Fire Eagle API, operate fully over SSL anyway as developers are interacting with non-public data. Using SSL obviates the primary purpose of the cryptography used in OAuth 1.0a, which was designed for transferring data over insecure channels.

WRAP addresses two areas in which the 1.0a protocol is lacking: it offers new ways to obtain tokens, and it evolves the architecture to enable other roles to issue tokens (other than the server). OAuth 1.0a offers a single browser-based redirection flow used to send the user from the application to the server, obtain approval, and return to the application. WRAP adds a few new flows for obtaining authorization and tokens mainly designed around providing better experiences on devices such as your XBox, desktop applications like TweetDeck, or fully JavaScript based implementations like Facebook Connect. And unlike 1.0a where the server issues and verifies every token, the tokens in OAuth WRAP are short lived and can represent claims issued by an authorization server, providing scale and security benefits for large operators.

Judging by the original “Simple OAuth” moniker, the goal behind WRAP was not to confuse developers or compete with OAuth. The intention, rather, was to promote OAuth and increase long term adoption by offering an SSL variant. Therefore, if you’re building a new API today and are trying to decide between deploying OAuth 1.0a or OAuth WRAP, nine times out of ten you should continue deploying OAuth 1.0a. But start experimenting with WRAP when its features are important to you and you are comfortable making changes as it evolves.

Building OAuth 2.0

WRAP brought the use cases and experiences that inspired it to the attention of the IETF working group. The consensus is that we now have enough implementation experience and new requirements to begin work on OAuth 2.0, instead of a minor revision. OAuth 2.0 will likely contain two parts, one defining an authentication scheme for accessing resources using tokens, and the second defining a rich set of authorization schemes for obtaining such tokens. By separating the two parts, we will be able to provide the right level of abstraction and modularity to support both the SSL-based approach taken by WRAP as well as the existing signature-based approach taken by 1.0a.

In many ways, OAuth 2.0 will be the result of combining the best ideas from both protocols. The authentication part will built on top of 1.0a while the authorization part will build on top of WRAP. It is important to remember that it is very early in the process, and that all these decision will be made by the members of the IETF OAuth working group. In other words, by those who show up. The goal is to have a set of stable drafts for OAuth 2.0 by the upcoming IETF OAuth Working Group meeting in March at the 77th IETF meeting.

For those implementing OAuth 1.0a today, a new edition has been published as an RFC draft which was accepted by the community as a replacement for the original 1.0a specification. This new specification does not change the protocol, but is more readable, includes many clarifications, errata, and examples, and thus easier to implement.

If you’re interested in keeping track of what’s going on with OAuth, Hueinverse’s OAuth page is a great place to watch. To get involved and take part in this important work, dig into the IETF OAuth Working Group and WRAP discussion list.

In April of this year, Mark Drapeau and Linton Wells II (previously the acting CIO of the DoD) published a thirty-five page report titled Social Software and National Security: An Initial Net Assessment which looked at the interplay between social software and national security. Combining a few of their conclusions, social software, “is an important information sharing enabler between individuals within government, between government employees and communities of interest, between researchers and government data, between the government and its citizens, and between governments of different countries” and that while, “information security concerns are non-trivial” that, “there is a point at which a mission can be hurt by strictly enforcing such draconian approaches that it keeps government from taking advantage of social tools that adversaries and other counterparties are using.”

While it would be possible for the DoD to block specific social networks by denying troops access to domains such as facebook.com, myspace.com, twitter.com, among hundreds of others around the World, as Stowe Boyd said on the Department of Defense’s Web 2.0 Guidance Forum, “Web 2.0 is fundamentally social, treating the individual at the center of the universe as opposed to groups or organizations, and then basing communication and information paths on social relationships between individuals.”

It’s my belief that even if the DoD tried to block all access to social networking sites it would be a never ending and ultimately unsuccessful battle as social is becoming a core component of the web itself. Not only are traditional social networking sites like Facebook, Twitter, and MySpace expanding through their own web-wide API programs, but social features are increasingly pervasive in what used to be “normal” web sites. A few examples:

The New York Times “Times People” – The New York Times launched the ability for you to sign in to nytimes.com, create a profile and follow other readers all without having to leave nytimes.com. This includes the ability to directly recommend articles that you’re reading to your followers on NYT as well as see those recommendations on every page of their site.

Palm Pre and Android – Both phones have address books that are integrated and updated automatically with your contacts elsewhere. The Android is constantly in sync with your Gmail contacts and the Pre has a feature known as Synergy which combines contact information, calendars and instant messaging from data stored locally on the phone, Gmail, Facebook, AOL, and Exchange.

ShareThis and AddThis – For the past few years, bloggers and other content providers have integrated those Nascar-style widgets into their sites to provide an easy way for readers to re-share articles. While they initially focused on re-sharing via blogging services, today they support and default to services such as Twitter, Facebook, MySpace, and AOL instant messenger.

Google Reader – Not long ago reading blogs and other content online was a solo experience from within your desktop “feed reader.” Google Reader changed this with the ability to follow other users and see what your friends are reading. In July they added the ability to group your friends and filter what you read based on what they liked. A few weeks ago they also added ability to share stories via Facebook and Twitter. Lifehacker writes in more detail about Google Reader Updates with Still More Social Features and More Google Reader “Send To” Tricks.

Google Friend Connect – Friend Connect is one of Google’s projects to bring social features to the long tail of the web. It provides the ability for non-technical site owners to bring sign in, profiles, following, “comment walls”, and other OpenSocial applications just by adding a few lines of HTML/JavaScript to their sites. Friend Connect is already placed on over five-million sites, is available in forty-seven different languages, and integrates with networks including Google, AOL, Twitter, and Plaxo. You can see Friend Connect on Robert Scoble’s blog showing the 1,600 people who have chosen to become members of his site directly. (Not to mention that in order to block usage of Google Friend Connect, the DoD would have to block troop access to Google.com itself!)

Identity – Whether via OpenID, OAuth (Twitter), or Facebook Connect it’s now simple to use an existing profile to sign into millions of different sites around the web. Well over one-billion people have accounts that are enabled with either OpenID or Facebook Connect. In many cases, it isn’t just about sign in but being able to find people you know on these sites and share content you create back into a variety of social networks. I’ve previously written about the Anatomy of “Connect” and how it’s becoming increasingly possible for any web site to integrate profiles, relationships, third-party content and activity sharing with these technologies.

Niché social networks – Whether it is a Ning community like GovLoop, a standalone network like GoodReads focused on book lovers, or Intel Communities for IT professionals, it’s clear that social networks will not only be large destination sites. More traditional blogging tools such as Movable Type, TypePad, and WordPress have all added various social features themselves over the past two years. See Movable Type Motion, Top Reasons to Love The New TypePad which includes an activity stream, profiles and sharing, and BuddyPress. (Disclosure: I work for Six Apart who creates Movable Type and TypePad.)

From infrastructure technologies like OpenID and OpenSocial, to widgets like ShareThis and Friend Connect, to The New York Times itself and your phone, features and interactions that you once only found on social networks are becoming ubiquitous. While it may be convenient for the DoD’s IT department to think about social networking as a list of URLs that they can block from any network, the reality is that social networking is becoming a core piece of the web itself.

For instance, the “small view” (i.e. the widgets which actually appear on the MyYahoo page) must be developed using “Yahoo! Markup Language” (YML), which is an extension of HTML with more bells and whistles. Yahoo is trying to bring together YML and the OpenSocial Markup Language (OSML), but right now they are forked. But turning an OpenSocial app into one that works inside Yahoo is getting easier.

Beware, the next few paragraphs get a bit geeky. YML (more info) is a lot like FBML and OSML (more info) in that they are all social markup languages. OSML is a bit different though, unlike YML which only works inside of Yahoo! and FBML in Facebook, OSML is part of the OpenSocial project and is designed to work inside of many different social network containers. If I wanted to display a user’s name inside of my application, here’s what it would look like:

• FBML: <fb:name uid=”4″ />
• YML: <yml:name uid=”QPR12345″ />
• OSML: <os:Name person=”${User}”/>

In this simple example, FBML and YML are nearly identical; you pass in a userid. OSML is a bit different, they’ve created a rich templating language and you’re passing in a user object instead of just a userid.

XFBML is the evolution of FBML but designed for use via Facebook Connect. Given that XFBML is designed to work for sites outside of Facebook.com, I’m much more interested in the ideas behind it and how they will ultimately be useful across social networks. Today XFBML is powered by JavaScript, though in the future I can imagine having actual HTML tags for this sort of social content. One of the large benefits of this approach is that a user’s privacy settings can be maintained easily across sites (see Thoughts on dynamic privacy, though note that Chris’ closing is no longer accurate).

Today XFBML works in such a way that I include Facebook’s JavaScript loader in my page, the JavaScript walks the page’s DOM looking for tags like <fb:profile-pic uid=”4″ />, uses your browser (and thus your current cookied session) to request the user’s photo, and then based on the user’s privacy settings and your relationship to the user fills in their photo (or doesn’t). This provides two main benefits: 1) if you only share your photo with your friends, a non-friend browsing this page would not see the photo and 2) if you change your photo on Facebook it will change on this page as well.

Given how quickly the Social Web is coming together, I believe that HTML will need to support social elements someday soon. It’s great to see this type of innovation by Facebook running in the wild, but the web itself ultimately evolves best when multiple competing approaches come together. Just as OAuth brought together the best practices from AOL, Flickr, Google, Yahoo! and others, there is a similar opportunity to bring together FBML, YML and OSML along with the client-side benefits of XFBML.

Over the past year we’ve seen an uptick in the infrastructure, development tools and projects designed to build the social web (n.b. I define the social web as something that is inherently decentralized, just like the web itself). On top of that, MySpace has gone from being off of most developer’s radars to the most open social network in existence. With MySpace I’m able to use my account to sign into other sites via OpenID, share my activity using Activity Streams, build applications using OpenSocial, interact with their APIs using OAuth and access APIs that not only allow the creation of new content within MySpace’s garden but also extract data from it.

While Facebook has made significant contributions to open source projects, ranging from some of their own to memcached, they’ve largely been absent from much of this progress around building the social web (remember, I define it as being inherently decentralized). Instead, like Microsoft they have willfully ignored many industry efforts in favor of their own proprietary development platforms. To their credit, they’ve been one of the most innovative social networks over the past two years, pushing the boundaries of what’s been thought of as possible with features like social tagging in photos, Newsfeed, Platform, Beacon, integrated chat and Connect.

Two weeks ago this changed. Facebook joined the board of the OpenID Foundation, released two-way APIs around status, notes, pictures and videos, hosted a user experience summit focused on OpenID and released a blog commenting widget powered by Connect. Since then they’ve also talked about how they wish to support the Activity Streams project and have reiterated their commitment to the sort openness that we’ve been promoting as key pieces of the social web.

I know what you’re thinking: “talk is cheap.” True, Digg said they’d support OpenID three years ago and we’ve seen…or wait, no we haven’t! I wish I had something concrete to point at to show that my next argument isn’t crazy, but I don’t. All that I can point to is the change I’m seeing when interacting with Facebook and their interactions with developers this year compared to the past.

My prediction is that by the end of the year Facebook will become the most open social network on the social web. I believe that not only have they now found business value in doing so, but also truly believe that the next phase of their mission, “to give people the power to share and make the world more open and connected” requires that they do so. This means that anyone building a business based on the notion that Facebook will remain a walled garden and won’t adapt – as was true with traditional media when blogging came about – will have their world turned upside down this year.

Disagree if you like, but my second argument is that if Facebook does not seriously embrace these ideas this year that their current position of dominance will be usurped. I’m not saying that Facebook will go away, that all of my friends will leave, that it will become irrelevant or that tens of thousands of developers will move on overnight. This year, there is an amazing opportunity to find and define a proper balance between traditional walled-garden social networks and completely decentralized efforts like the DiSo Project.

1. Profile: Everything having to do with identity, account management and profile information ranging from sign in to sign out on the site I’m connecting with.
2. Relationships: Think social graph. Answers the question of who do I know on the site I’ve connected with and how I can invite others.
3. Content: Stuff. All of my posts, photos, bookmarks, video, links, etc that I’ve created on the site I’ve connected with.
4. Activity: Poked, bought, shared, posted, watched, loved, etc. All of the actions that things like the Activity Streams project are starting to take on.

In my mind, the Goals of all of these “Connect” applications are focused on helping people discover new content, people they already know as well as new people with similar interests. They also all help to reduce some of the major pain points when it comes to decentralization of social networks; signing up for a new account, eliminating the manual process of filling out your profile, uploading a photo and going through that madness of “re-friending” your friends time and time again. While all of these features aren’t new, how this style of application combines them all certainly seems to be. If 2008 was the year of social application platforms (Facebook Platform and OpenSocial), perhaps 2009 will be all about “Connect” – whatever that means.

(I’ve put together an example of this using Facebook Connect and Citysearch as it seems to be the most complete example that I can find.)

As Web 2.0 took root, the ability to login to a site, store preferences and build a profile became ubiquitous. Beyond reading news or blogs, it’s fairly rare that you’re on a site where you’re either not logged in or don’t have the ability to login. The downside is that just about every site requires you to create a new account and have cookies to keep you logged in. Thus when your cookie disappears, you have to login again. Maybe your browser’s password manager eases this pain, but there are plenty of people that would be in a world of hurt if their browser every forgot all of their passwords (or they use a friend’s computer).

If we remove passwords from the equation and instead use OpenID, there’s the notion that upon visiting an OpenID enabled site (now numbering more than 25,000 across the web) you’ll most likely submit a form telling that site about your OpenID. I might go to MapQuest and login by typing in my OpenID “http://www.davidrecordon.com/” or Ma.gnolia and clicking a “Sign up with a Yahoo! ID” button. These interactions, with various tweaks around them, are very much the status quo today. If OpenID wishes to see true mainstream adoption, this will need to change.

Imagine if your web browser really knew who you were on the web. Just as you login to your computer, what if when you fired up your browser, it said “Hello Dave” and asked you to “unlock it” as well (Chris Messina was quite influential in my thinking about it this way). In doing so you become securely logged into your OpenID provider (or maybe more than one of them) and as you move around the web your browser takes care of automatically logging you into the sites that you want to be, asking you about others, and helping you register with new ones using your OpenID. Argue as much as you want about the details in making this happen, but I think it’s hard to disagree that making it easier for people to manage and use their identity (or identities) online is a bad thing.

There are a lot of proposals around how current OpenID interactions will change – a great summit on OpenID usability was held a little over a month ago – and whether it be more one-click buttons, less buttons, bigger logos, or email addresses I think it’s also worth looking at what it will take to really get the browser involved. This certainly isn’t a new idea, every major browser has the ability to remember passwords and FireFox even has those pesky user profiles so that people could theoretically have different cookies, bookmarks and other settings.

In the internet identity space this isn’t a new idea either. Information Cards (more widely known by Microsoft’s CardSpace implementation in Windows) have credit card like rich desktop integration built using WS-* and SAML. Dick Hardt’s team up in Canada has built Sxipper for FireFox which helps with both OpenID and normal web forms as well. When I was working for VeriSign, we developed the OpenID Seatbelt which is also a FireFox extension designed to make OpenID easier and prevent phishing by detecting OpenID enabled sites and your provider.

Today, MySpace, Flock and Vidoop released a prototype of their implementation toward this vision with OpenID for Flock. All three of these browser plugins help you manage your OpenIDs, detect when you’re on an OpenID enabled site, and then make it easier to sign in. To me, what Sxipper aspires to enable feels the most useful for a mainstream user.

OpenID for Flock is an add-on that polishes previous attempts of putting OpenID into a browser. While the user experience and graphics are quite a bit better than what I helped build at VeriSign, it’s lacking the features that help prevent phishing (making sure you’re actually logging into your OpenID provider versus a phishing site that looks like it) which is a bit surprising given Vidoop’s involvement. That said, OpenID for Flock is Open Source as part of a project dubbed IDentity in the Browser (IDIB) which the same cannot be said for either Sxipper or VeriSign’s OpenID Seatbelt. Given that IDIB is Open Source and already written as a Flock add-on, I’d certainly expect to see it ported to FireFox and there be far more community support of it compared to the other add-ons.

So where do we go from here? I don’t know how to write great browser plugins so just doing it is out. It’s great to see Flock’s direct involvement in this Open Source effort as it shows browser vendors innovating and experimenting with how their own products must evolve to support identity. Maybe this will cause the other browser vendors to think seriously about what they too could be doing in future versions to help make identity management easer and more secure on the web.

In my mind, Gears can help us get there. While it started as a project by Google to evolve web browsers faster and add needed features like offline support, it’s grown beyond that with offline support now coming in HTML 5 and a new Geolocation API. Today Gears runs on half a dozen different browser/platform combinations including FireFox, Internet Explorer, Safari, Chrome and Android. If there was ever a developer platform to build an Open Source cross browser implementation of what OpenID support might look like, Gears seems like the place to do it. Not only does this mean that we’ll need to write less code to have it work in multiple browsers, but ideally if it became mature enough maybe the Gears team would choose to ship OpenID support as well? All of a sudden, the community could be down from a handful of browser plugins to one leading Open Source example.

What do you think? Do you agree that identity is becoming as essential to a browser as location? Should we content ourselves for issues like security to be relegated to a few dozen-pixel lock icon, or have Big-Red-Phishing-Warnings set a standard that important issues deserve significant real estate? Really though, should the browser become more actively involved in how you use the web on a daily basis?

Beginning today, Windows Live™ ID is publicly committing to support the OpenID digital identity framework with the announcement of the public availability of a Community Technology Preview (CTP) of the Windows Live ID OpenID Provider. You will soon be able to use your Windows Live ID account to sign in to any OpenID Web site!

Microsoft joins Yahoo! who implemented support for OpenID earlier this year for all of their accounts. By sometime next year, every AOL, Microsoft and Yahoo! user will have an OpenID which makes the emerging focus on improving OpenID’s user experience even more important.

Angus Logan from the Live team has put together a quick screencast showing the current developer oriented process for testing the Windows Live ID OpenID Provider with an OpenID 2.0 enabled site.

Windows Live ID OpenID Provider Screencast from Angus Logan on Vimeo.

While this is great news from Microsoft, real web-scale adoption of technologies always faces a chicken-and-egg problem between developers and vendors. Developers don’t want to adopt a technology without buy-in from platform providers and platform providers don’t want to support a technology if developers won’t use it. We’ve largely been able to successfully avoid this concern with OpenID as it grew from roots in an open source community with lots of people and companies involved in making OpenID what it is today. There are now well beyond half a billion OpenIDs available on the web which means we can mark the first phase of OpenID adoption, platform support, as a success.

The next phase of developer adoption will not be measured in the number of OpenIDs or sites that support it, but rather user experience, accessibility, and seamlessness of integration into a wide variety of applications and experiences.

We originally expected a handful of people to show up and hack on implementing bits of the specification, but so far have been blown away at the progress made and about the twenty people that came. Tomorrow is a summit style meeting hosted by MySpace also in San Francisco to try to finalize the specification among a wide range of providers and consumers. I’m expecting a handful of interesting demos, but wanted to share two that have already come together tonight.

Joseph Smarr and Kevin Marks of Google hacked together a web transformer that integrates Microformats, vCard, and the Portable Contacts API. Given Kevin’s homepage which is full of Microformats, they’ve built an API that extracts his profile information from hCard, uses a public API from Technorati to transform it to vCard, and then exposes it as a Portable Contacts API endpoint. Not only does this work on Kevin’s own page, but his Twitter profile as well which contains basic profile information such as name, homepage, and a short bio.

Brian Ellin of JanRain has successfully combined OpenID, XRDS-Simple, OAuth, and the Portable Contacts API to start showing how each of these building blocks should come together. Upon visiting his demo site he logs in using his OpenID. From there, the site discovers that Plaxo hosts his address book and requests access to it via OAuth. Finishing the flow, his demo site uses the Portable Contacts API to access information about his contacts directly from Plaxo. End to end, login with an OpenID and finish by giving the site access to your address book without having to fork over your password.

While the individual building blocks are fairly geeky themselves, pulling them together like has been happening tonight shows that we’re only at the beginning of building the next generation of social networks. When the pieces work together, people won’t have to know what’s going on under the hood; it will just work–and will be almost like magic. John has more photos up on his blog.

This week we discuss Meebo’s announcement of Community Instant Messaging since it continues the trend of making the entire web more social while using existing building blocks to do so. As Joseph explained, the underlying architecture Meebo is using is Jabber/XMPP. What this means is that unlike Facebook’s Chat, social networks using Meebo’s Community IM have the ability to interoperate from day one if they choose to do so. Google’s Friend Connect is another great example of reusing building blocks where they take advantage of OpenSocial, OpenID, and OAuth. Overtime supporting these underlying technologies becomes easier as companies like Google and Meebo start to build them into their products.

Last week we focused on Gnip and Identi.ca, explaining how Gnip is helping to change the model of accessing data on the web. Traditionally web APIs have been focused on pulling data though things like Twitter’s XMPP Stream and Gnip are starting to flip this model on its head. And next week we’ll be taping from Facebook’s annual developer conference f8 in San Francisco. So please check it out, subscribe to our RSS feed (yes, we know our enclosures are broken), let us know what you think, and how we can do a better job of explaining the Social Web in an understandable way.