As Scott said, the current discussion is not about search entries (which have to be routed separately from the data, both for pratical and security reasons) but about metadata stored with data (which is encrypted and not visible to the nodes).
Scott doesn't think that we should run off an define a metadata format for all data on Freenet since task specific clients may wish to use whatever metadata format they want, but that we can say that if a piece of data contains only metadata and nothing else, we can assume it's something like a "Freenet control entry" for which we do have a specified format (FNP type field value pares) (the most obvious example of this are the redirects from KSK top KSS or CHK). Brandon rejects this elegant solution because of semantic objection (as far as I can understand it) that "metadata" linquistically implies that there is "data". I'm not sure if it would change his mind if we started refering to it is a "twinkletops" instead of "metadata".... On Sun, Aug 20, 2000 at 02:38:48AM +0100, Ian Clarke wrote: > O > > The only problem with encrypted metadata is that it will have to be > > changed to unencrypted metadata once searching comes along. > > Not nescessarily. > > I have been thinking about searching, and I think that the logical > thing is to have a new keytype which is basically a list of key/value > pairs which contain the metadata. This new key type will also support > fuzzy key specifications which will only be permitted as a searchkey > rather than as a key used for inserting. > > In the light of this (ie. the metadata actually being in the > searchkey), perhaps this metadata thread needs a rethink? > > Ian. -- \oskar _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
