This goes back two an old discussion we had before about how this is best implemented, but I have changed my mind a bit since then, mostly because the way that Inserts and Requests work have changed.
Here are a couple of things about this that I think are rather important: a) Disjoint Keytype subspaces If we are to have several different types of keys on Freenet, I think it is very important that when the routing it going on, Keys of different types can still be compared to one another. The reason for this is that we want to maximize the organization of the keyspace, and that will work better the more keys there are that can be compared to one another. SVKs, for example, would be rather rare on the network compared to the other types, but we still want their routing to take advantage of the organization of the keyspace brought about by requests for the other keys. It is also important, however, that a Request for one type of key, never return data for another type of key. For the sake of this I say that we should enforce that two keys of different types can never be equal. I don't seem to have a very easy time explaining this to people, as I keep hearing "But if I am searching for CHK and find a KHK with the same value, I will see that it doesn't match the hash", which is true, but consider another example. Say, hypothetically, that we implement one of the discussed voting systems for the value of a certain KHK. Since there _are_ issues with this, we would want people who did not like this to be able to use the old KHK as well. The easiest way to do this is to make the new vote-able KHK (call it say, dKHK) that can be voted on, but keep the old that can't. But we need to make it so that someone who Requests a dKHK can't get KHK indexed data back (because, in his opinion a normal KHK is just risking that it is non-sense), and that someone who Requests using KHK can't get dKHK indexed data (which in his opinion dKHK just reflects the censorship of the majority). So for this to work, you need to make sure that the type of key is in every Request and Insert for that key, and that the type that it has is always stored with the key, and taken into account when keys are compared. But that is EXACTLY the same thing as taking it into account the type in the key value. So what I want to do is enforce that keys end with a couple of bytes that give their type (end so that it will have the smallest possible influence on the routing). So a KHK might be "<hash value>0001" while a CHK would be "<hash-value>0101" and the hypothetical dKHK might be "<has value>0002" for example. And then Nodes would simply enforce that if the key ends with 0001 it has to be a KHK Insert/Reply message, and that if the key ends with 0101 it has to be a CHK Insert/Reply message, etc. b) The routing is the same. When we first discussed this, I claimed that we should make all the messages used to carry different types of keys identical, but that was probably not a very good idea (see, guys). However, now that the routing of the message and the sending of the data has been separated on Inserts as well as Requests, the DataRequest and InsertRequest messages can be identical for all kinds of keys, it is only the DataSend message, DataInsert and DataReply that will need to behave differently (being able to fail gracefully and restart the request when a hash doesn't match the CHK for example). On Fri, 21 Apr 2000, Lee Daniel Crocker wrote: > 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 -- Oskar Sandberg md98-osa at nada.kth.se #!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj $/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1 lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/) _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
