From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id 2EJCB78KJGRhZQAASxT56A (envelope-from ) for ; Wed, 29 Mar 2023 11:54:07 +0200 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id kJINB78KJGS0OwEAauVa8A (envelope-from ) for ; Wed, 29 Mar 2023 11:54:07 +0200 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id D004A1EF38 for ; Wed, 29 Mar 2023 11:54:06 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1phSUn-0005j0-U9; Wed, 29 Mar 2023 05:53:33 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1phSUm-0005io-AJ for guix-devel@gnu.org; Wed, 29 Mar 2023 05:53:32 -0400 Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1phSUi-0006jr-Rj for guix-devel@gnu.org; Wed, 29 Mar 2023 05:53:32 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id F1011240432 for ; Wed, 29 Mar 2023 11:53:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1680083607; bh=vjO5aN8gGIRzj3aVVVXIil+kii/EhqDFuenLBwbVHUA=; h=From:To:Cc:Subject:Date:From; b=gjww5TTMPWdcw8lyLukYgsKv1hkxQ5N9rVuEB7Wjkb9MVBZTrNnpve35vafABKLuJ eKySVA5+SvGy8k6ObychbPm1CHpRjWHGTCb86ZPLPNbEp2Gv/aBKp1P6XaLxKuI008 g8KXMZanI7uE55rrgVIGhcGdD+BAdwa678UDAZTe0RJ9he6wPFBm9V0Ga45v2zJYC7 PqNTAEZDZ4ouew0YvsA0uhRiJwG+lyKJT4L4pMhpLpcn37Ds19TGLdYnFpPUQTlzGz ZPNBwA/3R7eVRLaK+9sff2R4oj2SpP9FPPDnazKhgki+WHOoQ1ebkdJysoU4VnIukN KdDKXGVRcbR1Q== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Pmhh60s7vz6tsB; Wed, 29 Mar 2023 11:53:26 +0200 (CEST) References: From: pukkamustard To: Vijaya Anand Cc: Attila Lendvai , guix-devel@gnu.org Subject: Re: [GSoC 23] distributed substitutes, cost of storage Date: Wed, 29 Mar 2023 09:34:12 +0000 In-reply-to: Message-ID: <86wn2zriop.fsf@posteo.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=185.67.36.66; envelope-from=pukkamustard@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: guix-devel-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=gjww5TTM; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=posteo.net ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1680083646; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=1olj5bjpJuFtdgHw/RDUxcij84kn7knIikwbiE8YMuI=; b=hmZU4glZgriVEEmer3CIOFmzv43uI9/ulURG1kCzXK5gUuA/dpVTQRlpHp8Xe0+Xc+ljno Z+JER1zt7BpXK0ErP+wNoDSA6YyNCaAxKz2hD1o4osXwSVocCwV2LKLS7XIdQIMca6xwmm EfnuJKbrGLgYXsN/oQMBcm0i+w0Gi4DNXsJdlucorTUsODa7AmpT7S25Le9qtY2dH8FAvG WyZ96wxJXo+/JrSmkmtKa9RpB3vUU+RzxKPw3+o4WbeB1QyqmPbEgPikkQJPX+oOUV9TdT w2jR8sXzA+u8IVbVgpXl+5G76d25a9odUlM0dvp8G9DTN2J8DGV16DmmwpEnMg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1680083646; a=rsa-sha256; cv=none; b=ECt86VXFj+F4tzqKn2pclZ4VQ1eP6MgyQNM8ejslS5vLFbNxsNqpGbv570F02+8efRP2mO T0QfW265MCeK8S8qzMcucTOTXU38xdR9ZiQUjMXKAJJSWzBfgi4Jl73km/a9TRPA9vK/vk /jqQewnQbOQ9a14wD0go9mxTQoeAWK3725uLDeipvuvsTv4jYVVsdvjMpBMENs4TwmJW5f sQy0qxBYVgTe/EgvFzU6D3AEOhyyNSLJ299iopLr7WaR0Fd0qoIu9awX8Aq6eHckUIEg2t Y/7AWwkuLVqn5vxZZhdto88IUaCr/71xDlOL+Nm8qskOTfmoQ/5OscvqjOnRmA== X-Migadu-Spam-Score: -5.24 X-Migadu-Scanner: scn1.migadu.com X-Migadu-Queue-Id: D004A1EF38 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=gjww5TTM; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=posteo.net X-Spam-Score: -5.24 X-TUID: 5/pMtAhlJp46 Vijaya Anand writes: > Sorry for the late reply. > So in the case we are running swarm nodes that serves the network and hen= ce help fund the substitute server, we can also use these > to also upload eris encoded substitute blocks onto the network am I right= ? The total cost will thus be cost to run the swarm nodes + > storage cost of substitute blocks in the network + cost to run substitute= servers - money earned by running swarm nodes. But when > we don't run swarm nodes which run to serve the network, the total cost i= s not really affect right as the cost to run swarm nodes will > be lessened and no money will be earned.=20 > So in the context of fallback mechanism the user client can send request = to the substitute server for the missing block and the > substitute server will serve the eris encoded data block back to the user= (using HTTP). The responsibility of uploading these missing > blocks back to the network is of the third party nodes (which are running= to serve the desired content to the network). But how do we > send the message to the node to report the missing block on the network? = Can it be done by the user itself? Some remarks: - Maybe we don't need to do too much of an economic cost estimation, the current p2p networks (blocks over HTTP and IPFS) as well as ones that will quite possibly work soonish (GNUnet) do not incur any additional monetary storage cost. I think we should focus on resource usage (memory, disk, network) of users, servers and caching peers instead. - One fallback strategy we absolutely need is to use get a substitute using the existing mechanism (substitute is a single nar file that is retrieved over HTTP without ERIS or any other p2p stuff). - I like the principle "Think globally, act locally". Maybe users downloading substitutes who want to improve access to substitutes over p2p should only try to do so withing the scope of what they can do locally. I.e. by making the blocks available on the p2p network from the local machine. For IPFS and GNUnet this works very well and elimintates necessity of more RPC endpoints. > "i can dream about a future where there's a social network that is based = on digital signatures and encryption, and my Guix client > authorizes compiled binaries based on some weighted transitive closure of= signatures of my trusted peers"....Interesting! In the case > of accessing Guix substitutes from p2p network, we ensure authorization b= y Guix team by making sure the urn of the substitute is the > urn mentioned in the narinfo (which we get from a trusted source like the= substitute server). So in the case of accessing some random > compiled binary from the network, we just need to verify the authority of= the document providing the urn of the content? This is a very nice vision, that I share! However, maybe we should keep it out of scope from the GSoC project and rely on the existing signature mechanism for authenticity. A web-of-trust like system for substitute system would be an excellent and very interesting follow-up project. -pukkamustard > On Mon, 27 Mar 2023 at 2:49 AM Attila Lendvai wrote: > > > Also I didn't really think about the point about having to pay for > > the p2p services at some point of time. > > a quick note here: i forgot to mention that e.g. the Swarm Foundation ha= s programs for supporting opensource projects. so, > chances are high that the storage needs for Guix would be paid for by th= e foundation. > > > In this case we will have to pay for the storage of substitutes both > > on the p2p storage backend as well as for storage in the substitute > > server am I right? > > well, the substitute servers are currently already operated (and paid fo= r) by the Guix team. i don't think that p2p storage solutions > have reached a point of maturity that we could rely on them alone. there= should definitely be some time where both > infrastructures are running in parallel. somewhere down the road a choic= e could be made to stop running the current substitute > servers, but we are far away from that. > > also, running swarm nodes that serve the network can earn money. so, the= cost of running enough swarm nodes to pay for the > storage needs of Guix on the swarm network should be in the same ballpar= k of the costs of running the current substitute servers. > the storage price will be market based (this part is just being rolled o= ut on the live network), so it's reasonable to expect that > people will fire up nodes if the storage price go well above the VPS cos= ts. > > and not all p2p storage networks are made equal. e.g. IPFS is only a reg= istry of who is serving what. if you want to keep your data > alive on IPFS, then you need to run some nodes and make sure that they a= re serving the content that you care about... and bear > the costs of running these nodes. i.e. the DoS attack surface of IPFS is= much smaller. (IPFS stores only the metadata in the DHT > (i.e. where is what), while Swarm stores there the data itself -- they a= re different architectures with different features) > > (i need to learn more about GNUnet) > > > So ideally we will want to eliminate the usage of these substitute > > servers and shift totally to p2p services and in this case we will > > have to shift the responsibility of re-uploading the blocks to the > > clients itself. > > yep, that's my way of thinking, too. > > note that 'client' here has two meanings: > > 1) some part of the codebase > > 2) a program that is running on the computers of the Guix users > > i was using it in the first sense. > > without a functional Web of Trust solution, the Guix team will have to r= un nodes that compile packages, sign them with their PGP > keys, and make them available somewhere. currently it's published throug= h a HTTP based service that we call 'substitute > servers'. this GSoC project is about adding more storage backends. > > but those backends don't solve the problem that the Guix users need to t= rust someone with a private key who compiles and signs > packages, regadless of the transport mechanism that gets the packages to= the clients. > > i can dream about a future where there's a social network that is based = on digital signatures and encryption, and my Guix client > authorizes compiled binaries based on some weighted transitive closure o= f signatures of my trusted peers... but we are not there > yet. for now it's either trusting the Guix team's signature, or setting = up your own substitute servers and build workers (or trusting > someone else, but i'm not aware of any third party offering substitutes). > > > Also if we dont keep the re-uploading blocks option as default for > > the users, won't users usually not choose to enable it? Maybe we can > > keep it on as default and resource conscious users can choose to > > turn it off? Please let me know your thoughts on these points and I > > will change the implementation point of my proposal accordingly. > > first, it's a philosophical question: i value consensual relationships, = and that implies that the other party is well informed. and > clogging someone's network bandwidth is not an expected behavior from in= stalling a linux distribution. > > there's also a technical issue: these p2p backends will need to be confi= gured. i have my doubts that we could ship a default config > with Guix with which these p2p backends could just work out of the box, = but... let's hope that i'm wrong! > > and then there's the issue of payments: it's not obvious that a random c= lient can just upload binaries into a p2p storage network. > on some p2p networks someone needs to pay for that, and i don't yet unde= rstand well enough how the data is authorized through > payments (they are called postage stamps in swarm). > > a good, high level comparison of p2p storage solutions would be useful. > > --=20 > =E2=80=A2 attila lendvai > =E2=80=A2 PGP: 963F 5D5F 45C7 DFCD 0A39 > -- > =E2=80=9CThere is something in the human spirit that will survive and pr= evail, there is a tiny and brilliant light burning in the heart of man > that will not go out no matter how dark the world becomes.=E2=80=9D > =E2=80=94 Leo Tolstoy (1828=E2=80=931910)