[Top][All Lists]

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

Re: [GNUnet-developers] update mechanism

From: Igor Wronsky
Subject: Re: [GNUnet-developers] update mechanism
Date: Sat, 17 Aug 2002 18:40:29 +0300 (EEST)

On Sat, 17 Aug 2002, Martin Uecker wrote:

> [1] idea: build a distributed news server on top of gnunet 

Nice idea. Make it compatible with existing nntp-readers and
you ensure that ignoramuses start sharing uuencoded files 
over gnunet. :( I think its very important that valuable
storage space is not wasted because same files are duplicated
in different splitting/encoding/archiving styles. You might 
think this comment a joke in bad taste, but such already 
happened in freenet.

Also, have you considered spam prevention? "Frost" messaging system
in freenet has proved very vulnerable to automatic flooding. Gnunet
key search mechanism is just as vulnerable, but that might
not be as bad - people can negotiate keywords between themselves, 
or publish the actual keys somewhere else. Besides, the actual
file retrieval does not suffer of flooding, because hash
clashes are still unlikely, and knowing the right key produces
the right file. But a global message forum can be much more
vulnerable, because the key needs to leak only once for that 
particular forum to be flooded and unusable. The good-willed
(non-flooding) participants should know the key, but malefactors 
shouldn't. Yet the forum probably should be available to new 

This was meant as just some food for thought. Anonymity
brings out old problems in a larger scale, and much more
out of control. There is no hope that the users of the
system will keep from doing nasty things just because 
they are good kids. They aren't.

The problem with a spammable message system is that
it can bring about lots of worthless traffic to the network:
not directly because of the people who flood, but because 
of the people who keep requesting the spam, in the hope
that there is one real message somewhere along them.


reply via email to

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