Guix Days notes email thread

[Juliana Sims <juli@incana.org>]

[-- Attachment #1: Type: text/plain, Size: 560 bytes --]

Hello,

For those not at Guix Days:

We have split into groups discussing various topics.  Each group is 
collecting notes on its discussion.  I am starting this thread as a 
place for these notes, to be distributed as necessary.

To kick things off, I've attached my notes on the discussion of 
"distibuted substitutes" which we clarified referred to 
participatory/peer-to-peer substitutes.  I tried to group things 
conceptually based on where conversation ended up, but "conclusions" 
per se are all under "Next Steps" and "Open Questions".

Thanks,
Juli


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: distributed-substitutes.org --]
[-- Type: text/org, Size: 3543 bytes --]

#+title: Participatory (p2p) Substitutes

* Angles
** Building
** Delivering

* Why

** substitute servers are slow
** resources
*** compute
**** speed
**** cost
*** storage
** resilience

These problems increase exponentially with users or packages or both.

* Problems

Source code is easier because we can have absolute knowledge of hash of source
-- can cryptographically verify source.  By contrast, crypto verification of
binary requires compilation.  Need to trust source of binary substitutes.

** Trust
Someone needs to supply the hash.  Currently, this is the central Guix build
farm.

** Content-addressed downloads
Need architecture for distributed (network topography) delivery.  Can already
content-address sources and binaries; just need trusted hash.  That is, same
problem for source and substitutes.

** Nar files
Potentially inefficient?

** Obligations on users
Users may be expected to contribute back bandwidth, potentially build time to
the network.

** Privacy
What if we have private info in ~/gnu/store~ eg because of Guix home managing
dotfiles?

** Granularity
1. Different people have different security/privacy models.
2. People may want to use different transport mechanisms

* Solutions

We seemed to quickly shift to envisioning an opt-in network of distributors, eg
with Guix system service.  Above problems addressed below:

** Trust
1. a server/user you choose to trust gives you a hash; you can get this
   substitute from any server and hash it yourself.
   - need to trust central server
	 + can talk to operator
2. apply ~guix challenge~ somehow
3. distribute trust over multiple nodes, eg strongly trust a few nodes, weakly
   trust more, test hashes against each other
   - could incorporate this into existing substitute certification infra
   - existing research in eg Tor exit node trust
4. zero-knowledge proof
   - expensive
   - more variables = more expensive
   - thus, likely not feasible

Conversation is tending towards consensus-based trust (trusting hash if
plurality of trusted nodes agree on hash) combined with "watchdog" application
of ~guix challenge~.

** Content-addressed downloads
1. bittorrent
   - definitely tackles bandwidth usage
   - tends towards "supernodes" which advertise lots of smaller nodes
	 + could run this on Guix infra
2. IPFS
3. (bespoke) OCapN/Spritely
   - could facilitate granular control of access
   - Spritely envisions distributed storage over ERIS, which is encrypted and
     complicates this space
4. ~guix publish~

** Nar files

** Obligations on users
1. have ~guix publish~ already

** Privacy
1. do not advertise hashes, only respond to requests for specific hashes
   - there is an attack on this (TahoeLFS encountered this?)
2. only advertise specific substitutes eg what's in the core Guix channel
   - could be used to triangulate what software someone uses by watching what
     they request
	 + already the case if monitoring requests to central substitute server
	 + could download and distribute software you don't use
3. may not solve all privacy issues, but must communicate privacy concerns to
   users (ie informed consent)

** Granularity

*** Privacy
1. opt-in to share specific nars or equiv (see above)

*** Delivery
1. provide abstract interface to a network

* Next steps
We already have content-addressed distribution.

1. more central substitute servers and mirrors around the world
2. abstract API for decentralized substitute delivery

* Open questions
1. trust mechanism
2. exact delivery mechanism
3. who does the work