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.
-----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-----