Re: [GNUnet-developers] content duplication (was: update mechanism)

[Igor Wronsky]

On Sun, 18 Aug 2002, Thomas Formella wrote:

> | 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. 
> How about the idea of freeSQL (http://freesql.sf.net) Please replace
> 'freenet' or 'Freenet' with 'gnunet':

Sounds cool! ;) If there's really sufficient amount of people
who want to access Horace's database of Dalmatian Statistics, 
why not. 

What I meant was, for the sake of efficiency (and accessibility),
the prevention of the following scenario: lets say a person A, 
call him the Bane-of-all-Industries-WarezL0rd, "releases" 
some newest movie. Then person B thinks it a good idea to insert 
it by application 1 to gnunet, which uuencodes stuff. Person C 
feels the same, but uses yencoding program. Person D inserts 
it as a BLOB type to his world database of Dalmatian Statistics. 
Person E likes his movies zipped to floppy fitting pieces, 
and F is still using videocd's so he converts it to two MPGs.

Now, for someone to find and access the file, he needs 
one of those programs. Also the download will be prone
to increased unreliability, for instead of being able
to fetch blocks from any of the five nodes of the
inserters B-F (if they'd been using the same mechanism), 
he can rely only on one.

I don't say that people shouldn't be able to do
information hiding with weird application level tricks,
but that whether news or freesql or whatever will
be developed for gnunet, they imho should by default store
the files 'as-is', identically what gnunet-download does.
In a nntp style news app, for example, this might mean one 
or several header fields stating the hash/crc/size of
the "attached" files, the actual files being just
inserted "normally".


Igor