Re: [GNUnet-developers] Guix - GNUnet binary ditribution roadmap

[Ludovic Courtès]

Hi,

Thanks for sharing your tentative roadmap.

Pierre-Antoine Rault <address@hidden> skribis:

> Roadmap:
> #1 work on the GNUnet service: handling of requests from users
>   (tuple(s) answers[see below for structure]). tests with static database.
>   * work on a client-side binary list request

This is so abstract that I’m not sure what is meant here.  I’d like to
see clearer connections to the Guix and GNUnet code.

For instance, “requests from users” and “client-side binary list
request” are very abstract (and slightly misleading, because every
client is likely to be also a server, that’s p2p.)

Could you instead specify the underlying mechanisms involved?

I’d like to see something like:

  Publication of build products works like this:

    1. users runs the new ‘guix publish’ command, which inserts in the
       GNUnet DHT a key/tuple pair, where the tuple contains [list the
       fields etc.].

    2. ‘guix publish’ opens a GNUnet MESH channel to serve these files
       [explain how it’s used, possibly using the ‘gnunet-mesh’ command
       to illustrate, showing the kind of “channel identifier” that you
       get, describing how this interacts with the GNUnet peer
       identity, etc.]

       Files are served as Guix archives signed by the daemon’s key (?).

  Lookup of build products works like this:

    1. users look up the store file name, such as
       /gnu/store/...-emacs-24.3 in the GNUnet DHT.  This lookup is
       implemented as a substituter (akin to ‘guix substitute-binary’
       except that it uses GNUnet instead of direct HTTP connections.)
       Thus it’s completely transparent for the user: ‘guix build’,
       ‘guix package’ etc. magically get to use GNUnet to look for
       binaries.

    2. upon the list of matching answers, the substituter selects the
       first one offered by a peer whose trusted key is in the guix
       archive ACL.

    3. substituter connects to remote peer’s MESH channel specified in
       the tuple, retrieves the archive, checks their signature like
       ‘guix archive --import’ does.

There are a number of dots to be filled in here.  I think it’s important
to understand the mechanisms involved, and from there to fill in the
dots.

Then we can devise the milestones and a general roadmap.

WDYT?

> #3 work on the GNS SDSI/SPKI signing of user builds.
>   ['spki-sign' command developped]
>   [see signing below]
>   * work on key generation.
>   * work on key storage in a keyring.
>   * work on signature via key on a build.

Is there something to implement at all?  What about using what Guix or
what GNUnet provides?  This needs to be clarified.

> #4 work on the client-side checking of binary signature.
>   [update of the download process to include checks at the end]

Likewise.

> #5 work on the trust of signatures and filtering of tuples.
>   ['--dht' command option updated]

Likewise.

Ludo’.