Anecdotal evidence suggests that right now at least one third of our content persistence problems boil down to this one bug: "I added it 2 weeks ago and it still hasn't got past 0% (0/1)". A new key type, DHKs (Duplicated Hash Keys), would solve the problem, but the new keys would be twice as long as current CHKs. Is this a problem? I would really appreciate input from users, particularly those who upload and download files: - Is it a problem for the keys to be really long (twice as long as current CHKs)? CHKs are copied and pasted, so maybe not a problem? - Is it true that a great many downloads get stuck at 0% for a long time, showing 0 blocks of 1 if you mouseover the percentage?
Example: CHK at 4~2FTXtBE2So8NZZIzneYrn5SOaFFk-hQsvjBHLc77A,97XjJekfSl8HxkJFYhj4cdo9n7s0exhE-EWMr8zuVxM,AAIC--8/chaosradio_142.mp3 -> (something like) DHK at 97XjJekfSl8HxkJFYhj4cdo9n7s0exhE-EWMr8zuVxM,4~2FTXtBE2So8NZZIzneYrn5SOaFFk-hQsvjBHLc77A,ughDyCjP0jeBuRRx33nULUb4Pl-6Dk9DrDrH1miXCj0,VIOAKDzD~YIzrD5NBbD3v5SxOiwYXg84qQYdbkJA3bo,AAIC--8/chaosradio_142.mp3 GORY DETAILS: Currently we use: CHK@<routing key>,<crypto key>,<extra> (Filenames afterwards are manifests, and therefore impact on the CHK) 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). We might allow any number of routing keys from 2 upwards, for more redundancy at the cost of a longer URI, but IMHO 3 is a good default number. You would get such a key when you insert a file as DHK at . Arguably nobody ever types CHKs even now, and copy and paste allows for fairly long keys. Thoughts? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/support/attachments/20090423/6b272130/attachment.pgp>
