[Nix-dev] Google Summer of Code 2015

Michael Raskin 7c6f434c at mail.ru
Thu Feb 5 08:16:48 CET 2015


>I prefer the NDN approach for a number of reasons:

NDN will change. NDN is cheaper to filter than HTTPS. Etc. 

On the other hand, I guess adding NDN as one more retrieval method of
known-hash content should not be hard when there is a well-tested 
multiprotocol non-centralised substituter.

>* An Alan Kay quote: The Internet was done so well that most people
>think of it as a natural resource like the Pacific Ocean, rather than
>something that was man-made. When was the last time a technology with
>a scale like that was so error-free? The Web, in comparison, is a
>joke. The Web was done by amateurs.
>* IPFS.io tailors to patching flaws in HTTP and is aimed at the browser.
>* IPFS has many moving pieces, NDN is much simpler in comparison.
>* NDN has provenance built into the protocol, IPFS does not.
>* NDN isn't dependent on the browser and is meant to support other
>non-browser applications.
>* A web-of-trust implementation on NDN would be much simpler, as key
>dissemination is done via the NDN. Eelco's public key could be
>distributed with each Nix installation. As long as the NDN obtained
>list of trusted contributors signed by that key it's safe.... within
>the social limitations of a web-of-trust.
>
>So, no, I do not support a bittorrent P2P styled setup.
>
>On Thu, Feb 5, 2015 at 2:29 PM, Michael Raskin <7c6f434c at mail.ru> wrote:
>>>Possibly so, though maybe limiting the scope of this GSoC project to
>>>reproducible builds is a suitable approach? Thus laying the foundation for
>>>whatever dissemination strategy to be adopted in future.
>>
>> I hope the paragraph before the one you cited expresses my support for
>> that idea.
>>
>> Bittorrent/GnuNet PoC for P2P substituter could also be added (with
>> manual content hash list management).





More information about the nix-dev mailing list