Social networking as an API

A little while back, Sean had the insight that social networks should be a feature, not a service. I think he was right, but I’ll go him a step further and say social networks should be an API, not a feature. Rather than the current state of affairs, where some slice of your social network is represented on every site you participate in, all of your social network would be consolidated in one place of your own choosing. This approach is being referred to as a “distributed social network,” but that strikes me as a misnomer. The current fragmented situation is also distributed, just along a different axis.

My idea is inspired by the concept behind OpenID: basically, that you’ve got one “identity server” and use your credentials on that server to log in everywhere. All identity servers speak the same language, so when you’re trying to log in somewhere, as long as it knows how to communicate with any identity server, it can communicate with yours.

Your social network could function the same way. In fact, it would make sense for your OpenID server to also be the central repository for your social-network information. While this wouldn’t be necessary, it simplifies things, and for the rest of this entry, I’ll be assuming it’s the case.

So how would this work?

Suppose Alice uses myopenid.com as her OpenID server, and Bob uses supermegaopenid.com as his. Alice wants to mark Bob as a friend. So on her “my friends” page at myopenid.com, she adds a link to Bob’s page at supermegaopenid.com. This triggers myopenid.com to send a request to supermegaopenid.com, which lets Bob know “Alice has marked you as a friend. Do you reciprocate?” Bob chooses yes or no. If he chooses yes, Alice is added to his “my friends” page, and a message is sent back to Alice’s account at myopenid.com that they’re mutual friends.

So what do you do with this friendship information? Lots of websites are already using social-network information as a sort of role-based permissions system. On del.icio.us you’ve simply got contacts that you track; on flickr you’ve got contacts, friends, family, and friend+family; on twitter you’ve got people you follow, with some gradations of how closely you follow them on a person-by-person basis.

With a list of friends, a list of websites, and social-networking features on each of those websites, you’ve can construct a 3-D matrix of permissions.

  My blog Flickr Del.icio.us Twitter
Bob Comments on my blog:
Are not allowed
Are moderated
Are published immediately
I follow their pictures
Can comment on my pictures
Can add notes to my pictures
Can add tags to my pictures
I follow their posts I follow their posts
I follow their posts via IM/SMS
Carol Comments on my blog:
Are not allowed
Are moderated
Are published immediately
I follow their pictures
Can comment on my pictures
Can add notes to my pictures
Can add tags to my pictures
I follow their posts I follow their posts
I follow their posts via IM/SMS
Ted Comments on my blog:
Are not allowed
Are moderated
Are published immediately
I follow their pictures
Can comment on my pictures
Can add notes to my pictures
Can add tags to my pictures
I follow their posts I follow their posts
I follow their posts via IM/SMS
Alice Comments on my blog:
Are not allowed
Are moderated
Are published immediately
I follow their pictures
Can comment on my pictures
Can add notes to my pictures
Can add tags to my pictures
I follow their posts I follow their posts
I follow their posts via IM/SMS

Obviously with a lot of friends, maintaining all these different permissions could get overwhelming. Roles are useful way to simplify permissions. Rather than setting permissions for each friend separately, you can set them for a group of friends all at once. Having a core set of roles that everyone starts off with would be a good idea—flickr’s simple categories—contact, friend, family, friend+family—are intuitive and useful. XFN specifies a more complex and layered set of relationships that might be useful for some, overkill for others. But beyond some base level of pre-defined relationships, individuals should be able to define their own relationships, including “person I’m calling a friend because I don’t want to alienate them, but don’t really know or care much about” (aka the “myspace friend”). This means inevitably that a lot of relationships will be asymmetric, but I don’t see that as a big problem.

The role-based approach presents another problem: you may want to assign someone to an existing role, except change their permissions for one service. For that, it would be useful to be able to drill down to the list of individuals and set one person’s permissions as “friend, but different in this one way.” This would create some implementation problems that I’m going to ignore for the moment.

In terms of how you’d deal with all this, it’s possible that you’d view all your relationships and services through a matrix view at your openID server similar to the one shown here. Whenever you changed your permissions setup for one website, your OpenID server would contact that site and notify it of your new settings. It’s also possible that you’d view your relationships for a given site through that site, but it simply would be acting as a narrow window onto the overall matrix. Or both.

Implementing social networks through a mechanism similar to OpenID should make it easier for more sites to add useful social-networking features, give individuals better control over their social-network information, and lead to interesting results.

Update: Looks like Google is all over this already—and it’s the OpenID inventor behind it.

Update: The Appleseed Project looks very closely aligned to what I’m proposing.

Leave a Comment

Your email address will not be published. Required fields are marked *