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...
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.
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.
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.
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:
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.
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.
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!
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.
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...
Which would let you do authenticated cross-domain requests.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"
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.
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:
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.
