unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Attila Lendvai <attila@lendvai.name>
To: Maxime Devos <maximedevos@telenet.be>
Cc: Vijaya Anand <sunrockers8@gmail.com>,
	pukkamustard <pukkamustard@posteo.net>,
	guix-devel@gnu.org
Subject: Re: [GSoC 23] distributed substitutes, cost of storage
Date: Tue, 04 Apr 2023 10:53:48 +0000	[thread overview]
Message-ID: <rXuLs3NCSQTe_pC362Fi1lKgzkb5q8LgbmtfiOSUDBX5aiKQtg28aLV0c4J4WPyZGTzTKBcJBRcXnmNEZXIHbrVLBX63Tsz-AwTuqXXbeyw=@lendvai.name> (raw)
In-Reply-To: <543c3687-43c5-02d9-cc3a-8e62435ffd95@telenet.be>

> > it's another question whether this mirroring should be enabled by default in the clients. probably it shouldn't,
>
>
> It probably should -- if things aren't mirrored, then it's not p2p; you
> would lose the main performance benefit of p2p systems.
>
> More cynically, some p2p systems (e.g. GNUnet) have mechanisms to
> disincentive freeloaders -- clients that aren't being peers will get
> worse downloading speed.


any successful p2p solution must have an incentive system that makes attacks expensive (freeloading, DoS'ing, censorship, etc). arguably, the most important difference between the various solutions is what this incentive system looks like.

from a bird's eye view perspective, there are two fundamental architectures of p2p storage networks (that i know of):

 1) ipfs-like, or torrent-like, where the nodes register/publish what
    they have in their local store, and other nodes may request it
    from them

 2) swarm-like, where the nodes are responsible for storing whatever
    content "is" in their "neighborhood". (block hashes and node ids
    are in the same domain, so there's a distance metric between a
    block and a node). put another way: Swarm stores not only the
    metadata in the DHT, but also the data itself.

in 1) there's no need to pay for, and to upload content into the network. a node just registers as a source for whatever content it has locally, and then serves the incoming requests.

but if you have content that you want to make available in 2) then you need to make sure that this content gets to a set of distant nodes that will store it. this is very different from 1) from a game theoretic perspective, and can't be done without some form of payments/accounting.

in 1) it's simpler for a node to share: just give away your storage and bandwidth to the network.

in 2) it's more complicated, because if your node is requesting other nodes to do stuff, then you're spending a more complex set of resources than just your bandwidth, potentially including some crypto coin payments if the balance goes way off.

but both cases are fundamentally the same: users are spending their resources, and i wouldn't expect that installing a linux distro will start spending my network bandwidth, or any other resource than my machine's local resources.

but this of course can change, too: maybe a future Guix release can advertise with big red letters on the download page that installing it will use your network bandwidth to serve other guix nodes, unless it is turned off. and then all is well WRT informed consent.

--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“Historically, the most terrible things - war, genocide, and slavery - have resulted not from disobedience, but from obedience.”
	— Howard Zinn (1922–2010)



  reply	other threads:[~2023-04-04 10:54 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-25 19:00 [GSoC 23] distributed substitutes, cost of storage Attila Lendvai
2023-03-26 20:06 ` Vijaya Anand
2023-03-26 21:19   ` Attila Lendvai
2023-03-28 20:19     ` Vijaya Anand
2023-03-29  8:45       ` Andreas Enge
2023-03-29  9:26         ` pukkamustard
2023-03-29  9:34       ` pukkamustard
2023-03-30 11:08 ` Maxime Devos
2023-04-04 10:53   ` Attila Lendvai [this message]
2023-04-04 18:51     ` Maxime Devos
2023-04-05  7:19       ` Attila Lendvai
2023-04-06  8:13     ` Simon Tournier
2023-04-07 22:45       ` Attila Lendvai
2023-04-08  0:46         ` Csepp
2023-04-08 16:05           ` Attila Lendvai
2023-04-08  9:30         ` Simon Tournier
2023-04-08 15:53           ` Attila Lendvai

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='rXuLs3NCSQTe_pC362Fi1lKgzkb5q8LgbmtfiOSUDBX5aiKQtg28aLV0c4J4WPyZGTzTKBcJBRcXnmNEZXIHbrVLBX63Tsz-AwTuqXXbeyw=@lendvai.name' \
    --to=attila@lendvai.name \
    --cc=guix-devel@gnu.org \
    --cc=maximedevos@telenet.be \
    --cc=pukkamustard@posteo.net \
    --cc=sunrockers8@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).