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

[Toby Inkster]

On Fri, 2009-10-23 at 09:44 +0100, Nick wrote:

> 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 seem to remember having heard about this project before. I live just
around the corner from the University of Sussex's campus. (For those
people wondering how the second sentence is relevant to the first, visit
the splash project link.)

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

Note that I specifically said RSS 1.0 rather than just RSS. The RSS 0.9x
versions are a bundle of confusion, and RSS 2, despite the version
number is just a continuation of that line. Atom was mostly designed to
be a blank slate to escape from that mess. 

However, used properly, RSS 1.0 is a different kettle of fish
altogether: it's based on the RDF data model rather than the XML data
model.

RDF and Atom have different extensibility models. Atom is extensible in
a way: it follows the usual XML extensibility model, whereby everything
you don't understand, you ignore.

RDF, though often serialised in XML, is not a type of XML. (Many think
it is.) It has a very different extensibility model in that all data is
handled the same way, so generic processors don't need to ignore
anything. If you create a new RDF vocab, then all generic RDF tools will
support it out of the box - serialisers, parsers, databases, query
engines, etc.

This is important for distributed social networks because the kind of
data fields that, say, a group of friend who are all bee-keepers, and a
group of friends who are all violinists, will be interested in are
probably going to be quite different. But using the RDF data model means
that even if the bee-keepers' data gets passed through the violinists'
database and out the other end, it will come out unscathed.
Round-trip-ability.

Atom doesn't have that kind of extensibility. If you add a few custom
tags in different namespaces to an Atom entry, process the entry through
a few Atom tools that don't know about those namespaces, and spit
something out at the end, it's unlikely that those custom tags will have
survived.

Atom's extensibility is not a bad model, it's just not as useful (in my
opinion) for doing the kind of things needed by a distributed social
network.

Though that's not to say that individual nodes on the distributed
network shouldn't publish their content as Atom (they probably should -
as far as compatibility with real world feed readers goes, it's usually
better than RSS 1.0) -- but it's probably not going to work as the
backbone of node-to-node communications like RDF could.

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

That just seemed the easiest method to suggest. In practise, I'd hope
that implementations would support a variety of different formats for
output and input, possibly using connection negotiation to switch
between them. (I've got a pretty good PHP library for connection
negotiation that I'd be happy for the project to use under the AGPL.)

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

Precisely. What I'm suggesting is not so much a distributed social
networking protocol, but a collection of tools to simplify implementing
RESTful, semantic publishing practises which already work today.

(Well, plus a small but of protocol to handle friendship requests.)

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

I'm not especially familiar with it either, but it seems like it might
do the trick. XMPP also has a pubsub solution as I remember, and I think
Dave Winer's been talking about something similar for a while too.

XMPP might not be the right solution for a PHP project hoping to run on
cheap, commodity web hosting though; and PubSubHubBub seems to have
more traction than Dave Winer's idea, so that's why I suggest it as a
starting place for investigation. OMB also uses some sort of push model
for passing notices between sites, so that may be a place to look as
well.

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