Hola!
> this brings to my mind WebID (aka foaf+ssl) > I think WebID attacks a different problem. It assumes you have somewhere trusted to host your public key. As i understand it, if someone hacks the server where you publish your WebID, then he can put another public key there, and go online pretending to be you, right? Or did I misunderstand that? I want to trust no servers in my setting. That's why I think I can't use WebID. regarding privacy exposure in FOAFs, you can apply ACLs based on inference > rules > about trust. So you don't have to show same doc to everybody ;) > ok cool i hadn't thought of that. still, i prefer fabric-based rather than social-graph-based, if at all possible. > distributed search, yeah, that's the big issue. > > with all the hype about resurrecting finger by means of http, some people > thought that, given a grid of personal rdf stores (or even rdf-over-dht), > and even protecting results via foafssl if you want, the goal could be > accomplished by routing this "simple" SPARQL query: > > @prefix : <http://xmlns.com/foaf/0.1/> . > SELECT ?profile WHERE { ?person :mbox "mailto:foo...@example.com"; . > ?profile a :PersonalProfileDocument ; > :primaryTopic ?person . } > > ... > > this scenario sounds to me quite close conceptually to what you propose. > take webid fingerprint and start communicating (using your cert to > sign/cypher/authenticate). > yes; although I don't exactly know how such a SPARQL query would be routed by a DHT (presumably you route through effectively a DHT of email->profile pairs?), at least the part about finding a chain of signatures looks conceptually very close. > > So what I came up with was to define a "fabric"-approach. We define a > > multi-dimensional space in which all guids represent a fixed position. > Your > > coordinates in the fabric are determined not by you, nor by who you > interact > > with, but simply by the ASCII bits in your guid string. And then it's > simple: > > everybody sign the keys of their neighbours and vice versa to form the > fabric. > > not sure I understood this properly. every node should sign their > "neighbors" > in this metric space? > > > Now to know your public key, I just walk from my position in the fabric > to > > yours, following the chain of neighbours that are all 'holding hands', > and so > > everyone's connected with everyone. > > don't get how do you traverse a path. chosing the geodesic in this > coordinate system? > OK sorry, my description there was too simplistic. Let me try to explain it better: - each user keeps a list of neighbours. - You start with one user with an empty neighbour list. - When the second user joins, the two users become neighbours in the following way: - calculate the sha1 of each guid. Think of these sha1 hashes as strings of bits. - see the position of the first bit position in which the two strings are different. Say the first 3 bits are the same, and the 4th one is different. Then each of the users accepts the other one in position 4 of his neighbour list. The "quality as neighbour 4" is the position of the second bit that is different. So if position 5 is the same, but 6 isn't, then both now have a neighbour for position 4, of quality 6. - Naive implementation of neighbour-finding (only for explanation purposes): - Whenever a user is added, compare it one-by-one with all existing nodes. A neighbour is accepted for a position if the node did not have a neighbour yet in that position, or if the new candidate has a higher quality. - traversal from a string $A to a string $B: - $current = $A; - for($i = 0; $i < length($A); $i++) - if $current[$i] != $B[$i] - $current = $neighbour[$current][$i] the traversal will always arrive at B (you could add a break statement in case you get there early, even). if current doesn't have a neighbour i, then that means no guid exist whose sha1 is a candidate neighbour 1 for current. i don't really compare a newcomer to all existing nodes, obviously, that wouldn't scale. only to roughly one node for each bit in the hash. but i hope it's simpler if i leave that part out. Re. the problem, I think webID community tries to solve same problem you see > (although semweb community has a je-ne-sais-quois that makes their > proposals to > be dismissed many times withouth a second thought). > correct me if i'm wrong, but as i understand it, WebID assumes you have a hosting server somewhere that you trust not to be hacked. I don't have that in my application. I don't want to trust the server. > > About the fabric approach, surely I didn't grasp it fully, but if the > answer to > last two questions is yes, I think I see a flaw :P > ok, please let me know! :) many thanks for your help with this! Michiel.
_______________________________________________ p2p-hackers mailing list p2p-hackers@lists.zooko.com http://lists.zooko.com/mailman/listinfo/p2p-hackers
