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

[Toby Inkster]

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.

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