all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Chris Marusich <cmmarusich@gmail.com>
To: vincent@cloutier.co
Cc: Guix Devel <guix-devel@gnu.org>
Subject: Re: [GSoC] Draft of my proposition
Date: Tue, 22 Mar 2016 23:17:25 -0700	[thread overview]
Message-ID: <87fuvhvhu2.fsf@gmail.com> (raw)
In-Reply-To: <KDQFe3T--3-0@cloutier.co> (vincent@cloutier.co's message of "Mon, 21 Mar 2016 22:19:09 +0000 (GMT)")

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

<vincent@cloutier.co> writes:

> Since Guix users know in advance the hash of the data they want,
> downloading from peers has no security implications (and privacy can
> be done trough proxies).

How will trust work in the IPFS world?  I think maybe you touch on this
when you later mention "building consensus on a package’s hash", but it
wasn't entirely clear to me.

My understanding is that because Guix uses a cryptographic hash
function, it's true that if you have some data, you know the expected
hash value of that data, and the computed hash value of the data matches
the expected hash value, then you can be confident that the data hasn't
been corrupted or tampered with.  However, how do you know the expected
hash value was correct to begin with?  How can you trust it?

Currently, I believe that Guix handles trust by refusing to use
substitutes that are not signed by a trusted key.  The substitutes built
and vended by hydra.gnu.org are signed with Hydra's key, and users of
Guix must trust Hydra's key in order to use Hydra's substitutes.

> I have a fascination for peer-to-peer tech and I am constantly looking
> for the innovative new tech in this area (Bitcoin, Ethereum,
> etc). Less than a year ago I discovered IPFS, a project that takes the
> best ideas from BitTorrent and Git to create a simple and elegant
> protocol.
>
> IPFS allows one to find who has a piece of content and is ready to
> share it, when knowing only the content’s hash. Content is added in a
> reproducible manner and deduplication can be added via Merkle
> trees. IPFS is also content-agnostic, one could serve Guix’s programs
> without even running Guix. It would also be possible to share text or
> video documentation using IPFS.

This is a very compelling idea!  Thank you for sharing it; IPFS is new
to me, and it looks intriguing.  I understand that in the past, Rémi
Birot-Delrue did some work on a similar project to enable publication of
packages over GNUnet:

https://lists.gnu.org/archive/html/guix-devel/2015-05/msg00022.html

Although progress was made, I don't think the project to publish
packages over GNUnet was fully completed.  This seems to be the last
email thread from Rémi:

https://lists.gnu.org/archive/html/guix-devel/2015-08/msg00455.html

Have you considered picking up where Rémi left off?  Even if you choose
not to use GNUnet instead of IPFS, perhaps Rémi's prior work can help
you as you work on your project.

> A couple of years ago I realized that every tool I had learn and
> everything that I tinkered with was free and open source
> software. Almost everything I achieved with computers was because of
> people who shared their knowledge and technologies and I want to
> contribute back.

That's fantastic!  Thank you for stepping up and helping.

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

  reply	other threads:[~2016-03-23  6:17 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-21  0:40 [GSoC] Draft of my proposition vincent
2016-03-21  9:35 ` Ludovic Courtès
2016-03-21 22:19   ` vincent
2016-03-23  6:17     ` Chris Marusich [this message]
2016-03-23 20:33       ` Rémi Birot-Delrue
2016-03-23 21:29         ` Jookia
2016-03-23 22:45           ` vincent
2016-03-23 23:11             ` Jookia
2016-03-24  7:32               ` Efraim Flashner
2016-03-25 13:28         ` Ludovic Courtès
2016-03-23 22:37       ` vincent
2016-03-25 13:24         ` Ludovic Courtès
  -- strict thread matches above, loose matches on Subject: below --
2017-08-21 10:06 Frederick Muriithi
2017-08-21 11:19 ` Ricardo Wurmus

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=87fuvhvhu2.fsf@gmail.com \
    --to=cmmarusich@gmail.com \
    --cc=guix-devel@gnu.org \
    --cc=vincent@cloutier.co \
    /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.