[Top][All Lists]
[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
- Re: [GNUnet-developers] Freenet 0.5, (continued)
- Re: [GNUnet-developers] Freenet 0.5, Brett Wooldridge, 2002/11/02
- Re: [GNUnet-developers] Java (was Freenet 0.5), Blake Matheny, 2002/11/02
- Re: [GNUnet-developers] Java (was Freenet 0.5), Brett Wooldridge, 2002/11/02
- Re: [GNUnet-developers] Java (was Freenet 0.5), Krista Bennett, 2002/11/02
- Re: [GNUnet-developers] Java (was Freenet 0.5), LCID Fire, 2002/11/03
- Re: [GNUnet-developers] Freenet 0.5, Glenn McGrath, 2002/11/02
- Re: [GNUnet-developers] Freenet 0.5, Brett Wooldridge, 2002/11/02
- Re: [GNUnet-developers] Freenet 0.5, Krista Bennett, 2002/11/02
[GNUnet-developers] Freenet 0.5, Jan Marco Alkema, 2002/11/06