[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Social-discuss] A missive - thoughts on a distributed social networ
Re: [Social-discuss] A missive - thoughts on a distributed social network
Fri, 23 Oct 2009 09:44:35 +0100
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
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
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
> For aggregating your friends' content, clearly a push model would
> more efficient than polling. Something like PubSubHubBub might work
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.
GPG : 0x04E4653F 9732D7C7A441D79EFDF094F61F48567404E4653F