gnunet-developers
[Top][All Lists]
Advanced

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

[GNUnet-developers] Re: various suggestions


From: Krista Bennett
Subject: [GNUnet-developers] Re: various suggestions
Date: Mon, 29 Apr 2002 23:32:59 -0500
User-agent: Mutt/1.3.25i

Wayne Scott hath spoken thusly on Mon, Apr 29, 2002 at 10:30:18PM -0500:
> From: Krista Bennett <address@hidden>
> > If the content checksum were treated as just another root node keyword, I
> > agree that this might not be a bad idea. But then, users/developers could
> > do this anyway if they wanted, like any other "key" data. IMHO, this would
> > just move queries out of the system to some other media/software...
> > 
> > Or is there something I'm misunderstanding?
> 
> No I have read the encoding paper so I understand now.  You store a 1k
> rootnode for each keyword that stores a file.  So you can only search
> by those keywords, but you could have the file checksum be one of
> those keywords.

Right.

> 
> Now if I understand correctly, we are really just describing the
> libgnunetfilesharing.a layer built on top of gnunet right?  Really
> gnunet just exhanges 1k blocks of data that are indexed by arbitrary
> 160bit hashes.  So a application "could" store some indexing
> information directly and then retieve files with keywords.

Yup. An application above GNUnet which made some database of
keyword-checksum pairs (by registering the user's queries/replies,
sharing, or whatever) wouldn't really be any different than an adversary
sitting around making queries for particular keywords and recording some
corresponding unique feature of the file to be retrieved (checksum, root
indirection node hash index, length, etc) for blacklisting or other
diabolical purposes. The model anticipates this sort of thing.  Besides
(looking at the negative side of such databases), people that want to
insert things that they wish to hide aren't going to use an application
that shares its database anyway, and would probably further choose
non-obvious keywords to avoid the adversarial flavor of this kind of
keyword-file binding.

Of course, paranoid users may not want to have their queries and the
corresponding replies registered anywhere that might be expected to be
stored for longer than it takes to get a reply or might be accessible to
other people ;) This, however, is at the user's discretion when
choosing/building an overlying application. Caveat emptor.

GNUnet itself simply sees the hash corresponding to some block, sends it
out as a query, and receives the reply, so you're right. An application
"could" store some indexing information directly (checksum, or whatever)  
which it would have to retrieve from some external source (or from files
the user has on his own drive). GNUnet itself moves 1k hash-indexed blocks
around in response to hash-based-queries of either keywords or content
hashes without knowing (or caring) which. Anything thing else above that
is application-layer frosting (no pun intended).

> 
> 'frost' from freenet could actually work much nicer on gnunet...
> 

I haven't looked at it, but will sometime soon if Christian hasn't ;) 

- Krista





reply via email to

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