[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Guix - GNUnet binary ditribution roadmap
From: |
Ludovic Courtès |
Subject: |
Re: Guix - GNUnet binary ditribution roadmap |
Date: |
Wed, 12 Mar 2014 21:56:53 +0100 |
User-agent: |
Gnus/5.130007 (Ma Gnus v0.7) Emacs/24.3 (gnu/linux) |
Sree Harsha Totakura <address@hidden> 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’.
- Re: Guix - GNUnet binary ditribution roadmap, Sree Harsha Totakura, 2014/03/12
- Re: Guix - GNUnet binary ditribution roadmap,
Ludovic Courtès <=
- Re: [GNUnet-developers] Guix - GNUnet binary ditribution roadmap, Christian Grothoff, 2014/03/13
- Re: [GNUnet-developers] Guix - GNUnet binary ditribution roadmap, Ludovic Courtès, 2014/03/13
- Re: [GNUnet-developers] Guix - GNUnet binary ditribution roadmap, Christian Grothoff, 2014/03/13
- Re: [GNUnet-developers] Guix - GNUnet binary ditribution roadmap, Ludovic Courtès, 2014/03/14
- Re: [GNUnet-developers] Guix - GNUnet binary ditribution roadmap, Christian Grothoff, 2014/03/14
- Re: [GNUnet-developers] Guix - GNUnet binary ditribution roadmap, Ludovic Courtès, 2014/03/14
- Re: [GNUnet-developers] Guix - GNUnet binary ditribution roadmap, Ludovic Courtès, 2014/03/18