From: Pierre-Antoine Rault <par@rigelk.eu>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: guix-devel@gnu.org, gnunet-developers@gnu.org
Subject: Re: [GSoC] GNUnet binary distribution system
Date: Tue, 11 Mar 2014 00:19:48 +0100 [thread overview]
Message-ID: <531E4894.7080103@rigelk.eu> (raw)
In-Reply-To: <87a9cxkbg3.fsf@gnu.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
On 10/03/2014 22:09, Ludovic Courtès wrote:
>
> Pierre-Antoine Rault <par@rigelk.eu> 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-----
next prev parent reply other threads:[~2014-03-10 23:19 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-10 18:41 [GSoC] GNUnet binary distribution system Pierre-Antoine Rault
2014-03-10 21:09 ` Ludovic Courtès
2014-03-10 22:03 ` Christian Grothoff
2014-03-10 22:26 ` Ludovic Courtès
2014-03-10 23:19 ` Pierre-Antoine Rault [this message]
2014-03-11 3:35 ` Mark H Weaver
2014-03-11 6:59 ` Pierre-Antoine Rault
2014-03-11 18:29 ` Mark H Weaver
2014-03-11 8:42 ` Christian Grothoff
2014-03-11 13:06 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=531E4894.7080103@rigelk.eu \
--to=par@rigelk.eu \
--cc=gnunet-developers@gnu.org \
--cc=guix-devel@gnu.org \
--cc=ludo@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.