Konrad Hinsen <konrad.hinsen@fastmail.net> writes:

> I was thinking of the Guix package definitions. In the long run,
> assuming IPFS turns out to be reliable enough, we could put all source
> into IPFS with a CID reference, rather then today's many ways to
> download source files.

There would be nothing special about it beside implementing an IPFS
fetcher, or would it?  Let me know if I misunderstood.

> Again in the long run, if we don't mind depending on IPFS, we don't need
> the Guix store any more. Package installation would amount to local
> pinning. Anyone could then build a package anywhere (home directory,
> ...) and just add it to IPFS. Since that also eliminates the technical
> constraints of the store, the same mechanism could be used for any kind
> of data processing, with the results stored in IPFS. Reproducibility of
> any kind of computation via Guix, with building software just an
> important special case.

Very good point, I like it.  I think I'll mention this in the talk.

> For human input, Git would be OK, with repositories stored in IPFS
> (there's already some support for that, see
> https://github.com/ipfs/go-ipld-git). A more radical redesign is
> Radicle (http://www.radicle.xyz/), which uses IPFS as a collaboration
> platform (still at the git level). I guess Radicle could be used for
> much more than that in Guix, but I haven't looked at that in detail.

Didn't know Radicle, it looks fantabulous!  And... it uses (or plans to)
a Scheme-based language! :)

So you are saying that we could move the guix.git to a Radicle project,
right?
Makes sense to me.

-- 
Pierre Neidhardt
https://ambrevar.xyz/