Hi, Thanks for sharing your tentative roadmap.
Pierre-Antoine Rault <[email protected]> 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’. _______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
