While I am still thinking about the utility of "searching", and
all of us are still imagining uses to which Freenet can be put and
what clients might be built for it, I think the following facts
are undeniable, and should be acted upon:
(1) SOME application of Freenet will require a CHK mechanism,
and there is no similar mechanism with the same properties.
(2) SOME application of Freenet will require an SVK mechanism,
and while there may be similar systems with the same properties,
none can be simpler.
Therefore, I think that regardless of debate on anything else,
these two features must be implemented and spec'd. For CHKs, I
propose that the header field "SearchKey.ContentHash" be used in
the same manner as SearchKey now, but a node that stores data
should validate the hash. Likewise, "SearchKey.Signature" can
be used for SVKs.
(As long as we're in the mood to change things--I'm not very
happy with "SearchKey" either: should be "PrimaryKey", but I'm
happy to leave that alone if I'm the only one bothered by it).
These two features alone, and no others, can be used to build
a rich, robust, and useful information medium--I can even see in
my mind how the client program might operate. If other features
need to be added later, that's still possible.
So the decisions to be made: what algorithms to use, how are
the keys encoded, and how is the data store organized to
accommodate the new key types?
--
Lee Daniel Crocker <lee at piclab.com> <http://www.piclab.com/lcrocker.html>
"All inventions or works of authorship original to me, herein and past,
are placed irrevocably in the public domain, and may be used or modified
for any purpose, without permission, attribution, or notification."--LDC
_______________________________________________
Freenet-dev mailing list
Freenet-dev at lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/freenet-dev
