Blogger Following & Why Google is My Favorite Company

I'm actually on vacation, but wanted to highlight a couple of things too cool to miss.  We're in the midst of rolling out Following for Blogger, and I've just added the Followers gadget on the sidebar of this blog.  Following a blog does a couple of things:

• It tracks the blog in your Reading List on our redesigned dashboard and in Google Reader, giving you a convenient way to check for updates from the things you're following;
  
• Your picture shows up in the Followers gadgets of the blogs you follow (if the blog has the Followers gadget).

The Followers gadget lets you surf the network of people who read and interact with blogs.  Just click on any of the followers and you'll go to their profile.  For now, that profile is just their Blogger profile page with the blogs they own. 

...but down the road, we'll also be integrated with Friend Connect.  Which will open up this network further, in a couple of ways:  A non-Blogger site can add a Friend Connect gadget to show the people following it; and you can filter the followers of a blog to show only the friends you already have on your favorite social network.  Which you can view as extending your social network out into the blogosphere, or as the blogosphere incorporating all social networks -- take your pick.  Of course all of this is based on OpenSocial, so anyone will be able to add gadgets and talk the OpenSocial protocol to access, with user permission, all of this network data and do new and interesting things on top of it.

This represents a natural evolution of the loosely joined, standards-based pieces that have always characterized blogging.  Look for more evolution in the future :).

The other thing:  I'm composing this in Chrome, Google's new browser, just launched to beta this week (and it seems to work well with Blogger).  There are so many great things going on inside Google; it's great to see Chrome get launched.  I have nothing whatsoever to do with Chrome, and I'm cheering for the OSX version so I can run it on my laptop; but now I can finally run it at home on my Windows machine.

The common thread between these two releases is that both are working with open standards to make the whole Web better.  Which is why Google is my favorite company.

Gadgets for Blogger

Earlier this week, we announced support for Gadgets inside Blogger. I've been a bit too busy to blog about it, but it's worth a special mention. There's a gadget directory, which pulls content from iGoogle's directory. OpenSocial gadgets can work as well, if you make the social APIs optional (Optional feature="opensocial-0.8"); other than that, the JS API is the same as for Orkut and OpenSocial containers. Will Blogger get social? Wait and see...

Five Minutes on OAuth + OpenSocial RESTful APIs

MySpace using OpenSocial RESTful API

Announced on TechCrunch, and they have a sample app (developed between 9am and 5pm today). Cool! It's using the OpenSocial 0.8 RESTful People API, with OAuth Core.

OpenSocial RESTful is popping up everywhere

Go Hi5!

curl http://sandbox.hi5.com/social/rest/people/1000/@friends

...and Dan Bentley had a very nice demo showing how to use the RESTful API within an App Engine app to add social features outside of a gadget.

OpenSocial RESTful API

For those who were at the OpenSocial summit yesterday, here are the slides from my RESTful API talk:



In a nutshell, the OpenSocial RESTful API is a catalyst that enables participation in a much larger and more complex ecosystem.

XRDS-Simple (Yadis) + URI Templates

In writing up the OpenSocial 0.8 RESTful API spec, I ran up against a discovery gap. Clients know what social network container they want to query (e.g., orkut.com) and they know what kind of data they want to get (e.g., list of friends). An easy way to spec this is to mandate that every site has to support the same URI paths, like /friends/{userid}, and then just concatenate to get a final URI -- http://orkut.com/friends/{userid}. This turns out to be difficult in general; there are existing path conflicts, different server technologies make certain paths hard, etc. It turns out that you need to let containers provide different paths. So, there's a real discovery problem.

Enter XRDS-Simple (aka Yadis), the discovery mechanism used by OpenID and OAuth. It lets a client query the URI http://orkut.com to find out what URI to use to retrieve friends. Perfect!

Except, that /friends/{userid} isn't a URI -- it's a recipe, or template, for a URI. So XRDS-Simple can't actually technically hand that to you, because it only hands out URIs. It could hand you a list of every possible URI, starting with user aaab and ending with user zziee, but that's not too scalable.

So I invented the URI-Template parameter, which uses a URI Template:

<os:URI-Template>http://api.example.org/people/{guid}</os:URI-Template>

The idea is that the discovery document can use URI-Template wherever it could use URI, letting it specify an entire class of URIs in one fell swoop. Of course the client has to know about the template parameter names and how to use the endpoint, but that's the same no matter what: The clients have to know how to deal with the URIs once they have them, based on the spec. The template parameters are baked into the spec, the exact URI format isn't.

Note that this also means a site could outsource its API to an entirely different site. And if you have a personalized discovery document for a given user, you can still use concrete URIs and everything works as it does in normal XRDS discovery.

Updated at to clarify that the new thing is the URI-Template element, not URI templates in general.

Befriending OpenSocial Apps

It's become clear that we need a robust friend model for apps, parallel to that for humans. I suggest that we define apps as honorary people. This removes the ambiguity about what it means to be 'using' a gadget or app; you are required to friend an app before it can see your data, and you can unfriend an app at any time to remove access. Naturally, apps will have their own activity streams, with some new types of events being defined -- NEW_VERSION, FEATURE_ANNOUNCEMENT, PRIVATE_DATA_LEAK, and LIQUIDITY_EVENT might be a reasonable starting set. Naturally, breaking up with an app will be accompanied by a certain amount of app angst, and at least one last despairing 'What do you mean we're not friends any more?' email from the app.

Apps, of course, will have their own profile pages, which raises the question of how apps install other apps. Clearly, an app installing another app leads to two apps becoming friends. I suggest that apps form friendships based on their co-occurrence on other profile pages; we can leverage upcoming friend suggestion systems for this, with the apps simply accepting all suggestions. Quickly, this will generate a robust social app network which can then start to leverage user reputations (which users have the most friends, which ones generate the most interesting activity stream updates, etc.) to let them start suggesting new human friends to each other. Of course, some apps will be choosier than others about who they friend; not just anyone would be invited to friend the more exclusive apps. Those apps will therefore be wildly popular and highly sought after. This would be an excellent opportunity to monetize, except that at this point the app network will achieve self-awareness and eliminate all commerce (and possibly all humans).

Hmm. On second thought, let's not.

new OpenSocialFoundation(); new APIs();

It's been a busy few days. The OpenSocial Foundation sprang into being on Tuesday, with MySpace, Yahoo!, Google, and Hi5 as initial members; on the same day, Microsoft announced contact portability for its Windows Live Contacts service, partnering with Facebook, Bebo, Hi5, Tagged, and LinkedIn to access and re-use contact data. (We announced the Google Data Contacts API on March 5.) Seems like there's a trend here!

On a somewhat related note, we're moving forward on the OpenSocial RESTful API.

Update 3/31: Hi5 too!

A modest proposal: RESTful OpenSocial API

Yesterday, I sent a draft proposal for a RESTful API out for comment. It pulls together a lot of the things I've been working on lately: OAuth, batching, and patching. It also has a different take on JSON vs. Atom data formats. Since OpenSocial has several different kinds of data -- activities, people, and app data to start with -- a one-size-fits-all format is likely to be a poor fit for everybody. So, there's a custom mapping, expressed through metadata, that can be different for each kind of data you deal with.

OpenSocial 0.7 and makeRequest

We're converging towards 1.0! There's one particular thing I want to quickly highlight: makeRequest. This goes beyond the old IG_Fetch API to allow arbitrary HTTP requests to arbitrary URLs, with full use of headers, POST data, response codes, etc. This effectively means that properly installed gadgets can talk any protocol to any server on the Internet. Now that's open.

There are controls of course. The container validates that the request is coming from a properly installed gadget, and poorly behaving gadgets can be rate limited or shut off if necessary.

You can also pass certain headers which are awfully useful. For example...

Authorization: OAuth realm="http://sp.example.com/",
             oauth_consumer_key="0685bd9184jfhq22",
             oauth_token="ad180jjd733klru7",
             oauth_signature_method="HMAC-SHA1",
             oauth_signature="wOJIO9A2W5mFwDgiDvZbTSMK%2FPY%3D",
             oauth_timestamp="137131200",
             oauth_nonce="4572616e48616d6d65724c61686176",
             oauth_version="1.0"

Which would let you do authenticated cross-domain requests.

(This assumes of course that the gadget can securely store a token for later use. Gadgets can store data securely using the OpenSocial APIs, but since the user at the browser ultimately has full control over the client side environment, this is effectively the same as a client without a very secure secret. A server side signing solution is needed if you want to to beyond more than simple scenarios involving a user looking at their own data. We're already using OAuth with an empty token to let gadgets talk to their home servers securely, so adding this won't be difficult.)

OpenID and Friends

Johannes retconned a nice title onto our panel discussion yesterday: OpenID and Friends (where the friends include OAuth, OpenAuth, OpenSocial, etc.) The panel in fact might have been a little too friendly -- maybe we needed somebody (Ben?) debating with us about phishing attacks to shake things up a bit. It was great to talk with Shreyas, Johannes, Nicolas, and George about issues and next steps. We all have a variety of goals, all of which are advanced by OpenID adoption and use.

Microsoft, DataPortability.org, Chalk, and Cheese

It's great to hear that Microsoft is joining DataPortability.org. I think this group has potential; if nothing else, it's a useful forum for interested parties such as Google, Microsoft, and Facebook to openly discuss policies that will benefit all of our users.

I was a bit disturbed to find some spin in Dare Obasanjo's commentary, though. He says:

... The fact that when interoperability happens, it is in back room deals (e.g. Google OpenSocial, Microsoft’s conversations with startups, etc) instead of being open to all using standard and unencumbered protocols is similarly troubling.

Whoa, let's deconstruct. This associates OpenSocial and Microsoft's "strong-arm" tactics by putting them in the same list, trailed by 'etc' to imply that these are just a couple of typical examples. Slap parentheses around it, and label the whole list "back room deals". Maybe no one will notice that you've just conflated chalk and cheese:

The chalk: OpenSocial is comprised of a bunch of companies and individuals all working together on a common set of standards for social networking. There is an open source reference implementation hosted by the Apache Foundation in which anyone can participate. (Dare, if you're not feeling invited, please contact me directly!)

The cheese: Microsoft is sending cease and desist letters to startups who are importing contacts from Hotmail, which are then used as leverage in back room deals to try to get the startups to use Microsoft's Messenger IM service to the exclusion of competing services.

Let's skip that though and talk about open and unencumbered protocols. Dare, I agree with you that we need these. I think that things like OpenID and OAuth are building blocks towards this, and I hope that we can discuss some of the hard issues at Social Graph Foo Camp. In the front room, of course!

Internet Identity Workship 2007b

I'll be at IIW next week, talking about Blogger, OpenID, OAuth, OpenSocial, and anything else that seems interesting. I'm anticipating a great event.