23. Mar 2016 02:17 by cmmarus...@gmail.com:
> <> vinc...@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.
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 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.
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
>> 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.
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
