[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [GSoC 23] distributed substitutes, cost of storage
From: |
Maxime Devos |
Subject: |
Re: [GSoC 23] distributed substitutes, cost of storage |
Date: |
Tue, 4 Apr 2023 20:51:19 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.2 |
Op 04-04-2023 om 12:53 schreef Attila Lendvai:
Onderwerp:
Re: [GSoC 23] distributed substitutes, cost of storage
Van:
Attila Lendvai <attila@lendvai.name>
Datum:
04-04-2023 12:53
Aan:
Maxime Devos <maximedevos@telenet.be>
CC:
Vijaya Anand <sunrockers8@gmail.com>, pukkamustard
<pukkamustard@posteo.net>, guix-devel@gnu.org
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.
GNUnet is (1) but also more than that, because of the automatic pushing
to other nodes. To my understanding it's not (2), but at the same time
your comment about (2) applies.
Also, this crypto coin balance problem can be avoided by simply not
basing your P2P system on money (crypto coins or otherwise); it's a
problem that those systems invented for theirselves.
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.
Network bandwidth (and storage) _is_ a local resource.
Also, how are you going to keep your distribution up to date or install
new software without allowing your distribution to spend network
bandwidth? -- For non-P2P systems, it is already the case that that
network bandwidth is spent by the local machine, P2P systems just makes
it more symmetrical and hence fairer.
More to the point, recalling that this is a reply to my statement that
mirroring should be enabled by default:
>> 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.
... and noticing that you are making a distinction between the resources
of the user and others:
‘users are spending _their_ sources, and i wouldn't expect that [...]
will start spending _my_ network bandwith, [...], _my_ machine [...]’
(emphasis added)
... it appears that your view is that it's ok to spend resources of
other people even without trying to reciprocate (*), and that it is
unreasonable to expect reciprocation by default?
(*) I'm not claiming that not reciprocating is always bad -- it's a
reasonable thing to not do when on a very limited plan. Rather, the
point is that reciprocating by default is reasonable and that in
reasonable circumstances, not reciprocating is unreasonable.
I mean, given how you are a proponent of crypto, you appear to be a
capitalist, so I'd think you are familiar with the idea that to use
resources of other people, you need to compensate them (in money like
with Swarm or in kind like with P2P systems (*)).
(*) I don't consider Swarm to be a P2P system -- Swarm _by design and
intentionally_ actively maintains a class distinction between customers
(people paying for storage and uploading) and, let's say, entrepreneurs
(people getting paid for storage and downloading). While sometimes a
customer might also be an entrepreneur, by this inherent difference
between customers and entrepreneurs in Swarm, by definition they aren't
peers.
What also confuses me in that you appear to simultaneously subscribe to
the view that it's fine to not compensate people _and_ the view that
stuff should be paid -- for P2P systems with a quid-pro-quo system (like
e.g. GNUnet), you believe it's unreasonable to automatically do the quid
pro quo by default:
‘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.’
whereas at the same time you are an proponent of monetary systems like
Swarm that are based on literally paying the person whose resources you
are using.
More explicitly, I have a question: what makes the 'quid-pro-quo' and
'literally money' systems so different that you think it's
_unreasonable_ to expect people to _follow the basic principle of the
quid-pro-quo system_ by default and _reasonable_ to just exploit the
quid-pro-quo systems (i.e. by not doing the expected quid-pro-quo), and
unreasonable to do exploiting (i.e. not paying) on 'literally money'
systems?
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.
That's ‘consent’ the same way that cookie banners without a "Reject"
button (*) are consent. It's certainly ‘Informed’ and it's useful to
warn people with low or expensive bandwidth to minimize the bandwidth
limits in the GNUnet configuration, but to call it ‘consent’ is
doublespeak. I would prefer to not have doublespeak and instead to be
honest that it's a requirement for installing Guix instead of twisting
things into ‘consent’.
(*) Some variations are possible, e.g. a 'Reject all’ button that
ignores the ‘Legitimate interest’ parts, and where you need to disable
all illegitimate interests one-by-one which just takes a huge amount of
time. Also cf. contracts of adhesion, e.g..
This paragraph also makes a false assumption: it assumes that Guix
_will_ use network bandwidth to server other Guix nodes, even though it
would presumably be still an option to use the central substitution
server (likely not the recommended option, but still an option, at leas
for a transition period).
Furthermore, this seems an illogical place to put such a warning --
there already is a place to put installation instructions and warnings:
the manual! The Guix manual already has several warnings (just search
for ‘Warning’), and there does not appear to be a fundamental difference
between the new proposed warning about network bandwidth and the old
warnings.
IIRC, the manual has a section on configuring which substitute servers
to use (and presumably that part of the manual will later be extended
with info about P2P substitution). Likewise, IIRC, substitution is not
enabled automatically, instead, there is some menu for configuring
substitution. The manual and that configuration menu seem way better
places to me.
Greetings,
Maxime.
OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature