[Top][All Lists]

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

Re: [GNUnet-developers] gnunet-guile reboot & guix

From: Amirouche Boubekki
Subject: Re: [GNUnet-developers] gnunet-guile reboot & guix
Date: Sat, 13 Jan 2018 10:26:44 +0100
User-agent: Roundcube Webmail/1.1.2

On 2018-01-13 01:49, ng0 wrote:
Amirouche Boubekki transcribed 1.5K bytes:
Héllo all,

I restarted from scratch the gnunet-guile bindings. It was made
much easier thanks to the work of ng0 on gnunet documentation and
guile-bytestructures to handle C structs and unions.


I think I need to know what's the plan/design for gnunet/guix
integration to continue.

If you want a (relative) unprocessed summary of its history, it's
collected in here
(org-mode recommended):

Here is an extract relevant to the current discussion:

* Design of guix/gnunet integration

So I can see two milestones now, as we discussed before:

1. Create a variant of ‘guix publish’ that publishes over GNUnet’s
file sharing (FS) service, using the neat bindings that you wrote.

For that you can literally copy guix/scripts/publish.scm as a
starting point, and simply remove the HTTP-related code (which is a
small fraction.)  The rest will be mostly identical: narinfo
meta-data generation, signing.  I guess it will be easy to test it
using gnunet-search and similar tools.

As a 2nd step, we’ll see how we can refactor things to allow code
sharing between the existing ‘guix publish’ and its GNUnet variant.

2. Create a variant of ‘guix substitute’ for searches through GNUnet.
Again, a large part of the code is about narinfo and signature
checking, and it can be reused.

I’m not completely clear on how search for substitutes will work,
though.  Currently, when the user wants to build /gnu/store/xyz, ‘guix
substitute’ simply fetches  How will
that work with GNUnet?  Are we going to look up their /gnu/store file

I’m not completely clear on how search for substitutes will work,
though.  Currently, when the user wants to build /gnu/store/xyz, ‘guix
substitute’ simply fetches  How will
that work with GNUnet?  Are we going to look up their /gnu/store file

I’ve considered a solution for that: GNUnet allows one to create
specific namespace and publish files under this namespace. Unlike
publishing under the “global namespace” where keywords are used to
identify a file, when publishing under a specific namespace files are
identified with a choosen identifier. Moreover, as a namespace is
basically a cryptographic key pair, and publishing a file under your
namespace means signing, one’s assured nobody else will publish under
her or his namespace. By the way, the private key associated with a
namespace is named “ego” or “pseudonym”.

It’s easy to test this feature:

# create a `test` ego/namespace
$ gnunet-identity -C test

# list the known egos in the form: `name - public key`
$ gnunet-identity -d

# index the file `foo.txt` under the `test` namespace
$ gnunet-publish -P test -t foobarbaz foo.txt

# find the file `foo.txt`
$ gnunet-search gnunet://fs/sks/M2OC987U9LFJHQ8LC9SLCV4…/foobarbaz
gnunet-download -o "foo.txt" gnunet://fs/chk/PL217ODD8EDSMOIQ3UT0…

Now if Alice wants to publish her binaries, she creates an
ego/namespace and publishes everything under it; Bob adds her
namespace’s public key to his authorized substitutes list, and when
installing `/gnu/store/xyz` the substitute will search for
`gnunet://fs/sks/<Alice’s key>/xyz`.

Instead of publishing an archive we might also directly publish/index
the build, but I don’t know if it’s viable.

Does it seem right to you?

* Another discusion about guix integration

Instead of using ‘file-system-tree’, this variant should probably use
‘live-paths’ from (guix store), which returns the list of live store

Well, `file-system-tree` is only used to recursively index a random
directory’s content (in our case, a single store item). It looked viable
for publishing a single store item, but won’t be good for indexing at
once the entire set of live paths; I should ask the GNUnet team how to
properly index such a huge amount of directories.

On my machine, running `live-paths` takes ~2 seconds, but the
publication of the entire store will probably take much longer anyway.

BTW, I noticed there’s quite a bunch of global variables that are
‘set!’.  It would be better to avoid that, but I suppose the
continuation-passing style that the GNUnet libraries impose makes it

Hopefully, using the “closure” parameters of the GNUnet API in the
bindings should reduce the need for global variables, and improve
elegance of end-user programs.

Nitpick: it’s a bit annoying that we have to specify a GNUnet
configuration file.

Yes, GNUnet programs usually look for `~/.config/gnunet.conf`, and
`publish-gnunet` does the same. Now, maybe `publish-gnunet` could
somehow obtain the config file used by `gnunet-arm`?

No, it would need the config file to figure out how to talk to
gnunet-service-arm (or any other service). And we do support running
many instances of peers on the same host, which really means the config
is the only way to find out.

The rest of ng0 reply:

On various occasions it was made clear to me that FS isn't ready for such usage and we would need to extend it if we start working on it. I could be wrong, but to some degree our implementation of our own designs has some
mistakes, if I remember Grothoff right.

Bits and pieces without what I came up with in winter 2016:

* anonymous levels aren't necessary for sharing code
** update on this: one (or more?) other OS' is looking into Guix+GNUnet
as well and I'm not sure if they would rely on anonymity. Imo it makes
   no sense for the start. anonymity setting 0 would work for a start.

Anonymity is easily configurable.

Before I share my part of the ideas, maybe someone who wasn't involved
in the on-and-off discussions could add their ideas? Fresh ideas could
bring new perspectives we haven't seen.

For the Guix part I just know that it should be an option, not a default.

Oh really? I don't see that appear in the discussion with Remi.

reply via email to

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