Guix - GNUnet binary distribution roadmap

[Deepan Sekar <dee93.jr@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3113 bytes --]

Hi

Im sorry for coming up with an update in the proposal for the binary
distribution for GSoC 14 this late. I had my university exams. I hope the
shortlisting is not already over and we can still continue the discussions.

Ludo, I tried to edit the proposal in the melange page like you said but
its not possible. It seems the organization has to enable that option.

So, here's the thing:

1. The "guix package -i .." command currently looks up the package
definition and installs the package with the substituter downloading the
binaries from hydra server. If thats not possible, the derivations are
built on the local system.

modifications:
a. Change the package definitions field "url-fetch" of all the packages to
reference that the download is to be made using gnunet. This will make the
daemon run the necessary steps discussed below. The users can update to
this model after its released by using "guix pull".

b. The package definition can be retained and we can change the source code
of the substituter to by default lookup for the binaries in the GNUnet
service and if its not available, then go for the hydra server.

2. Now, whichever method above is implemented, the subsituter can be
reprogrammed to open a gnunet dht connection and get the necessary details.
The substituter finds out the dependencies of the given package from the
package definition and computes the SHA256 hash of the depencies.

3. Since the DHT uses key/value pairs to get and put data, we can use the
SHA256 hash of the dependencies of the package as the key. The name of the
package (since there is a possibility that two packages can have the same
dependencies), gnunet peer id of the user having the package and the mesh
channel identifier as the values associated with that particular key.

4. Once the values from the DHT nodes are received, the substituter filters
out the tuples with a different filename which might be present due to the
match with the hash of the dependencies used as key.

5. From the resulting entries of the corresponding values, the first peer
in the list is used to open a p2p connection in gnunet.

6. The filename and the hash are used to request for the necessary binary
from the peer. Or maybe only the hash can be used. The filename alone is
not sufficient because various versions might be present in the peer's
system. The hash on the other hand is unique.

Note: The gnunet features in the previous steps are available presently.
Only the substituter code in guix has to be written.

6. The downloaded binary is then used by guix to install the package as it
currently does.

Note: For authentication purposes, we can use signatures of the peers along
with the files.

7. Finally, with the users consent, the guix daemon can publish in the
gnunet dht pool of nodes to "put" the key/values of the package so that
other users can now use this peer as a source for the binary file later.


This is the idea for the implementation. The timeline can easily be formed
once the implementation idea is approved. The above can be divided into
phases and assigned a deadline.

Regards,
Deepan

[-- Attachment #2: Type: text/html, Size: 3664 bytes --]