[freenet-dev] Solving "I queued it 2 weeks ago and it's still at 0%" : are really long URIs a problem?

[Arne Babenhauserheide]

Am Donnerstag 23 April 2009 15:16:40 schrieb Matthew Toseland:
> Arguably nobody ever types CHKs even now, and copy and paste allows for
> fairly long keys. Thoughts?

You know what I think. 

The length of the key doesn't matter to me, because freesites already hide 
them in links, and otherwise I just copy-paste them. 

I didn't ever watch my downloads long enough to say where exactly they stop. I 
just start them, and if they didn't finish in a week, I remove them again. I 
don't trust my memory enough to say much about the state. Many didn't even 
start, but I'm not sure in which state they were...

Best wishes, 
Arne
-- 
-- Ein W?rfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln.
-- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the 
history of free software.
-- My stuff: http://draketo.de - stories, songs, poems, programs and stuff :)

-- PGP/GnuPG: http://draketo.de/inhalt/ich/pubkey.txt

[freenet-dev] Solving "I queued it 2 weeks ago and it's still at 0%" : are really long URIs a problem?

[Matthew Toseland]

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@,,

(Filenames afterwards are manifests, and therefore impact on the CHK)

The new key type would be:

DHK@/

(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: 

[freenet-dev] Solving I queued it 2 weeks ago and it's still at 0% : are really long URIs a problem?

[Matthew Toseland]

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

Re: [freenet-dev] Solving I queued it 2 weeks ago and it's still at 0% : are really long URIs a problem?

[Arne Babenhauserheide]

Am Donnerstag 23 April 2009 15:16:40 schrieb Matthew Toseland:
 Arguably nobody ever types CHKs even now, and copy and paste allows for
 fairly long keys. Thoughts?

You know what I think. 

The length of the key doesn't matter to me, because freesites already hide 
them in links, and otherwise I just copy-paste them. 

I didn't ever watch my downloads long enough to say where exactly they stop. I 
just start them, and if they didn't finish in a week, I remove them again. I 
don't trust my memory enough to say much about the state. Many didn't even 
start, but I'm not sure in which state they were...

Best wishes, 
Arne
-- 
-- Ein Würfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln.
-- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the 
history of free software.
-- My stuff: http://draketo.de - stories, songs, poems, programs and stuff :)

-- PGP/GnuPG: http://draketo.de/inhalt/ich/pubkey.txt
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl