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

[Nick]

Hi Toby,

Thanks for this, it's very interesting for me in thinking how to 
build more distributed functionality into the platform I'm currently 
working on (http://code.google.com/p/splash-project - updates there 
soon), and very close (if more developed) to my own thoughts.

I do have a few comments and questions.

> 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.

I very strongly agree.

> 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.

Are you picking RSS here primarily because of the extensible nature 
of RDF? I recently flirted with Atom and RSS, decided atom was 
clearer, but then wanted to embed FOAF data and got stuck. Am I 
correct in thinking that by being RDF based RSS is inherantly more 
extensible than Atom thanks to being able to arbitrarily add 
vocabularies, or am I missing something similar in Atom?

> 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.

Why XHTML+RDFa, rather than separate RDFa and XHTML representations?  
Separating them has a couple of advantages to me. First, I'm 
transmitting less unnecessary data to an aggregator, but rather only 
the specific RDF requested. Second, decoupling the two gives us more 
flexibility in how people present their web profile, while still         
ensuring reliable and fast federation. So people could choose (or 
design their own) ways of displaying their webpage, whether as some 
'lifefeed' type web aggregator, a website with different sections 
(with 'blog', 'gallery' etc), a glorified address card, or something 
quite different.

The only necessary part of the web page would be a link tag in the 
head to a FOAF file, which itself points to all the resources etc 
available and shared (what's shown depending on authentication).

> The great thing about all this is that, even without any special
> 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.

I quite agree; as little as possible should be done on the server 
(at least should necessarily be done on the server). This aids the 
creation of plenty of diverse clients (web based and not), doing a 
range of things not originally anticipated. By pushing most of the 
functionality to clients we're giving people much more freedom in 
what they can imagine and do, rather than largely being contingent 
on the creativity of 'the daisychain project' to think about 
appropriate ways of aggregating and using friends' data. This, to 
me, is the real promise of distributed, decentralised social 
networking.

> For aggregating your friends' content, clearly a push model would 
> be
> more efficient than polling. Something like PubSubHubBub might work
> here.

I'm not enormously familiar with PubSubHubBub, but as it's server to 
server, presumably it only makes sense with web clients. So, well 
and good, but entirely optional depending on the choice of client.  

I look forward to hearing other thoughts on this.

Nick


-- 
GPG : 0x04E4653F           9732D7C7A441D79EFDF094F61F48567404E4653F