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: c...@4~2ftxtbe2so8nzzizneyrn5soaffk-hqsvjbhlc77a,97XjJekfSl8HxkJFYhj4cdo9n7s0exhE-EWMr8zuVxM,AAIC--8/chaosradio_142.mp3 -> (something like) d...@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 d...@. Arguably nobody ever types CHKs even now, and copy and paste allows for fairly long keys. Thoughts?
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl