Login

Redecentralize

We’ve had enough of digital monopolies and surveillance capitalism. We want an alternative world that works for everyone, just like the original intention of the web and net.

We seek a world of open platforms and protocols with real choices of applications and services for people. We care about privacy, transparency and autonomy. Our tools and organisations should fundamentally be accountable and resilient.

Home

Parent
Michael Rogers [LibreList] Re: [redecentralize] Thoughts on decentralization: "I want to believe." 2014-08-07 17:32:09 (6 years 7 mons 28 days 14:10:00 ago)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi Adam,

This is a great post. I share your frustration with the difficulty of
building decentralised systems that are usable, efficient and secure.
But I have some doubts about your argument.

I don't think the Tsitsiklis/Xu paper tells us anything about
centralisation vs decentralisation in general. It gives a very
abstract model of a system where some fraction of a scarce resource
can be allocated wherever it's needed. I'm not surprised that such a
system has different queueing behaviour from a system with fixed
allocation. But it seems to me that this result is a poor fit for your
argument, in two respects.

First, the result doesn't necessarily apply beyond resource allocation
problems - specifically, those problems where resources can be moved
from place to place at no cost. I don't see the relevance to the
lookup and routing problems you're aiming to solve with ZeroTier.

Second, the advantage is gained by having a panoptic view of the whole
system - far from being a blind idiot, the allocator needs to know
what's happening everywhere, and needs to be able to send resources
anywhere. It's more Stalin than Lovecraft.

I'm not denying that a touch of centralisation could help to make
ZeroTier more usable, efficient and secure - I just don't think this
paper does anything to support that contention.

You mention split-brain and internet weather as problems ZeroTier
should cope with, but I'm not sure centralisation will help to solve
those problems. If the network is partitioned, some nodes will lose
contact with the centre - they must either stop operating until they
re-establish contact, or continue to operate without the centre's
guidance. A distributed system with a centre is still a distributed
system - you can't escape the CAP theorem by putting a crown on one of
the nodes.

It's true that nobody's been able to ship a decentralised alternative
to Facebook, Google, or Twitter. But that failure could be due to many
reasons. Who's going to buy stock in a blind-by-design internet
company that can't target ads at its users? How do you advertise a
system that doesn't have a central place where people can go to join
or find out more? How do you steer the evolution of such a system?

All of these questions are easier to answer for infrastructure than
for public-facing products and services. Facebook, Google and Twitter
sit on top of several layers of mostly-decentralised infrastructure.
Since you're building infrastructure, I wonder whether it would be
more useful to look at how centralisation vs decentralisation plays
out at layers 2-4, rather than looking at the fully-centralised
businesses that sit on top of those layers.

The blind idiot god is a brilliant metaphor, and I agree it's what we
should aim for whenever we need a touch of centralisation to solve a
problem. But if we take into account the importance of metadata
privacy as well as content privacy, I suspect that truly blind and
truly idiotic gods will be very hard to design. A god that knows
absolutely nothing can't contribute to the running of the system. So
perhaps the first question to ask when designing a BIG is, what
information is it acceptable for the BIG to know?

Cheers,
Michael

On 02/08/14 00:07, Adam Ierymenko wrote:
> I just started a personal blog, and my first post includes some
> thoughts I've wanted to get down for a while:
> 
> http://adamierymenko.com/decentralization-i-want-to-believe/
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBCAAGBQJT46oJAAoJEBEET9GfxSfM+qkH/24J+2VPW4kOokwA20PAg285
Fk9Snzuuz7ruP9qIfuMJVfN5k7+01on7H/VnDuW6gAnc8oGTqye9RWQzmCzMbghe
Z2CzadRufFDTgPYk73pyLWAlFLujqu0N/cqHeWGqw8K7wmDmfucnnimKEnQQ2eBP
uODbPyJUzc3NahRE42yMeXurC7A0HlcHyMhg7rPkdGZVzJzQ9RDJAkLVo+lpdJ3V
ovBpN+QjMg9IJoTKH1Rc5pApTZawoBFPap/o7s3PWLdDY8CL8Oyie2N0NwfyFrVe
fN6xBva1PuZ7I2rNhzQijy7hDRhGFeVMH3z6sI2OiUT/UUsHLpHbIEukq9x28c8=
=4/Oc
-----END PGP SIGNATURE-----
: