gnunet-developers
[Top][All Lists]
Advanced

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

Re: GNUnet design issues (was [GNUnet-developers] Freenet 0.5)


From: Krista Bennett
Subject: Re: GNUnet design issues (was [GNUnet-developers] Freenet 0.5)
Date: Wed, 6 Nov 2002 20:03:58 -0500
User-agent: Mutt/1.3.25i

Jan Marco Alkema hath spoken thusly on Wed, Nov 06, 2002 at 08:24:50PM -0800:
> 
> In mine opinion Gnunet can be improved by :
> -     the integration of a cdrecord program. All Cd?s, Dvd?s (distributions)
> must automatically be identified.

???? identified by what and for what? Clearly, if someone wanted to 
integrate this into a particular application, they could, but this is 
certainly a peripheral issue...

> -     the use of trusted third party concepts.

As mentioned in my previous e-mail, if you want to run your own server 
through which others you trust (and who trust you) can download, certainly 
you can arrange that; as an overall scheme, though, this goes directly 
against what makes GNUnet work. The whole idea of GNUnet is to trust no 
one and to avoid centralized servers. If we wanted to rely heavily on 
trusted third parties, we'd be something entirely different, and worse for 
it.

> -     different portable GUI?s for all platforms (Java, Windows API, etc.).

This, again, depends on what you mean by GUI, what it interfaces to, what 
you intend it to do, etc. The current GUI code is written in gtk, for 
which there IS a windows port.

> -     transport and the level of encryption depending on the information. For
> example the photos of the summer camp have not to be encrypted. They can be
> spread on the Gnunet with ?ftp speed?. Mail text encrypt with x number key.
> Attachments and streaming video encrypt with y number key (y << x).

If you don't want the overhead of encryption for things that don't need to 
be encrypted, then you always have the option of using a different 
(faster) transport mechanism outside of GNUnet...

> -     first zip than encrypt. Before file transfer the file should be zipped.
> The zip should be depending on the bytes in the file. Maybe another zip
> program is needed for jpg files than for text files.

The user can always do this before insertion. It's his issue, really, 
IMHO.

> -     The use of banking transactions for coordination means to give priority 
> to
> the requesting file transfers.

Again, we already do this...

> P.S. Weak things can be transferred to strong things and the other way
> around. The strong thing of encryption of all files can, under certain
> circumstances, be overdone.

Sometimes, yes, but given the goals of this network, encryption is vital. 
All data should look equally random. See Tracy's comment...

I think a careful review of the papers will show our motivation behind a 
lot of these things :)

Cheers...

- Krista

-- 
***********************************************************************
Krista Bennett                               address@hidden
Graduate Student
Interdepartmental Program in Linguistics
Purdue University

         If at first you don't succeed, try again. Then quit.         
             There's no use being a damn fool about it.
                           -- W.C. Fields




reply via email to

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