[foaf-protocols] P2P FOAF search

Luke Maurits luke at maurits.id.au
Tue Jun 9 08:20:57 CEST 2009


Sorry I've been silent on this front for a bit.  I got a little
flummoxed when I learned that it's either not possible or not
straightforward to do honest P2P networking with XMPP (i.e. messages
travel directly from one endpoint to another and not via an
intermediate server).  It turns out the thousands of pages one can find
via Google that talk about "building P2P apps using XMPP" are actually
talking about implementing P2P *protocols* over a client-server
network.  This was not what I had in mind at all so my train of thought
got derailed and I ended up spending a lot of time on my foaflib
project instead.

Returning to P2P FOAF search, I'm actually not convinced that this is
really much of a problem.  It certainly makes things easier.  Node
discovery is the most complicated part of a true  P2P network and doing
away with it makes our work easier.  It should be possible to one day
have 5 or so "super clients" which are always on and which most
regular clients have at least one of on their friend list.  These big
clients could even locally store the most commonly returned results,
etc.

There are, of course, downsides - someone needs to have an XMPP account
just to do a search, which feels kind of wrong, but it might work as a
proof of concept, anyway.  If we were to be really careful we may
even be able to draft the actual protocol at a sufficient level of
abstraction that we could have a genuinely P2P non-XMPP network
coexisting with the XMPP proof of concept.

I'm really hanging out for the revival of the FOAF project Wiki so we
can start fleshing out some actual details on there.

Anyway, as for this:
> A possible approach:
> 
> 1. You have a set of triples on your machine (in a triplestore or
> maybe sqlite file)
> 2. You run Pidgin client over XMPP
> 3. Add a "buddy pounce" to your friend, which executes a command when
> someone writes to you
> 4. Parse the text someone has sent you, and check for a search request
> 
> 5. Check the access control of your friend (JID or FOAF) over your triples
> 6. Query the store for authorised triples
> 7, Reply back with the search results (SPARQL insert?)
> 8. Your friend parses the reply and add them to his triple store

Sounds like a simple enough way to get something very basic working,
although I'm not sure how much work would be involved in getting a
portable buddy pounce based solution working.

Re point 7 (and this applies to the idea in general, not just the
experimental light versions), I think we should discuss the motivation
for sending results back in the form of a SPARQL insert.  If we did
this it would be extremely tempting for client developers to simply
execute the query the received in the response message, because this is
so much easier than parsing up some other response format and building
their own SPARQL query.  But I worry about the security sensibility of
this.  We don't want to invite "SPARQL-injection" attacks.  There's
also the question of verifying the accuracy of the returned
information.

Part of me feels like a better solution would be to have
response messages include publically accessible URIs for RDF documents
describing foaf:Persons matching the request criteria.  The client
which originally performed the search could fetch the documents from
that URI and verify for itself that the criteria are indeed met before
updating its own triple store.  This means that (i) nothing should end
up in anybody's triple store as the result of a search unless it was
downloaded from an "authoritative" source, (ii) response messages
contain a list of URIs which is much less prone to security issues than
a SPARQL insert, (iii) response messages are probably shorter - 20 URIs
for FOAF profiles can be serialised much more efficiently than SPARQL
insert statements sufficient to put 20 foaf:People into a store.

Thoughts?

-- 
Luke Maurits <luke at maurits.id.au>
http://www.luke.maurits.id.au
http://www.luke.maurits.id.au/foaf.rdf
CompCogSci | Crypto | Maths | Python | Unix


More information about the foaf-protocols mailing list