wanderingstan

It’s long overdue.

Almost 4 years ago I started to get excited about what could be done with a social graph (or network, as we called ‘em back then). My head swam with possibilities of a real trust network: get product and company reviews , prevent spyware and check validity of files, control process execution, and of course use your network for trusted searching. That last one let to the development of Lijit, which was been my life for the last 3 years.

I never imagined how hard it would be to actually get a graph. The “big guys” of MySpace and Facebook sealed their users’ graphs in TOS-protected Silos, and users grew wary of re-friending on every new web service. Open standards like FOAF and XFN were there, but no one really used them. It was beginning to look like social graph innovation would be limited to whatever the big guys wanted to allow.

So I’m excited about Google’s new Social Graph API. There’s a still a long way to go, but maybe with Google’s weight other services will allow users to publish their graphs and be available to this API.

Google went big by using the information in the Web’s link-graph. What exciting new tools will be possible when we have real access to the social graph?

Related: Not all links are created equal

Today I’m going to a local mini-conference to discuss “Social Graph Unification”, a topic that’s been hot the past few weeks. It’s exciting to think that you could unify your friend lists across Facebook, MySpace, and Gmail. But we should not be content with a mere synchronizing of friend lists. Friend lists are merely one class of data that you might like to have synchronized. (In fact, I think it’s stupid to have your replicated across different services, but that’s a post for a different day!) Here is a rough sketch of the different types of data that you might create online these days, across all services. The question for today is, how many of these would you like (or be comfortable with) being synchronized?

Interesting dimensions to think about:

Pointers vs. Raw Data: Identities and Relationships are not data themselves, but point to other data sources.  Profile and Content are data in themselves. Bookmarks are a type of content that is a pointer to other content.

Serialized vs. In-Place: Profile data is typically not serialized, but Content data is. Some fields are in flux between them: E.g. Twitter showed that “Status” could be serialized, and other companies are trying to serialize “Location” (So that you could a feed of someone’s location history.)

Push vs. Pull: Blog posts are messages that are put out there for anyone to ‘pull down’ are read. Emails are messages ‘pushed’ directly to someone else.

Also interesting to think of the coverage that different services achieve. General purpose social networks like MySpace and Facebook cover almost all most of these types of data. Other services have carved out specific niches: LinkedIn does a little bit of profile data, business contacts, and email. Twitter does a little bit of profile information, subscriptions, and status. Flickr does a little bit of profile information, subscriptions, friends, photos, and email. 

Will people remain content to have this data scattered across services? Will syncronization enable this? How the hell do you manage permissions across all of this!? I’ll let you know how the conference goes!