[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GSoC] Draft of my proposition

From: vincent
Subject: Re: [GSoC] Draft of my proposition
Date: Wed, 23 Mar 2016 22:37:27 +0000 (GMT)

23. Mar 2016 02:17 by address@hidden:

<address@hidden> 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.

IPFS checks the integrity of the content you download and that's it. You have to validate in other ways that the content you want has effectively a given hash.

I think it's a very big advantage, because it totally uncouples the p2p sharing from the trust system. Users do not have to agree to be on the same security scheme. One could configure his system in a way that it will only download content signed by, let's say the FSF and the EFF, and another user downloads only when signed by his employers. Both those users will be able to share the same data with one another, because the data is separated from the signature.

That's what I meant by "building consensus on a package’s hash", because the community will be able to innovate to build a trust system. :)


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?


IPFS does not aim to solve the last part. 

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 are signed with Hydra's key, and users of
Guix must trust Hydra's key in order to use Hydra's substitutes.

Users who trust Hydra will be able do download substitutes from one another, if the package is signed by Hydra. This should come as a relief to hydra's servers! :)

I could also add that a package must be signed by the all the user's trusted substitutes before downloading.

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

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:

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:

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.

I think IPFS simpler and more stable API is a must. But I will definitely be looking into reusing parts of his code, either for IPFS or making it usable for both. I could be an interesting stretch goal.

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.

Thanks to you for making it possible :)

- Vincent

reply via email to

[Prev in Thread] Current Thread [Next in Thread]