On 03/21/2013 07:01 PM, Christian Grothoff wrote: > 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.
For authentication, we intend to use GPG with gnunet-update. The idea is that the gnunet-updater would search for updates using GNUnet's File Sharing service and downloads meta-data files. It then verifies if the meta-data files are signed by a trusted key (which is user-configurable) and proceeds with the download of actual binaries. Using this approach the meta-data files and the binaries pointed in meta-data can be published by anyone and still be verified. This could improve the availability of both meta-data and the binaries. -- Harsha
