gnunet-developers
[Top][All Lists]
Advanced

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

Re: [GNUnet-developers] Namespace discovery+navigation


From: Christian Grothoff
Subject: Re: [GNUnet-developers] Namespace discovery+navigation
Date: Fri, 12 Dec 2003 18:42:10 -0500
User-agent: KMail/1.4.3

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 12 December 2003 01:22 am, Tom Barnes-Lawrence wrote:
> I felt like starting another discussion on informal protocols and
> such things:
>
> Since the namespaces thing finally got into GNUnet, I've been interested
> to actually see some reference to someone's namespace. But I never have.
> I've found a couple of directories, which was nice and interesting, but
> still no namespaces.
>
>  From my discussion a few months back with Christian, and from reading
> the new ECRS paper a couple of days ago, I understand that the only
> ways you can actually *get* a namespace key, is:
>
> -By some out-of-band means
> -Be the one who creates it (really counts as the previous method)
> -Find it referenced in a directory
> -OK, also have some plain-text file or something shared across GNUnet,
>  which is more or less equivalent to the directory method but a bit
>  stupid really)

Right.  There is one other possibility: gnunetd can 'snoop' namespaces by 
seeing a namespace reply pass by.  gnunetd can then 'learn' the namespace, 
but it would of course still not know any contents in it.  And it is only a 
passive approach in that it requires any of the above -- snooping can not 
occur unless someone *else* requests something in that namespace.  Note that 
snooping will only reveil the existence and ID of a namespace but not the 
contents that were transferred.

> So, to try the only real in-band way of finding a namespace, I tried
> doing a search for "directory". Found some directories, but no
> namespaces. Perhaps there are none yet. But that's not important.

What I think is most likely is that the manual effort of creating namespaces, 
placing files in them and building directories with the data is too high -- 
especially compared to the keyword-based approach with the convenience 
offered by libextractor...

> Point is, as the main way of using GNUnet will probably involve the
> namespaces (so you can largely stick to content you can reasonably
> trust not to be spam), people will need some reliableish way to
> get access to a decent number of namespaces.
>
> My first informal-protocol proposal:
> Choose some key that people can advertise their own namespaces on.
> Keys are advertised by a directory with just one entry, that is a
> file in their namespace (thereby containing their namespace key).

Why limit to just one entry?  Why not allow people to advertise any number of 
entry-points into their namespace?  Sure, that'd make the directory a bit 
larger, but I see no good reason why we should recommend against placing 
multiple links into this entry-point.

> Suggested keywords for these adverts: namespace, namespaces, or
> namespace-adverts

How about namespace-YEAR (as in 'namespace-2003').  Namespaces are 
particularly good for content that is updated, but as everything, they are 
likely to be abandoned sooner or later.  So to avoid accumulating endless 
amounts of useless namespace advertisements, adding some timestamp should 
reduce this problem (for now, YEAR should be sufficient, MONTH can be added 
once we start to see lots of new namespaces all the time). 

> Adverts would not be placed automatically, in case people want to
> keep their namespaces largely hidden, but perhaps a simple utility
> program could be made to create them (or perhaps a command-line option
> for the pseudonym creation command).

I think this might make sense together with some description of what the 
namespace is supposed to be for ("my kitten collection namespace") that 
contains some guidelines on how to 'guess' keywords in the namespace ("search 
for kitten by name"). 

> Then, as these will probably get a bit crowded (and may get badly
> spammed), there could be a higher-level version, whereby some people
> can put up similar directories, but this time with lots of entries,
> each one being into a different namespace. A bit like a little
> "yellow pages" type thing. Of course, whatever key this went
> under would also probably get spammed too... but you have to
> start somewhere.
> Suggested keywords: namespaces, namespace-collections,
> namespace directory or namespace-directories.

I think this second level is probably only useful in the form of some 
well-known human editors that collect namespaces (in their namespace), as 
opposed to some standardized mechanism.

> Second issue:
> It's been pointed out that the directories and namespaces system
> helps to allow GNUnet to be almost like the WWW. This is very neat.
> But people are used to web hosts having heirarchical directories
> (well, OK, so nerds are). Whilst GNUnet's directories can actually
> be arranged into pretty much any structure, it might be nice for
> people to be able to think of a namespace as having a "root"
> directory, that can have a hierarchy of other directories under it.
>
> This root directory could then be expected to have a sort of
> standard set of things in it and some of its subdirectories,
> that people should be able to recognise.

I'm not sure how much structural recommendations are really going to be 
helpful.  Feels like overkill to me, just like writing style-guides for WWW 
pages.

> so,
> My second informal-protocol proposal:
> People (who want to play nice) should insert a directory into
> their namespaces under the keyword "root", or "root-directory".
> This could also be the item that they use for a reference into
> their namespace in their adverts.
> This root directory could (should?) contain a directory of
> references to other namespaces as described in the first
> proposal, in order to expand upon that "yellow-pages" notion,
> but with the advantage that it shouldn't be full of spam.
> This should mean that once somebody has one or two namespace
> references (for non-spammers, at least), they should be able
> to get lots more of them easily.
>
>
> So: thoughts, anybody?

Some good ideas, but I believe some of them would be more useful in the form 
of software-wizzards ('build a namespace') than in the form of informal 
standards that don't necessarily help people to actually create conforming 
namespaces.

> Now, before I say any more, can I ask this:
> Am I right in saying that the contents of any directory that
> is downloaded, and the results of any search attempted, are
> stored in a database, and can be redisplayed with
> gnunet-directory-listdb? Only if so, it seems to work now,
> but didn't seem to when I tried it a few months back, for
> some reason.

And it will stop working again when you use CVS :-).  Ok, basically, GNUnet 
now has an option to turn on storing all of the above in a little DB.  In 
0.6.0a, it was 'always on', to make it easy to build directories with 
gnunet-gtk.  Since this leaves privacy-critical information in plaintext on 
your disk (until you run gnunet-directory-emptydb), it is now (CVS) turned 
off by default. 

> Are directory contents stored in it as soon as they're downloaded,
> or is it only after they're parsed with gnunet-directory-print?

That depends on what you use for downloading (gnunet-gtk should do it 
directly, gnunet-download waits until you -directory-print it).

C
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE/2lJS9tNtMeXQLkIRArRLAJ0erunf1k1nz908rb1fKCK3FIChAACeI2N/
bitmZ6MxieSne6SyoCCsFK0=
=91y/
-----END PGP SIGNATURE-----





reply via email to

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