> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of David Allen
> Sent: 27 September 2002 09:35
> To: [EMAIL PROTECTED]
> Subject: Re: [Tech] freenet search
>

<snip>

>
> > The first step is to rip apart each page into distinct
> > words. We are going to use each word as a freenet key
> > and the data associated to each key is the list of
> > locations that contained that word. In our simple
> > example we would have the following key/value pairs:
> >

<snip>

>
> Who controls the spider program?  Who are they, and why should
> we trust them?  Freenet's stability and power is in it's decentralized
> and anonymous nature.  This sounds like it would centralize the search
> process, which would either create a bottleneck, a single point of attack,
> or both.
>


This is probably totally incorrect,
but why not just decentralize the process and have the nodes do the
spidering while they're working?

(I'm basing this idea on the premise that nodes can decrypt the data they're
passing along as intermediate nodes in a chain...)

If each node randomly chose to decrypt the content and index it, then nobody
would have control over the indexing process.

The problems I see with this are:
1. How to issue search requests to nodes which have a likelihood of keeping
the index
2. How to spread commonly requested indexes without compromising anonymity.
3. I've probably hit some major problem already that compromises anonymity.

If I'm right so far,
then the answer to problem 1 would be to issue a request just like for a
normal key, except because there's no concept of reaching the 'end' of the
search, there would be a standard TTL on the request which is randomly
+'d,-'d,/'d and x'd as per usual by the nodes.
Each node that receives the search request randomly check's it's indexes and
if it find's results it forward's those along with the request to the next
node.

As the index would only contain key's pointing to the data, the only thing
you could tell if you got a result from a specific node is that some data
has passed through that node which matched (I think). And as the
result/request is a chain you shouldn't ever be able to know which specific
node tacked on a key to the result chain (unless you're the node which
tacked it on).

The second problem should just be a matter of propagation, with a random
decision on whether to forward the index down the chain or store it, so it
wouldn't even be possible to know which node had the index to begin with.

Good idea/bad idea?

It's probably got more holes than Swiss cheese, but one of these ideas has
got to help eventually :)

William.


_______________________________________________
Tech mailing list
[EMAIL PROTECTED]
http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/tech

Reply via email to