From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 02 07:52:17 2022 Received: (at 52555) by debbugs.gnu.org; 2 Feb 2022 12:52:17 +0000 Received: from localhost ([127.0.0.1]:51802 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nFF7R-000785-ES for submit@debbugs.gnu.org; Wed, 02 Feb 2022 07:52:17 -0500 Received: from mout02.posteo.de ([185.67.36.66]:60167) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nFF7O-00077m-7P for 52555@debbugs.gnu.org; Wed, 02 Feb 2022 07:52:15 -0500 Received: from submission (posteo.de [89.146.220.130]) by mout02.posteo.de (Postfix) with ESMTPS id EA813240105 for <52555@debbugs.gnu.org>; Wed, 2 Feb 2022 13:52:07 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1643806327; bh=yNrQsQJfvuyiVKi7mL2Ed53n44JDomBMl49FVbtRM5s=; h=From:To:Cc:Subject:Date:From; b=RpglqmkS0xYfUaxF9GHSJ1C8C5n1G6JRe8zlgclHlC1CvnoXtEMeInL7rv4h3dPhv n7s3JwgaiZnT7DlEbeflp9sM9fSFoycS8pXqn/9P6vyu/DruEebEq+Jzvz1vofgAVf 2gt1sUN0DluCW0M7ZgLI7iBpszZKYv65u/ucjExHXa6ROud60B6HlSPGZhCNNP10b2 jPv5dDCj7SxA28sehry/ie6Q+dEP227NUoINHCA2E4XXRDsGKwPNiEdGFil8LKCvE4 Qr1aLDbSd3t22fx+dLpaZQH6bbzonrgRLT3GtnGoCFv9/P93bIp6Xa8UaimwL8wYrK apAPWoBKYUGCg== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4JphX62MhWz6tmm; Wed, 2 Feb 2022 13:52:06 +0100 (CET) References: <20211216161724.547-1-pukkamustard@posteo.net> <20220125192201.7582-1-pukkamustard@posteo.net> <86fsp1h6ce.fsf@posteo.net> <846716544b4424f02e383114ebcb52957b43dd4d.camel@telenet.be> From: pukkamustard To: Maxime Devos Subject: Re: [bug#52555] [RFC PATCH v2 0/5] Decentralized substitute distribution with ERIS Date: Wed, 02 Feb 2022 12:42:21 +0000 In-reply-to: <846716544b4424f02e383114ebcb52957b43dd4d.camel@telenet.be> Message-ID: <8635l1h1mx.fsf@posteo.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 52555 Cc: ~pukkamustard/eris@lists.sr.ht, 52555@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Maxime Devos writes: >> 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? This does not work as the mapping from block reference to location in NAR can not be known by the client who only holds the ERIS URN. Furthermore, some blocks will be intermediary nodes - they hold references to content blocks (or other intermediary nodes) but not content itself. > (Afterwards, the client should insert the block(s) back into > IPFS/GNUnet/whatever, maybe using this proposed =E2=80=98in-file block st= ore=E2=80=99 > such that other clients (using the same DHT mechanism) can benefit.) It might make sense for some clients to make content available to other clients and to go trough the extra effort of putting blocks back into IPFS/GNUNet/whatever. But this should be optional. Maybe we can call such clients "caching peers"? IMO A client should by default only deal with things that are strictly necessary for getting substitutes. The substistute servers (and caching peers) should make sure substitutes are available to clients, whether over IPFS/GNUNet/whatever or plain old HTTP. -pukkamustard