On Sun, Dec 31, 2000 at 03:03:07PM -0800, Aaron Voisine wrote:
> It definately makes more sense from a deniablity standpoint to
> use a dropthrough encryption algorithm on the KSK first.
We are smarter than we look ;-)
> As far as being a broadcast, I understand that's bad, but I
> figured with caching and low hops to live, it would be no worse
> than any other data request.
The primary means of ensuring scalability isn't really caching so-much as
intelligent routing.
Here is how I think searching should happen:
We define a function that, given a list of key/data pairs (metadata
describing the content) A, and given two other pairs, B and C, it can
determine which of B and C is closer to A*. There are an infinite number
of ways that this could be achieved, but the closer it is to what a human
might do, the better. Someone did write some code which did this but I
have no idea where they went.
Once you have done this, you can treat the metadata for a piece of
information as a key, and can route requests towards that key.
The only remaining change is that, right now, a key will only be
retrieved if you find it exactly, where as that is not going to happen in
most cases with metadata searching. We need a new "Find Closest" message
which will return a list of the closest keys to the one being sought
encountered by the search. This would be returned to the user who would
then select the one they want to try to retrieve.
* In actual fact it will be more complex than this, since this comparison
is likely to be a costly computation we will want to cache and
precompute whatever we can
Implementing searching will be great fun - if anyone wants to do
interesting stuff with Freenet, I suggest that you attack this. To begin
with, you can start to think of good ways to do a fuzzy match of key/data
pairs to another set of key/data pairs. Of course, if you wanted to be
super-smart, you could figure out a way to do a fuzzy match to an SQL
statement (which rather than returning "yes" or "no", returned a measure
of how close the match is).
Ian.
PGP signature
