[foaf-protocols] P2P FOAF search

Melvin Carvalho melvincarvalho at gmail.com
Tue Jun 9 15:27:47 CEST 2009


On Tue, Jun 9, 2009 at 8:20 AM, Luke Maurits<luke at maurits.id.au> wrote:
> 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.

yes, I agree that this is well-suited to having a number of
specialists that have a good list of data

we have a few already, examples include

qdos
sindice
swse (deri)
google search api
any other examples in the LOD cloud?

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

agree, we should aim not to tie ourselves too closely any particular
protocol, except perhaps, for DNS and RDF (which seems largely
unavoidable), however to get a proof of concept running using
something like XMPP could work well, and also end up being an
acceptable standard

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

I believe Dan is working on this, I think it will be a semantic media
wiki, so we could draft something quite easily transferred over when
it is ready

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

it is a bit manual (i think requires a shell scipt to act as a bridge
to your triple store), and would probably work well with about up to
half a dozen nodes, but you probably need something more scalable and
portable longer-term, so im not sure if it's worth the time
investment, it is a technique I will probably personally try out, but
any approach is fine by me

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

my original thought was just to send a list of triples as part of the
SPARQL insert/update

I'm not that well versed on the intricacies of SPARUL, so perhaps
someone could advise a good data exchange protocol here, or reuse some
existing work?

Security is a key factor, but I'd probably personally be able to
consider the attack vectors more easily, once we had something in
place.  I think FOAF+SSL could play a role as well as web access
control.  Also I think scoring and ranking will be important on a per
client, and global basis.

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

This makes sense also, but since a triple is just a list of three
URIs, it seems like a compatible approach that can take place at parse
time, then the client can determine whether they are seeing pointers
to other resources or actual dereferenced data.  Again the client will
need to work out what it trusts.

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