Re: [Help-gnunet] Questions on latest version

[Christian Grothoff]

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

On Monday 01 September 2003 12:21 am, Tom Barnes-Lawrence wrote:
> On Sun, Aug 31, 2003 at 04:27:35PM -0500, Christian Grothoff wrote:
> > >  So basically, did Nils' patch get included in the end?
> >
> > Yes, but it was recently (post 0.5.5) moved to the libextractor CVS. It
> > will be in the next libextractor relase and was part of 0.5.5. The 0.5.5
> > default config file has the appropriate line:
> >
> > EXTRACTORS =
> > libextractor_filename:-libextractor_split:-libextractor_lower
>
>  Aha! So the automatic extraction supplies lower case versions of keywords
> (all keywords?)... but the AFS system itself doesn't actually convert
> keywords itself?

Right.

> I suppose as long as there aren't keywords that are hard-to-find because
> of case variations (except by people who are actively trying to make
> their content hard to find), that should be fine.

That's why we picked the libextractor solution: you get to pick and can still 
easily manually override.

> > > -So I understand that it's namespaces that allow updates, and it's
> > >  directories that allow you to create heirarchies.
> > >  But how do the directories reference stuff?
> >
> > They contain RBlocks or SBlocks in plaintext (the file-identification
> > plus meta-data). Insert a bunch of files and go into gnunet-gtk. Build a
> > directory "by hand", you should see that it is quite easy.
>
>  I tend not to bother with gnunet-gtk much, I'm afraid; I had another
> look this release, but it didn't seem any more stable. So I'm still
> working with gnunet-insert- or hoping to.

Hmm. I haven't seen gnunet-gtk crash in a long, long time. Maybe you could 
bother to report what is going wrong? For me, it has been rock solid for the 
last versions (what GTK version are you using???)

>  BTW, yeah, I remember some months back saying *I'd* try to write some
> client-side stuff... I haven't given up on that, I just, er, got
> sidetracked when I started writing a game :P It didn't help that almost
> every approach I'd wanted to take, countless obstacles seemed to get in
> my way. But other projects I got working on recently helped me think
> of solutions for some of those things, so I could mebbe have another go.
> (I'm making no promises this time, if it happens it happens)

Well, I've started refactoring the code to make it easier to write GNUnet 
clients (see the new gnunet-util include file in current CVS). The goal is 
that after installing gnunet *with* headers, you can easily compile and link 
code against the GNUnet libraries without integrating everything with the 
GNUnet CVS/build system.  

> > >  I'm basically wondering, if I make a directory entry that links to a
> > >  directory in someone else's namespace, when that remote directory gets
> > >  *updated*, will the reference to it from my directory access the one
> > >  it found originally, or the newly updated one??
> >
> > Ok, someone else has a directory D in a namespace X under the
> > namespace-key K.  Now when you create your own directory O which can
> > contain either a direct link to D (which means that if D is updated, your
> > link will still point to the OLD contents, which is what you may want);
> > or you can link to K in X, which means that your directory will point to
> > the updateable version of the directory.
>
> Um, lets see. "the namespace-key K", would be the key for the directory D,
> rather than a key used with everything in X? And K would be the Sblock?

Let me try again. We have a directory which contains whatever. That directory 
is identified uniquely (without updates, this version) with a file identifier 
"F". The user providing the directory put this directory under keyword "k" 
into the global namespace, creating the RBlock "R" (which contains F plus 
some meta-data and which will be found when searching for "k").  The user 
ALSO added the directory to his namespace "X" under the namespace key "T". 
"T" is like "k" a keyword, just that  "T" is not in the global namespace but 
in the private namespace "X".  Inserting the directory into the namespace "X" 
under key "T" created an SBlock "S" containing "F" and meta-data, such as the 
identifier "N" of a possible future update update.

If another user wants to refer to the directory, he can add to his directory 
either
a) the RBlock "R" which knows nothing about the namespace and which will 
continue to refer to the original version of the directory D
b) the SBlock "S" which will by the nature of containing N also refer to 
future versions of "D"
c) BOTH the RBlock and the SBlock (just for the heck of refering to both the 
updateable and the immutable version of the directory).

Better? We're currently trying to write a nice description of this whole 
scheme for an updated version of the encoding paper, so better docs are 
hopefully going to be available soon.

>  Just before writing this email, I tried having a go at creating a
> pseudonym, to see if I could learn a bit in the process. Gnunetd wasn't
> running (because I was offline), and it just sat there, even though the
> pseudonym utilities didn't mention they needed it (some things obviously
> need it, but not *all* of them do, right?). When I reconnected and started
> gnunetd again, I then tried creating the pseudonym again...
> and it segfaulted.
>
> [New Thread 1024 (LWP 3014)]
> Sep  1 05:28:37 WARNING: No password supplied
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 1024 (LWP 3014)]
> 0x4002c04f in rndlinux_gather_random (add=0x4002ba7c <add_randomness>,
>     requester=2, length=120, level=1) at rndlinux.c:131
> 131             FD_SET(fd, &rfds);
>
> Don't know if that's enough for you to do anything with (or if you've
> already seen this bug).

Has already been reported and a patch has been available at 
http://www.ovmj.org/GNUnet/download/patch-gnunet-0.5.5-rndlinux.c since 
August 24th.

>  Well, in the meantime, it'd be interesting to know, gnunet-insert's
> manpage says:
> -t ID, --this=ID
>        Specifies the ID of the  SBlock.   This (snip)
>
> I don't understand what this is referring to, or what this flag will
> do. I can see it's to do with namespaces, and maybe is about updateable
> content, but otherwise... *shrug*

"this" refers to the "T" in the above example: set the key for the current 
(this) version of the document.  Similarly, you can set "N", the identifier 
that you are planning to use in the "N"ext update.

> The manpage continues:
> The  ID  can  be  given in HEX notation, otherwise the HEX
> code is derived by hashing the given ID string.
>
>  Where would I get either of these things? Are these what get returned
> from gnunet-pseudonym-create, when it works? I suspect not, but it's
> just not that clear.

No, they have nothing to do with the pseudonym. Think of them more like of the 
keywords used in the global namespace. "T" and "N" are the "keywords" in the 
local/private pseudonym-authorized namespace.

> > Essentially, every directory (and file) can be accessed in two ways; with
> > an RBlock (the old, keyword, immutable mechanism) or via an SBlock (the
> > new, additional, optionally updateable, signed mechanism). Directories
> > can refer to both RBlocks and SBlocks.
> >
> > Does that help? (Note that gnunet-gtk's visualization of the difference
> > between RBlocks and SBlocks is, well, lacking.)
>
>  It helps to at least know that both those types of reference are
> technically possible, even if the docs make my eyes water ;)

Patches are welcome (or you can make your FAQ even more valueable by 
explaining what I obviously can not explain :-).

>  Perhaps it would help if the CLI programs separated what they did
> somewhat- I notice some manpages point to the non-existant manpage for
> the non-existant program "gnunet-insert-sblock", but now all content
> insertion operations seem to be integrated into gnunet-insert.

Which, believe me, makes it actually easier to use. At least once it's 
documented :-).

>  I suppose that if you make a directory, you'll want to insert it
> (maybe you'd want to make separate directories to create heirarchies
> by hand, rather than relying on the -r flag, but it'd be no use without
> having all the directories published), but when you try to create/
> insert the directory at the same time as inserting what it refers to,
> it all gets a bit unclear what's going on IMHO.

The problem is, that this is the only practical way to get all of the 
file-identifiers straight. gnunet-gtk allows you to freely compose 
directories from files inserted earlier. A GUI is the only good answer to a 
drag-and-drop build-my-directory problem. I just see no good way to do this 
with a simple CLI.

>  And then the addition of namespaces/updatable content seems to make it
> even less clear: EG, what if you're making an updatable directory that
> references some non-updatable content that you're inserting now, plus
> some updatable content that's already been inserted, etc etc.
> I expect gnunet-insert is able to do all this, I'm just saying that
> maybe a more modular interface could be easier to understand. Or
> perhaps it wouldn't.

Easier to understand, maybe. Easier to use, definitely not. Also note that 
gnunet-insert still can NOT do everything that the system may allow you to do 
(like insert a file into your namespace of which you only have the file 
identifier). gnunet-gtk actually can do that, but it currently does not allow 
you to specify "N" and "T". While I'd like both tools to be able to do 
everything, it'll take some more time to get there.

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

iD8DBQE/U9RT9tNtMeXQLkIRArMiAJ0S+6/u0QHu/m4mZqLDQztCGC45MACfQH6c
einAT6eKrNO8WUOOl2xvZQE=
=/Nm5
-----END PGP SIGNATURE-----