On Apr 23, 2009, at 3:11 PM, Evan Daniel wrote: > > I suggested the obvious extension of this on IRC. Instead of simple > searching at location + 0.25, you search at location + n/N, where n is > which copy of the block you're looking for, and N is the number of > copies inserted. > > Toad didn't like this because it makes top blocks identifiable to > everyone on the routing path, and involves network-level changes. The > other approaches can be implemented at a higher level as a translation > before handing a normal CHK request to the network. > > Evan Daniel
The problem... How to find a 'top block'... either (1) we have to already know about it on-fetch (long chk uri) (2) it needs to be derived from existing fetch data (like my idea) (3) a new mechanism needs to be made (like ssk-top-blocks/matthew's- multiplier idea) At this point, I'm greatly favoring Matthew's idea of multi-content- hash/ssk keys. However, some alternative names to try on... Reliable Fetch Key RFK Reliable Hash Key RHK Multiple Hash Key MHK Multi-link Key MLK Matthew's Multiplier Key MMK On Apr 22, 2009, at 7:48 PM, Matthew Toseland wrote: > UMK,N@<H(data)>,<extra>/<filename> > (Where N is the number of copies inserted) And maybe with "N" in the extra data so as to not introduce a new syntax... it is still fetch-time data after all! > MMK@<H(data)>,<extra:N>/<filename> -- Robert Hailey -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20090423/a9c82dd0/attachment.html>
