Re: Using GNUnet for binary package distribution

[Christian Grothoff <grothoff@in.tum.de>]

On 03/21/2013 02:02 PM, Ludovic Courtès wrote:
> Hello GNUnet!
>
> GNU Guix provides a transparent binary/source deployment model.  A
> server can claim: “hey, I have the binary for
> /nix/store/v9zic07iar8w90zcy398r745w78a7lqs-emacs-24.2!”, where the
> base32 string uniquely identifies a build process.  If you trust that
> server to provide genuine binaries, then you can grab them instead of
> building Emacs locally.
>
> The “traditional model” has been to have a build farm build and serve
> binary packages.  In that model, users trust the build farm to provide
> authentic binaries.
>
> I’m interested in providing a /practical/ decentralized distribution
> model.  It seems to me that GNUnet’s DHT would be the most appropriate
> (as opposed to AFS).  WDYT?
>
> One of the problems to be solved is authentication: users would have to
> specify a list of GNUnet pseudonyms of trusted binary providers, or
> something like that.  Managing this list would have to be as easy as
> possible, to allow the system to scale.
>
> Another issue is privacy: we want to give users an incentive to share
> their binaries, but at the same time, they should have control over what
> gets shared (for instance, Christian may want to hide the fact that he’s
> installed Python and not Guile ;-)).
>
> What do you think of the idea?  Would the DHT retain files long enough
> for this to be practical?

Well, the GNUnet DHT expects that the data source periodically refreshes 
the values by re-issuing the PUT; without that, it cannot work. 
Furthermore, you need to consider that DHTs are typically only useful 
for small data pieces (think <= 64k), not for large files.  So what 
you'd store in the DHT is the meta data (where to find the large files), 
not the actual files.

gnunet-update (svn/gnunet-update/) is a little project where we started 
to work on a GNUnet installer that is supposed to include an update 
mechanism that downloads updates via GNUnet --- after all, if you are
using a recent version of GNUnet, sharing your installation binaries
costs you at least no disk space at all, and if censorship kicks in,
having a way to update in a decentralized fashion might become important.

So gnunet-update is planned to provide the means to locate files based 
on some package description (signatures, meta data) and download them
via the P2P network.  Fundamentally, there is nothing wrong with using
the basic ideas to distribute packages other than GNUnet itself.

Our current approach to package management is essentially to look at ldd 
and grab all dependencies (unless compatible versions are already
available on the target system, based on libtool versioning info); the
idea was to make it work with 'any' distribution as long as the 
architecture matches.  Naturally, that doesn't mean that in principle a 
different package manager could not be used/supported.

gnunet-update is not yet finished, we're currently planning to revise 
some internal part that gnunet-update will depend on (stream); still, 
help in moving this area along would be of course welcome.

Happy hacking!

Christian