NoseRub

@Dirk

your quote:
"But I guess that this also would be the beginning of storing login data into NoseRub."

I assume access to other applications would be granted using a token (tied to both the user and the application), not using username/pswd
The oauth way, or the Google version of it...

From what I understand:

Part of the story is an on ongoing struggle between Facebook, Windows Live and Google to position themselves as THE "social graph hoster/owner". Facebook wants you to build apps within their site, Windows Live already has an api http://msdn2.microsoft.com/en-us/library/bb463989.aspx to give access to social contact info to outside applications, and Google will have one soon, as well as Linkedin.

I don't think any company will ever succeed in this, just like Passport was unable to impose itself as the universal identity hoster...

The other part I understand from the story seems more exciting to me:

"One way it will do that from the start is by creating two-way APIs so that any app created for Google can be taken to other Websites. ([...] the apps themselves will be portable). And data from other social sites will be able to be imported into Google's social apps as well."

Not sure what this all means: it might be as modest as Google-hosted widgets that show and let you choose your Google contacts, basically the equivalent of the already existing Windows Live contacts control: http://dev.live.com/contactscontrol/v0.2/default.aspx

But "any app created for Google can be taken to other Websites" might also mean that Google is going to open license this api and open source a/some implementations. That way, other social networks can give access to their "social graph" as well. If you create an application that is using Google contacts, you might as well point it to Twitter, and it will work with Twitter contacts (possibly Oauth will be part of the solution). So far, a standardised api for accessing your contacts from outside a social network has been lacking, and Google might give the first shot here.

Just a possible scenario: an travel application like Dopplr might ask you "who of your friends can see your travel schedule".

Then you might choose one or more of the social networks you're part of, and be presented with an interface with which you select some or more of your Gmail contacts and/or your Twitter friends and/or your msn/live.com buddies.

You would need to give Dopplr access to those lists, but for Dopplr, the implementation of accessing these different contact lists would be identical.

Anyone who would be able to prove to Dopplr (using OpenID or another remote authentication mechanism) that he/she is that particular Gmail contact or that Twitterer, would be able to access your travel schedule.

How about Noserub in this scenario? Noserub could implement this api too... Meaning that http://identoo.com/dirk.olbertz could login to Dopplr (using OpenID) and select http://id.thylmann.net/othylmann from his contacts list at http://identoo.com/dirk.olbertz/contacts/. The person able to proove that he is http://id.thylmann.net/othylmann (that would probably be Oliver Thylmann) would then be able to see Dirks private Travel schedule.

As far as I can see, Noserub could act like any other social network here, with the one difference that its identities are hosted on different servers.