On Sun, Jun 03, 2001 at 01:25:14PM +0200, Stefan Reich wrote: > I see a problem with distributing the search queries and answers through the > network. > > In Freenet, requests for keys are not being broadcasted, but sent to a chain > of nodes
You don't say ;-) > If one of those nodes knows the key, the search > is successful. The direction the chain takes can also be influenced by > individual nodes if they know in which part of the network a specific range > of keys might be found. This is what makes Freenet scale. And the search mechanism I described takes advantage of the same mechanism. > How does this translate to fuzzy searching? Suppose we distribute the meta > information along with the data itself. Then, basically, the chance of > finding the metadata you're looking for is just as high as finding regular > files. Not sure what you mean by this. > But, for scalable metadata searches, we need nodes that specialize in > certain types of queries (automatically, just like specialization in Freenet > works for keys). This is probably feasible, but at least it requires a new > architecture; the mechanisms that Freenet currently offers don't suffice. So > I would say, separate fuzzy search from the Freenet core. Please read my proposal carefully, it works in pretty-much the same way as ordinary searching in Freenet. > Basically, Gnutella is trying to solve the same problem we're discussing > right now (except for the insert mechanism that doesn't exist in Gnutella). > So we could learn from their experiences. There experience has been a network which doesn't scale and lacks any anonymity. > Another thought comes to my mind (should have been a separate mail I > guess) -- it is not good if data and metadata are usually on the same node. > This will practically eliminate deniability. With metadata, you know what's > in your data store; without it, you don't. Did you even read my proposal? I discuss this. > But still, the situation is different when the metadata is delivered to your > node along with the data itself. Then you don't have to query any external > indices. You could even write (or be forced to write...) a simple piece of > code that scans the node for, say, *.mp3 and removes the corresponding > files. This is why I suggested in my proposal that metadata and data be treated separately, perhaps even in separate datastores. Ian. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20010603/a073f891/attachment.pgp>
