Re: [GNUnet-developers] Search wildcards, and the mail archive

[Igor Wronsky]

On Fri, 3 Jan 2003, Nathan Lutchansky wrote:

> >  I'd already sort of guessed that GNUnet probably wasn't able to
> > return every file stored on a node, but I'd wondered about using
> > specific keywords such as "SOMETHING" or "ANYTHING" or "WHATEVER"
> > to give files so that they would be likely to turn up if a user
> > just wanted some sort of a broad sample of various things (sort of
> > like the test content, but more the sort of things that people
> > might want)- or maybe things that people thought were worth getting.
> Not a bad idea.  There could be an issue with having a great deal of
> content indexed under the same keyword, but I don't know how the keyword
> indexes are designed.  Maybe more descriptive keywords like "PUBLICDOMAIN"
> or "FREELYDISTRIBUTABLE" would be better, since they describe a specific
> subset of content that should be legal to posess in most free countries.
> Another mechanism along the same lines would be some sort of persistent
> "announce" protocol, kind of like the chat protocol, except that messages
> would stick around for a set amount of time.  Then gnunet-insert(-multi)
> could automatically announce the availability of new files using messages
> that persist for, say, 48 hours.

There are basically two ways to address the annoucement
thing. The trivial way is nice and gnunetish (==passive ;) ),
it requires almost no additional coding. The non-trivial
way is open. I'll discuss the trivial way first.

For starters, its not a good idea in the long run to index lots
of stuff with the same keyword (for example, its likely that
searching for popular mimetypes will eventually return only
obsolete or unavailable content - that is because the oldest
blocks are propagated best), but what could work is to choose
some keyword format for announcements, like

ADVERTISEMENT-$DAY-$MONTH-$YEAR

and then make the insertion tools (optionally!) to add that
keyword to the list of used keywords. Similarly the search
client could have an option to search for the current keyword
(perhaps with some specifyable offset of days). User community
could even do that with just wrappers, without any support
from the devteam, and/or use different prefixes
for different styles of content.

I'm not sure what the nontrivial way would be. The easy
solution above can be spammed. Also the fact that search
results are in no way connected to content availability
keeps bothering me. The current habit of forever finding
results for files that have not been around for ages will
eventually ruin the search mechanism for all sensible
keywords.

TBL talked about possibility to look for just 'some matches'.
This is slightly disagreeing with the principle of deniability:
gnunet is designed in a way that the node operator can claim
deniability of the nodes content because there is no easy
way to find out whats in there - he'd have to guess the
right keywords. So a mechanism to return just some results
would in a way try to do that, it'd have to guess keys that
it doesn't know... but I'm tired and can't think clearly at
the moment, e.g. about extending the current underlying
framework, what would be its implications. For example
ability *not* being able to deny search results might
actually be bad, because although we could claim that
we are giving just a 'pointer' to the actual data, not
the actual data, what then if blocks of the actual data
were in the same node's cache. Phew. I should take a nap.

Further comments? Suggestions? Ideas?


Igor