From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:470:142:3::10]:50896) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hmxFD-0003Sn-6g for guix-patches@gnu.org; Mon, 15 Jul 2019 05:26:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hmxFC-0000Zn-3T for guix-patches@gnu.org; Mon, 15 Jul 2019 05:26:03 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:37572) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hmxFB-0000Zd-W4 for guix-patches@gnu.org; Mon, 15 Jul 2019 05:26:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hmxFB-0006Hn-Pb for guix-patches@gnu.org; Mon, 15 Jul 2019 05:26:01 -0400 Subject: [bug#33899] [PATCH 0/5] Distributing substitutes over IPFS Resent-Message-ID: From: Ludovic =?UTF-8?Q?Court=C3=A8s?= References: <20181228231205.8068-1-ludo@gnu.org> <87r2dfv0nj.fsf@gnu.org> <8736pqthqm.fsf@gnu.org> <87zhlxe8t9.fsf@ambrevar.xyz> <87ftnbf1rt.fsf@gnu.org> Date: Mon, 15 Jul 2019 11:24:57 +0200 In-Reply-To: (Hector Sanjuan's message of "Sun, 14 Jul 2019 22:31:43 +0000") Message-ID: <87ef2rr6om.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: Hector Sanjuan Cc: Antoine Eiche , "go-ipfs-wg@ipfs.io" , Pierre Neidhardt , "33899@debbugs.gnu.org" <33899@debbugs.gnu.org> Hello H=C3=A9ctor! :-) Hector Sanjuan skribis: > On Friday, July 12, 2019 10:15 PM, Ludovic Court=C3=A8s wr= ote: [...] >> > - Pinning: Pinning all files separately incurs an overhead. It's >> > enough to just pin the IPLD object since it propagates recursively. >> > When adding a tree, then it's no problem since pinning is only don= e once. >> > >> >> Where=E2=80=99s the overhead exactly? > > There are reasons why we are proposing to create a single DAG with an > IPLD object at the root. Pinning has a big overhead because it > involves locking, reading, parsing, and writing an internal pin-DAG. This > is specially relevant when the pinset is very large. > > Doing multiple GET requests also has overhead, like being unable to use > a single bitswap session (which, when downloading something new means a > big overhead since every request will have to find providers). > > And it's not just the web view, it's the ability to walk/traverse all > the object related to a given root natively, which allows also to compare > multiple trees and to be more efficient for some things ("pin update" > for example). Your original idea is to create a manifest with > references to different parts. I'm just asking you to > create that manifest in a format where those references are understood > not only by you, the file creator, but by IPFS and any tool that can > read IPLD, by making this a IPLD object (which is just a json). OK, I see. Put this way, it seems like creating a DAG with an IPLD object as its root is pretty compelling. Thanks for clarifying! Ludo=E2=80=99.