Re: [GSoC] GNUnet binary distribution system

[Pierre-Antoine Rault]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

On 10/03/2014 22:09, Ludovic Courtès wrote:
> 
> Pierre-Antoine Rault <address@hidden> skribis:
> 
>> Having worked with libtorrent and kademila, i am quite familiar
>> with dht and P2P, and I think GNUnet shouldn't be much difficult
>> to adapt to. I am thus reading info about GNUnet, but I already
>> have some features in mind (not sure if redondant with other
>> messages posted before):
> 
> Please do get in touch with the GNUnet folks as well.  I’ve Cc’d
> them so you can say hi.  ;-)

Thanks ! :)

>> * As said by Andreas Enge, users should all be able to share
>> packages themselves, provided they can cryptographically sign
>> their binaries. They would deploy a node (a personnal node) using
>> a local deamon (could be by passing a command to guix-daemon
>> which would handle the task). The local daemon would contact a
>> list of known nodes (contained in a mirrorlist) and send them
>> hashes with their corresponding signature.
> 
> What exactly is meant by “node” and “mirrorlist” here?

A node [1] represents either a server like hydra or a user that has
decided to share binaries, in our dev case.

[1]
http://en.wikipedia.org/wiki/Node_(networking)#Distributed_system_nodes

A mirrorlist is a list of adresses to contact first (i.e: dht may be a
distributed system, it still needs a few adresses to initiate hash
search ; at least that's how most torrent systems handle dht). A user
should be able to manually add/remove dht nodes to be contacted first.

> The initial discussion [0] left open the question of where
> binaries themselves should be stored.  A possibility would be to
> use GNUnet’s DHT simply as a discovery mechanism, and then to
> establish a connection directly to the user’s machine, which would
> run, say, an HTTP server.

That's what I had in mind. Now, considered the post [2] by Christian
Grothoff, we might consider using either an HTTP server for
performance or GNUnet's MESH for anonymity (and security). We should
balance needs and ease of implementation.

[2] http://lists.gnu.org/archive/html/guix-devel/2014-03/msg00113.html

>> * Users should be able to trust a node. That would not mean
>> trusting all providers for all hashes recursively, but rather
>> trust those trusted by the node in cascade. Thus a distinction
>> beetween trusted pairs and trusted node pairs should be done.
> 
> Please read the “Invoking guix archive” section of the manual
> (from Git), to get a feel of the current approach.  See also Mark’s
> message at 
> <https://lists.gnu.org/archive/html/guix-devel/2014-02/msg00297.html>
>
> 
for ideas of what we’d like.
> 
>> * I think we should focus on ease of use, since it could become a
>> good alternative to setting up a full fledged server to share
>> officially supported packages and unofficial ones (like the AUR
>> for Archlinux).
> 
> That’s been discussed before (see 
> <http://lists.gnu.org/archive/html/guix-devel/2013-08/msg00127.html>),
>
> 
but it’s orthogonal.

Then we have to extend the guix tools to cover user modules (overlays,
that is).

> This proposal needs discussion with both Guix and GNUnet people
> (and notably Sree Harsha, who is at the intersection of both
> projects :-)), to work towards a concrete road map of things to
> hack on.

Sure ; It's the only way to have a clear and shared view of what parts
of Guix are involved in the project. I'm working on a roadmap draft
for now.

- - rigelk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTHkiUAAoJEHfJ0QE7gLd6+pwH/0qKzeyF3S/78GEI8E999SAo
HF0tG3UdaDAmFlm69HVuzEwaHzJVzUsyo77rRDvRWv7urIrsuIakMTdfcQPeaFF5
X8s59AyE1KhVqbwoCPGwW21Cti5rGF1B0fUk9NTmTcbd14orYgeYsQJtGbOSATIU
up7OVnyDnyqVlCiHcMBjkyvED+d0IGG5CXS1DKhyHM1u/U2S2XatYsRem5nPZ+kE
iAvZAct1+rCJT1f3uQLGPAcCIxXs7BR2BWS9gslXOdZlCFIKSyiIsYlGar9j/WXi
ZwkmmLiylDmv2z9gqapH6PthhantZiEqGDh2dHarY0gqz0VnVgq7OobAjPm0bGs=
=W+vJ
-----END PGP SIGNATURE-----