On Thursday 23 April 2009 06:16:40 am Matthew Toseland wrote:
> 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,97XjJekfSl8HxkJFYhj4cdo9n7s
>0exhE-EWMr8zuVxM,AAIC--8/chaosradio_142.mp3
>
> -> (something like)
>
> DHK at 97XjJekfSl8HxkJFYhj4cdo9n7s0exhE-EWMr8zuVxM,4~2FTXtBE2So8NZZIzneYrn5SOa
>FFk-hQsvjBHLc77A,ughDyCjP0jeBuRRx33nULUb4Pl-6Dk9DrDrH1miXCj0,VIOAKDzD~YIzrD5
>NBbD3v5SxOiwYXg84qQYdbkJA3bo,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?

I doubt copy-pasted keys that are long would pose a problem in most 
situations. But I can think of a couple of considerations:

1. It seems that when keys are posted on FMS (not so much frost), they often 
get chopped off at 80 characters, leaving the user to remove the newlines by 
hand. If the keys get long enough that 2 lines isn't always enough, then it 
might become hasslesome to undo the linebreaking (even if the linebreaking is 
due to misuse of the news client). Maybe the freenet web interface should 
notice extra newlines and remove them automatically?

2. How much bandwidth do keys take? Do they get sent with every packet? (I 
don't know much about Freenet internals yet, sorry!). If lots of users offer 
very little bandwidth each, would the extra key size mean potentially slowing 
things down?



-- 
Sincerely,
Jack Mudge
jakykong at theanythingbox.com

Reply via email to