[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#52555] [RFC PATCH v2 0/5] Decentralized substitute distribution wit
From: |
Maxime Devos |
Subject: |
[bug#52555] [RFC PATCH v2 0/5] Decentralized substitute distribution with ERIS |
Date: |
Wed, 02 Feb 2022 12:27:11 +0100 |
User-agent: |
Evolution 3.38.3-1 |
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
Description: This is a digitally signed message part