From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 02 10:07:44 2022 Received: (at 52555) by debbugs.gnu.org; 2 Feb 2022 15:07:44 +0000 Received: from localhost ([127.0.0.1]:53068 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nFHET-0004wP-9L for submit@debbugs.gnu.org; Wed, 02 Feb 2022 10:07:44 -0500 Received: from xavier.telenet-ops.be ([195.130.132.52]:41928) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nFHEQ-0004wD-43 for 52555@debbugs.gnu.org; Wed, 02 Feb 2022 10:07:40 -0500 Received: from ptr-bvsjgyhxw7psv60dyze.18120a2.ip6.access.telenet.be ([IPv6:2a02:1811:8c09:9d00:3c5f:2eff:feb0:ba5a]) by xavier.telenet-ops.be with bizsmtp id qF7b2600C4UW6Th01F7cfL; Wed, 02 Feb 2022 16:07:36 +0100 Message-ID: <45e1dd2f05c6733eb74792af07194347fdd55ebd.camel@telenet.be> Subject: Re: [bug#52555] [RFC PATCH v2 0/5] Decentralized substitute distribution with ERIS From: Maxime Devos To: pukkamustard Date: Wed, 02 Feb 2022 16:07:31 +0100 In-Reply-To: <8635l1h1mx.fsf@posteo.net> References: <20211216161724.547-1-pukkamustard@posteo.net> <20220125192201.7582-1-pukkamustard@posteo.net> <86fsp1h6ce.fsf@posteo.net> <846716544b4424f02e383114ebcb52957b43dd4d.camel@telenet.be> <8635l1h1mx.fsf@posteo.net> Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-3lXz/ldhBv2+wwdvsJIY" User-Agent: Evolution 3.38.3-1 MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telenet.be; s=r22; t=1643814456; bh=3HVagiaD37/TWambj2cRkJ/5KrREtKSPiKMSvmPXFXc=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=oUMRtSHu2XbpoZpF7vZOQGdJANKwmXgsaWP5GVmEit/o/admL+Kpek9NI8PQBTQZD hPV62qQbjPgk25OvVJTWUgfi7oNmtrMtrNcCJuHOh1XaDgpNjgalWBtVyhTM3Qtg/K D2Xrztdrats76E1iE5ldL/CjHrLVHqryM3+1E0tyybozgWCiJMiVFBZP5/WJH6fTP4 U/qHQeL7Pyjr6KilNwQyVZZiX/pMSXZyLbMq70cDsPDSb9J2HaiDKezxACGdnupD5E yDgiy9pE6N4ZPEsvaQPGlQdhehAPco3CLbk8FSDHDGgpQ8g7dlGC1VCV59P9ifGOp5 2qT95H5azUg8A== X-Spam-Score: -0.7 (/) 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: -1.7 (-) --=-3lXz/ldhBv2+wwdvsJIY Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable pukkamustard schreef op wo 02-02-2022 om 12:42 [+0000]: > > (Afterwards, the client should insert the block(s) back into > > IPFS/GNUnet/whatever, maybe using this proposed =E2=80=98in-file block > > store=E2=80=99 > > such that other clients (using the same DHT mechanism) can > > benefit.) >=20 > 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"? >=20 > 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. If re-inserting missing blocks back into the IPFS/GNUnet/whatever is made optional and is off by default, then=C2=A0almost nobody will enable th= e =E2=80=98caching peer=E2=80=99 option and we will have freeloaders, somewha= t defeating the point of GNUnet/whatever. In a classic setting (=E2=80=98plain old HTTP=E2=80=99), serving and downlo= ading is a separate thing. But in a P2P setting, downloading cannot be separated from uploading -- strictly speaking, a peer might be able to download without uploading (depending on the P2P system), but that's anti- social, not something that should be done by default. However, if re-inserting missing blocks is _on_ by default, then there doesn't seem to be any trouble. Greetings, Maxime. --=-3lXz/ldhBv2+wwdvsJIY Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iI0EABYKADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYfqeNBccbWF4aW1lZGV2 b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7hI+AQCyLDdDhhLnScMBo6MNl55F+DKo Yaje3fToELjEOBmOUAD/YOvJCAsYd7BILqDAImAt4T8s+UnANcKzVtbWKXbklwc= =ttyT -----END PGP SIGNATURE----- --=-3lXz/ldhBv2+wwdvsJIY--