Social Network Portability
Posted to the social-network-portability list, August 21, 2007.
From what I've been seeing thus far (and it has been great discussion) I'm seeing a set of three basic functionalities that need to be offered.
First, social network portability
Not coincidentally the name of this list. But what does it mean? Not an aggregation of all social networks in the world or anything like that. Think of a person's personal social network on, say, Facebook. A list of friends.
In the first instance, we want a consistent way of identifying those friends. That's what OpenID is for. Each person who is one of my Facebook friends should have an OpenID. Which means is that what we want is a way of associating existing accounts, such as a Facebook account, with an OpenID. From the perspective of Facebook, this probably means a plug-in application. Other social networks will roll this their own way. On my own site I simply ask people to log in with their existing account, and then (while still logged in) log in with their OpenID account.
Then, thinking of a social network as (essentially) a list of OpenIDs, we need the following:
a) a way to export this list from any social network. This means, in essence, a simple SN feed. Since OpenIDs are URLs, it could be as simple as an RSS feed or an OPML. I think of it in my own mind as RSSN (Really Simple Social Network) which looks exactly like RSS except the link element is an OpenID.
It could also be a FOAF feed (though I echo the comments about it being a pain to work with). Something like Anthony Romano's openfriendfinder/foaf would be a great tool to support this (until the various social networks supported it natively).
It should also support authenticated access (even though the whole userid password thing in RSS aggregators is a pain). Because the idea here isn't so much to broadcast one's social network to the world. That's a separate function. The object here is to have some way of allowing someone to get their own social network from a site.
b) (optional) a way to work with these lists. An RSSN or OMPL or whatever mix and match. Maybe a way to edit the thing by hand, if I want. A way to add attributes (that would be useful for OPML as well, so I could tag my RSS feeds as 'canadian' or 'British' or whatever - but I digress). The main thing is, I can aggregate one or more lists of OpenID URLs into a space, and then merge them and edit them as I wish.
c) a way to import this list into a new social network. This is the big payoff. I don't need to add my friends, one by one, into the new social network. I just import my list.
A few people have talked about the properties of these lists. Are they 'follow' lists, for example, or the names of people I am following? We could probably come up with some basic types, based on (say) communication capacities. 'People who can send me stuff (aka 'whitelist')'. 'People I want to send stuff to (aka 'subscribers')'. 'People who are both.' 'People I actively check for posts (aka 'feeds'). And so on.
But we don't need to define this. Different social networks export different kinds of lists, and we can lable them as we export them. Different social networks will deal with lables differently. This is how we differentiate between different social networks.
Some people have been talking about the (web-wide) social graph. That's not part of this. We don't need that for this. This is simply a matter of me being able to manage my own lists.
Second, attribute portability
We've seen discussion of this in the OpenID community under the heading of 'attribute exchange' http://openid.net/specs/openid-attribute-exchange-1_0-04.html which has been concerned mostly with fetch and response requests.
We also saw discussion on this list with the proposal for a 'Rich About Me' page for WordPress sites. And, of course, FOAF is not only about lists of friends, it's also a way of describing oneself. FOAF combines all this into a single document. But there's no need to do so; we could have several lists of OpenIDs (friends, enemies, lovers, etc...) and the URL for each list becomes an attribute.
Essentially, what we're looking at here is a profile generator that can work with OpenID providers. What would work best is a 'standard' profile generator that we can just shoot to a site when we do a one-off contact with it (like making a comment). This avoids the need for all the allow-deny dialogue. I have often thought of an RSP format (Really Simple People) that looks a lot like an RSS item - the basic elements (name, link (with is an OpenID, of course), description) plus a set of optional elements (how hard would it be to come up with a list? we don't even need a canonical vocabulary).
My list of people could use RSP for each person I'm in contact with. I could collect attributes about you. Not just the ones you send me (though that would be useful) but also attributes other people send me. (See my paper Resource Profiles http://www.downes.ca/files/resource_profiles.htm for much more on multi-party metadata).
Personally, I think that among the most useful attributes will be service URLs. For example, suppose you comment on my website. If I want, I could require that you actually post the comment on your own site. What I would need to make this work is the address for your blog upload service. Then my application accepts your comment and sends it to your blog software's API. Or if you register for an event on my website, if I know the URL for your calendar service, my application accepts your registration and sends the notation to your calendar.
Third, network traversal services
In the discussions thus far people are thinking of nifty applications for social networks. Like message white-listing. Or a bookmark search service, that will go one, two, or whatever degrees away through (published) sets of connections.
These services are based, not on actual lists of friends, but on published lists of friends. Published lists are different from personal lists. For example, an 'RMail' service could work based on each person publishing a list of OpenIDs from whom they are willing to accept mail.
There may be more 'whole network' services, but for the most part, I think they will be the least important of the applications. Yes, there will always be a Google or a Technorati trying to create a view of the world as a whole. But I think the real power of social network portability will be giving us a view of our own neighbourhood - and letting people in that neighbourhood get a view of us.
I hope this was useful.
From what I've been seeing thus far (and it has been great discussion) I'm seeing a set of three basic functionalities that need to be offered.
First, social network portability
Not coincidentally the name of this list. But what does it mean? Not an aggregation of all social networks in the world or anything like that. Think of a person's personal social network on, say, Facebook. A list of friends.
In the first instance, we want a consistent way of identifying those friends. That's what OpenID is for. Each person who is one of my Facebook friends should have an OpenID. Which means is that what we want is a way of associating existing accounts, such as a Facebook account, with an OpenID. From the perspective of Facebook, this probably means a plug-in application. Other social networks will roll this their own way. On my own site I simply ask people to log in with their existing account, and then (while still logged in) log in with their OpenID account.
Then, thinking of a social network as (essentially) a list of OpenIDs, we need the following:
a) a way to export this list from any social network. This means, in essence, a simple SN feed. Since OpenIDs are URLs, it could be as simple as an RSS feed or an OPML. I think of it in my own mind as RSSN (Really Simple Social Network) which looks exactly like RSS except the link element is an OpenID.
It could also be a FOAF feed (though I echo the comments about it being a pain to work with). Something like Anthony Romano's openfriendfinder/foaf would be a great tool to support this (until the various social networks supported it natively).
It should also support authenticated access (even though the whole userid password thing in RSS aggregators is a pain). Because the idea here isn't so much to broadcast one's social network to the world. That's a separate function. The object here is to have some way of allowing someone to get their own social network from a site.
b) (optional) a way to work with these lists. An RSSN or OMPL or whatever mix and match. Maybe a way to edit the thing by hand, if I want. A way to add attributes (that would be useful for OPML as well, so I could tag my RSS feeds as 'canadian' or 'British' or whatever - but I digress). The main thing is, I can aggregate one or more lists of OpenID URLs into a space, and then merge them and edit them as I wish.
c) a way to import this list into a new social network. This is the big payoff. I don't need to add my friends, one by one, into the new social network. I just import my list.
A few people have talked about the properties of these lists. Are they 'follow' lists, for example, or the names of people I am following? We could probably come up with some basic types, based on (say) communication capacities. 'People who can send me stuff (aka 'whitelist')'. 'People I want to send stuff to (aka 'subscribers')'. 'People who are both.' 'People I actively check for posts (aka 'feeds'). And so on.
But we don't need to define this. Different social networks export different kinds of lists, and we can lable them as we export them. Different social networks will deal with lables differently. This is how we differentiate between different social networks.
Some people have been talking about the (web-wide) social graph. That's not part of this. We don't need that for this. This is simply a matter of me being able to manage my own lists.
Second, attribute portability
We've seen discussion of this in the OpenID community under the heading of 'attribute exchange' http://openid.net/specs/openid-attribute-exchange-1_0-04.html which has been concerned mostly with fetch and response requests.
We also saw discussion on this list with the proposal for a 'Rich About Me' page for WordPress sites. And, of course, FOAF is not only about lists of friends, it's also a way of describing oneself. FOAF combines all this into a single document. But there's no need to do so; we could have several lists of OpenIDs (friends, enemies, lovers, etc...) and the URL for each list becomes an attribute.
Essentially, what we're looking at here is a profile generator that can work with OpenID providers. What would work best is a 'standard' profile generator that we can just shoot to a site when we do a one-off contact with it (like making a comment). This avoids the need for all the allow-deny dialogue. I have often thought of an RSP format (Really Simple People) that looks a lot like an RSS item - the basic elements (name, link (with is an OpenID, of course), description) plus a set of optional elements (how hard would it be to come up with a list? we don't even need a canonical vocabulary).
My list of people could use RSP for each person I'm in contact with. I could collect attributes about you. Not just the ones you send me (though that would be useful) but also attributes other people send me. (See my paper Resource Profiles http://www.downes.ca/files/resource_profiles.htm for much more on multi-party metadata).
Personally, I think that among the most useful attributes will be service URLs. For example, suppose you comment on my website. If I want, I could require that you actually post the comment on your own site. What I would need to make this work is the address for your blog upload service. Then my application accepts your comment and sends it to your blog software's API. Or if you register for an event on my website, if I know the URL for your calendar service, my application accepts your registration and sends the notation to your calendar.
Third, network traversal services
In the discussions thus far people are thinking of nifty applications for social networks. Like message white-listing. Or a bookmark search service, that will go one, two, or whatever degrees away through (published) sets of connections.
These services are based, not on actual lists of friends, but on published lists of friends. Published lists are different from personal lists. For example, an 'RMail' service could work based on each person publishing a list of OpenIDs from whom they are willing to accept mail.
There may be more 'whole network' services, but for the most part, I think they will be the least important of the applications. Yes, there will always be a Google or a Technorati trying to create a view of the world as a whole. But I think the real power of social network portability will be giving us a view of our own neighbourhood - and letting people in that neighbourhood get a view of us.
I hope this was useful.
Hello, Stephen,
ReplyDeleteAn interesting summary/commentary --
One of the uses I've been thinking of along these lines includes the use of actual rss feeds as personal attributes -- so, an individual could specify a social feed (ie, the Onion), a professional feed (their work blog plus bookmarks), a personal feed (their personal blog, or a calendar) -- Using OpenID, they can specify what gets shared with what sites, and in this way the act of creating a network becomes a low-end remixing engine --
AX brings a lot of opportunities into the mix
I wrote about this a little while back.
Cheers,
Bill