GNU bug report logs - #52555
[RFC PATCH 0/3] Decentralized substitute distribution with ERIS

Previous Next

Full log

View this message in rfc822 format

From: Maxime Devos <maximedevos <at> telenet.be>
To: pukkamustard <pukkamustard <at> posteo.net>
Cc: ~pukkamustard/eris <at> lists.sr.ht, 52555 <at> debbugs.gnu.org
Subject: [bug#52555] [RFC PATCH v2 0/5] Decentralized substitute distribution with ERIS
Date: Wed, 02 Feb 2022 12:27:11 +0100

[Message part 1 (text/plain, inline)]

pukkamustard schreef op wo 02-02-2022 om 10:51 [+0000]:
> > The database doesn't seem necessary, the substitute server could
> > have
> > some end-point
> > 
> >    /publish-this-nar-again-into-IPFS/name-of-the-nar
> > 
> > which, when contacted, inserts the nar again into IPFS.  Then when
> > a
> > block was unavailable, the client contacts this end-point and
> > retries.
> 
> But for a HTTP block endpoint we would still need such a
> database/block
> storage.
> 
> I think it is important that we do not rely on IPFS for block
> storage. The decentralized block distribution should work even if the
> IPFS daemon is not available.

Do we need a database at all?

E.g., if the client cannot download the data in the range [start, end]
because the corresponding block has disappeared, can it not simply
download that range from https://ci.guix.gnu.org/nar/[...]
(not sure about the URI) using a HTTP range request?

(Afterwards, the client should insert the block(s) back into
IPFS/GNUnet/whatever, maybe using this proposed ‘in-file block store’
such that other clients (using the same DHT mechanism) can benefit.)

Greetings,
Maxime.

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.