Re: [GSoC 23] distributed substitutes, cost of storage

[Maxime Devos <maximedevos@telenet.be>]

[-- Attachment #1.1.1: Type: text/plain, Size: 8791 bytes --]



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.

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]