Re: Guix - GNUnet binary ditribution roadmap

[ludo@gnu.org (Ludovic Courtès)]

Sree Harsha Totakura <sreeharsha@totakura.in> skribis:

> On 03/11/2014 08:14 PM, Pierre-Antoine Rault wrote:
>> Hi,
>>
>> Sorry for contacting you directly (without the guix mailing list),
>> but Ludovic Courtès recommanded me to contact you as I would like
>> to work [1] on integrating GNUnet in Guix as a binary deployment
>> and sharing system.
>>
>> [1]
>> http://lists.gnu.org/archive/html/guix-devel/2014-03/msg00106.html
>
> No problem; I was also following your thread on guix-devel.

Cross-posting is fine for this discussion, IMO.

>> For now I'm afraid I have to catch up with what has been said and
>> thus made the following requirements/ideas list (all ideas are not
>> from me): * required: users may run a server to share binaries
>> (HTTP or GNUnet server).
> Let's just stick with the GNUnet server (we call such a server as a
> service in GNUnet, let's call it Guix service) as of now.  HTTP can be
> done optionally.  Moreover the currently binary distribution is made
> through a HTTP server.

Yeah, let’s keep HTTP optional.  The requirement will be to have a
server over GNUnet’s MESH, right?

>> * required: users should use a gpg key to sign their packages.
> OK, sounds good.

For consistency, I’d prefer to use our SPKI-style infrastructure (info
"(guix) Invoking guix archive").

>> * required: users would look for hashes on a dht node (GNUnet node)
>> to find user servers.
> I am assuming the hash lookup will be against the package and the
> result will contain the peers offering the package.  This requires all
> nodes which are running the Guix service to publish into DHT the
> packages they built or downloaded from others.
>
>> * required: users should be able to add/remove keys to their
>> keyring of trusted keys (which would have official keys as a
>> basis).
>
> Yes.

Again, SPKI:

  http://lists.gnu.org/archive/html/guix-devel/2013-12/msg00135.html
  http://theworld.com/~cme/spki.txt
  http://lists.gnu.org/archive/html/guix-devel/2013-12/msg00141.html

SPKI is very flexible, and would allow users to publish “delegation
certificates”.  For instance, I could sign a certificate that says “I
trust packages signed with this key.”  That’s a very useful feature.

(It’s of course similar to OpenPGP’s web of trust, except that OpenPGP
is engineered to handle specifically email/key bindings.)

>> * optional: users' servers could be dht nodes themselves.
> This may not be possible.  If you are running the Guix server, you
> would want to publish the packages you built into the DHT and for this
> you need to run the DHT service.

To me “could be DHT nodes” is the same as could “run the DHT service”.
I think you’re saying the same thing, no?  :-)

> The requirements from Guix side are missing here.  IMO, you have to:
> * Understand the current protocol used over HTTP to search and
> download packages from Guix Hydra server.
> * Implement a equivalent client/downloader in Guix using Guile to
> download the packages using GNUnet.
> * Extend the Guix daemon to publish package updates into GNUnet DHT,
> whenever new packages are added to the Guix store.

I think guix-daemon would remain unchanged.  Instead, the package
publisher could (say) periodically ask for the list of live store items
(as per ‘guix gc --list-live’) and publish those.

> The roadmap should contain a plan for implementing these requirements,
> the order in which the implementation happens and estimates of how
> long each step takes.

Agreed.

However, I think the protocol could be different from, and simpler than
Hydra’s.

Ideally, I imagine you could do something like:

  dht-get /gnu/store/ykmg6ydrmlkn600wklriw3wzc1z3dcli-emacs-24.3

and get as a reply (roughly) a tuple containing:

  1. a signature (as a canonical s-expression);

  2. a reference to a MESH channel from which to download the archive of
     that store item;

  3. additional information about the archive (see the <narinfo>
     structure at
     <http://git.savannah.gnu.org/cgit/guix.git/tree/guix/scripts/substitute-binary.scm#n192>).

I’m not sure I’m using the right GNUnet terminology/concepts, so do
clarify this.  :-)

> To begin with, I suggest you should start experimenting with GNUnet's
> DHT by writing an service which publishes periodically some (key,
> value) pairs.  In parallel, you may also try to understand the Hydra
> protocol.

Sounds good.  Don’t hesitate to ask questions here and on IRC.

Thanks,
Ludo’.

_______________________________________________
GNUnet-developers mailing list
GNUnet-developers@gnu.org
https://lists.gnu.org/mailman/listinfo/gnunet-developers