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