Re: [Social-discuss] A missive - thoughts on a distributed social network

[Melvin Carvalho]

On Thu, Oct 22, 2009 at 1:00 AM, Toby Inkster <address@hidden> wrote:
> Darling everybody,
>
> I promised Matt that I'd pop my head in and provide my thoughts on
> distributed a social network. I think it's a great idea, but alas I
> don't think I have any time to contribute to it in any practical way, so
> my thoughts are all you're likely to get.
>
> When I first started using the Internet it was via AOL. Our family used
> that for a year or so before moving to a real ISP. That experience
> taught me that walled garden social networks are not a Good Thing.
> Consequently, you'll find me on very few of them. I don't have a
> Facebook account; I don't have a Myspace account; I think I have a
> del.icio.us account, but have not really used it. Because I don't have
> much experience using "social network sites", I think perhaps I might
> bring a different perspective to this discussion, based on different
> preconceptions of how a social network should behave.
>
> I'd also like to state that my interests lie not so much in building
> social networks, but making our existing network more social.
>
> Moving swiftly on, here are my thoughts on how *I'd* approach building
> something like daisycha.in, if I were in charge, and if I had the time.
>
> Firstly, federation is a must. I should be able to run my own account on
> my own server, and connect up with other people running software on
> their own servers, or shared servers.
>
> Another feature is extensibility. This is entangled up with an idea that
> Dan Brickley's been going on about a bit recently - the idea that geeks
> shouldn't decide how everyone describes themselves. For instance, say
> that in our federated network, two servers need to exchange profile
> information about their users: there will be fields like "name",
> "avatar", "email" being passed about. The protocol designers shouldn't
> decide which fields are allowed and which are optional. The end users
> should, or at the very least, the people running the servers should.
> What fields are important to you and me might not be important to other
> people.
>
> Privacy and security are important, and related. I should be able to
> share data with my social network, reasonably confident that it won't be
> leaked outside my circle - at least, not without a conscious decision
> from one of my friends to deliberately pass it on. (Clearly, this last
> possibility is always going to be a privacy hole - there isn't a
> sensible technical fix for it.)
>
> Anyway, those are fairly abstract ideas, but important to state. Now for
> more practical matters. What should this distributed social network
> actually do?
>
> Firstly, I'd want to publish profile-type information about me. Some
> profile information I want to be public, so people can find it (perhaps
> through Google). Other profile information I want to only be available
> to my friends, or maybe just to a subset of them.
>
> Secondly, I want to publish items of content. These might be short,
> microblog-like bits of text; they might be photos, videos or audio
> clips; they might be links to things I've found on the Web. Again, some
> of these I might elect to make public, and others I'd want to keep
> private.
>
> I want to, of course, be able to view my friends' profiles, and be kept
> informed of the items of content that they publish, in some sort of
> aggregated view, so that I don't need to go and visit each of their
> pages individually.
>
> Lastly, I'd need a way to manage these friends and contacts. A way of
> blocking access from some people; a way of establishing a relationship
> with others.
>
> So what would a web application that let me do this actually look like?
> Here's my suggestion. It would consist of two loosely-related parts:
>
>        1. A publication tool;
>        2. A feed aggregator.
>
> Each of these would be functionally fairly independent, though for
> usability's sake, they would probably provide a fairly integrated user
> experience. A third part of the platform which would need to have ties
> to both is an API for adding and approving friendships.
>
> Using the publication tool I'd publish my profile data and content
> items. The publication tool would allow me to configure access control
> to different bits of data. This wouldn't have to be tricky ACL-type
> stuff: a mere "this is public"/"only my friends" drop down would cover
> the majority of use cases.
>
> Crucially the publication tool would be outputting the data using FOAF
> and RSS 1.0, embedded in RDFa. Using RDF gives us our extensibility -
> RDF is a framework built to represent data of all kinds. There's a whole
> host of off-the-shelf libraries, parsers, databases, query engines and
> so on that it opens up. Specifically for daisycha.in I'd recommend ARC2,
> a PHP+MySQL RDF toolkit.
>
> The output XHTML+RDFa files would be simply published to a location on
> the public Web, albeit with the non-public ones using HTTP
> authentication. This would be Googleable and could indeed not only act
> as your social networking profile but as your personal web site as well.
>
> The aggregator would visit the XHTML+RDFa-enabled profiles of all your
> friends, parse their information and present it in a unified view for
> your consumption. As these people have confirmed your friendship, your
> aggregator will have access to their private profile data and content
> items too.
>
> Those parts are actually pretty easy. We're left with two gaps:
>
>        1. Managing friendships;
>        2. Push updates of new content.
>
> To manage friendship, OpenMicroBlogging's method might be a possibility,
> but it's not really intended for symmetrical relationships. Here's
> another possibility...
>
> Assuming Alice and Bob want to become friends; their profiles are hosted
> on separate sites. Alice finds Bob's profile through Google and copies
> and pastes hist profile's URL into her friendship manager. This
> publishes a friendship "claim" to her profile (i.e. her profile says
> that Alice claims to be Bob's friend). Alice's friendship manager then
> pings Bob's server. Bob's server receives a ping from Alice's server and
> fetches Alice's profile. It notes the friendship claim and puts that in
> a queue of claims to verify for Bob. Next time Bob logs in, he sees the
> claim and approves it. Bob's server pings Alice's to let it know the
> friendship was approved. Alice's server lists Bob as Alice's friend. It
> returns a success message to Bob's server. Bob's server gets the success
> message and adds Alice as Bob's friend.
>
> For aggregating your friends' content, clearly a push model would be
> more efficient than polling. Something like PubSubHubBub might work
> here.
>
> The great thing about all this is that, even without any special
> software at all, you can join in the social network. If you only want to
> publish public profile and content data, then you can make do by
> publishing static XHTML+RDFa files. It's only once you get into the more
> complex area of making friends that you need to have any server-side
> scripting involved.
>
> Anyway, that's how I'd do it, if it were me.

+1

Great post.  I think this is the way to go.

>
> --
> Toby A Inkster
> <mailto:address@hidden>
> <http://tobyinkster.co.uk>
>
>
>