help-gnunet
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-gnunet] how fast should gnunet be?


From: Igor Wronsky
Subject: Re: [Help-gnunet] how fast should gnunet be?
Date: Fri, 30 Aug 2002 13:36:22 +0300 (EEST)

On Fri, 30 Aug 2002, Christian Drechsler wrote:

> b) how fast should downloading be? i never managed to download a file at
> all - once i got some 700 bytes (out of about 4 mb), all other attempts (i
> tried ca. 10-15 downloads) never yielded a single byte for hours - some
> were running several days.

My personal opinion is that if some intelligent mechanism
can't devised to let user know about content availability,
the best option is to emulate edonkey. This does not require
any changes in gnunet. What I mean is two things:

a) Out-of-band www server listing content and their <hash,crc,size>.
   The www listings could be moderated by some suitably lenient party.
b) Dedicated hosts serving the listed content.

That should be a good start. Anyone with some bandwidth could do 
it. The common excuse for running such a site is just claiming
that it does not distribute actual content, but only information
related to it. I think that on the german gnunet page (see links on 
gnunet homepage) there's a forum for publishing keys, but that does 
not help much if the inserters do not support their content 
by keeping their gnunet nodes up long enough for the content
to be distributed to other nodes. Eventually any popular
content should be able to survive on its own, but that does
ofcourse not happen if it has never been downloaded from
the original node except for the root block. And just that
root block is currently enough to make it stand out as a 
result in searches. :(

I know that a) poses an anonymity problem. Of course
submissions could be sent anonymously, making the submission 
channel (email, gnunet, ??) vulnerable to spam. Or the site
could be run by some evil organisation, publishing keys
as they see fit.


I.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]