On Thursday 23 April 2009 17:25:11 Dennis Nezic wrote: > On Thu, 23 Apr 2009 14:16:40 +0100, Matthew Toseland wrote: > > GORY DETAILS: > > > > Currently we use: > > CHK@<routing key>,<crypto key>,<extra> > > > > (Filenames afterwards are manifests, and therefore impact on the CHK) > > Isn't the first part supposed to be the data hash, and not a routing > key. And what is a routing key anyways? :P
The routing key is the hash of the encrypted, padded data of the block. > > How does the filename impact the hash again? Filenames are interpreted as manifests. This is necessary because a CHK does not have a filename. Having an optional filename would make it ambiguous whether that filename was a file in a CHK freesite, or whether it was a meaningless optional filename. A new key type can have a mandatory filename, and thus solve the problem. > > > The new key type would be: > > > > DHK@<data hash>,<routing key 1>,<routing key 2>,<routing key > > 3>,<extra>/<ignore filename> > > > > (A filename is mandatory, and is always ignored, so does not impact > > on the rest of the key). > > So the DHK filename part is mandatory, but is simply a recommendation? Yes. Hence the same data with the same mime type and the same level of redundancy will always yield the same DHK (up to the slash). > So, if the filenames here don't impact on the hash, this should help in > the case where the same file gets uploaded with different filenames? Yes, although such files would share the blocks anyway, it is more efficient if we always have the same key. > (Ie., from your description of CHK filenames above, differently named > files each have different manifests, and thus waste both disk space and > key space?) But the real gain is redundany in the top block. And the real cost is a longer URI. This is not a big problem?
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Support mailing list [email protected] http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:[email protected]?subject=unsubscribe
