From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christian Grothoff Subject: Re: Using GNUnet for binary package distribution Date: Thu, 21 Mar 2013 19:01:04 +0100 Message-ID: <514B4AE0.9070405@in.tum.de> References: <87620kykg6.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; Format="flowed" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <87620kykg6.fsf@gnu.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gnunet-developers-bounces+gnu-gnunet-developers=m.gmane.org@gnu.org Sender: gnunet-developers-bounces+gnu-gnunet-developers=m.gmane.org@gnu.org To: gnunet-developers@gnu.org, bug-guix@gnu.org List-Id: bug-guix.gnu.org On 03/21/2013 02:02 PM, Ludovic Court=E8s wrote: > Hello GNUnet! > > GNU Guix provides a transparent binary/source deployment model. A > server can claim: =93hey, I have the binary for > /nix/store/v9zic07iar8w90zcy398r745w78a7lqs-emacs-24.2!=94, 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 =93traditional model=94 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=92m interested in providing a /practical/ decentralized distribution > model. It seems to me that GNUnet=92s 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=92s > 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 <=3D 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