Re: [GNUnet-developers] gnunet-guile reboot & guix (take two)

[ng0]

Hi,

On Sat, 03 Feb 2018, amirouche <address@hidden> wrote:
> Hello all,
>
>
> After discussing gnunet & guix at fosdem with gnunet
> people I have better picture of where things can go.
>
> The short story is:
>
> 1) There is no way to know the gnunet hash aka. gnunet uri
>   of a substitute before the build.
>
> 2) There is no way to associate gnunet hash and guix hash
>   in a secure/trusted manner over gnunet. Except maybe
>   if we use GNS to publish guix hash as subdomains of
>   substitute-server.guix.gnu?
>
> Possible solutions:
>
> a) Add the gnunet-uri of the substitute in the package
>   definition. This can only work if the package is
>   reproducible aka. the build is always the same given
>   the same package definition. For reproducible builds,
>   it will be possible to offload the build and
>   the download over gnunet.
>
> b) Use a central repository (!) which must be trusted and
>   which will provide a map of guix hash <-> gnunet hash
>   based on builds done locally. This way we can offload
>   the download of the files to gnunet...
>   That said, the central repository is still a SPOF.
>
> Solution b) is not a massive improvement over the current
> situation, that said maybe that is good enough. It's the
> easy solution. We must:
>
> i) change the substitute server to publish over gnunet
>    new builds and add the gnunet hash to a local
>    database.
>
> ii) change the substitute server to publish
>     guix hash <-> gnunet hash association file
>
> iii) change guix, to fetch the association file from
>      a trusted server and then download over gnunet
>      the files.
>
> Solution a) is my prefered because it's truly peer-to-peer
> but it leads to complicated workflow for builds that are
> not reproducible since we must reset the gnunet uri in
> the package definition from a trusted build server.
> I am not sure how it's possible to rewrite a package
> definition in guile right now.
>
> WDYT?

Solution (b) could be an intermediate solution that would be easy
to test the reliability of current FS with. However, I agree with
you that (a) is my preference.

I'd extend it later on with ideas coming from liquid democracy
once we have this running.

wrt not reproducible... if we know it, what about introducing a
'reproducible' keyword? We'd have to check builds and once a
build is reproducible we'd remove the keyword from the arguments
(#:reproducible? -> defaults to #t)..
Good idea? Bad idea? I haven't put much thought to this keyword
idea.

Another idea we had (I need to read into the old offtopic) iirc
was (breaking it down to the simple parts I remember) that a
certain number of people signs a package as "reproducible"
so you can trust its state. This goes a bit more
into the direction of LD I'm playing with.

I'll read into the old messages and tell you more what we thought
about it.

>
>
> _______________________________________________
> GNUnet-developers mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnunet-developers
>

-- 
ng0 :: https://ea.n0.is
A88C8ADD129828D7EAC02E52E22F9BBFEE348588 :: https://ea.n0.is/keys/