Closed du5t closed 8 years ago
For explaining distributed vs decentralized vs centralized, this graphic is the best visual I'm aware of:
Source: https://twitter.com/ioptio/status/597113993401098240 + https://github.com/ioptio/design/tree/master/networks
It was specifically designed to fix the confusion that this one was creating.
Perfect, thanks! Maybe we'll even be able to get the facilitating artist to jazz it up a little.
nice diagrams, but unfortunately they somewhat contradict the terminology of paul baran's 1964 paper in which "decentralized" and "distributed" are reversed compared to the diagrams in this thread
e.g. see here for the original: http://networkcultures.org/unlikeus/resources/articles/what-is-a-federated-network/
i've seen (and used) those baran diagrams probably a dozen times at various meetups, barcamps etc during the last few years' (re-)decentralization movement
so maybe we can use the diagrams in this thread, but swap "decentralized" and "distributed"?
so maybe we can use the diagrams in this thread, but swap "decentralized" and "distributed"?
No. Decentralized and distributed are correctly labeled in the graphic above. Again:
It was specifically designed to fix the confusion that this one was creating.
(Referring to the Baran paper.)
To be clear: decentralized systems are a subset of distributed systems.
"Distributed" refers to redundancy of some resource (usually information or compute power) across nodes on a network.
"Decentralized" refers to control of those resources and a lack of a central point of failure. Distributed systems do inherently have some decentralization in the sense that they remove central points of failure of data storage (for example), but the term "distributed" does not take into consideration who controls those nodes.
For example, take Napster. Napster was a distributed peer-to-peer system in the sense that data was distributed across nodes on a network. However, it was also a centralized system in the sense that there was a single point of failure: the Napster server through which peers would find each other. This central point of control was the reason for its demise. Skype is another example of such a system (but one that survives because it complies with existing laws).
That distinction is not shown in the Baran graphic and that has caused a lot of confusion and damage that this new graphic will hopefully clear up.
"Federated" systems are merely systems that are "more decentralized" than "centralized" systems. It refers to a degree of decentralization along a spectrum. Federated systems are not at the end of "decentralized", they sit between "decentralized" and "centralized".
Note that the graphic above is also not perfect since it half-implies that all distributed systems are centralized, which is not true since decentralized systems are a subset. Technically, it shows this distinction by having the network topologies be identical in both cases, but it's still confusing.
I'm still waiting for the "perfect graphic", but until then the one above is the best we have (that I'm aware of). I really like @du5t's suggestion of getting a professional graphics facilitator.
Wait, I thought the next step in the paper process involved both the editor (Shannon) and the artist (Sonia). Am I sorely mistaken?
Wait, I thought the next step in the paper process involved both the editor (Shannon) and the artist (Sonia). Am I sorely mistaken?
I don't know and I don't have any information to the contrary, so don't worry, in that domain you'd probably know better than me. :)
Note for email readers: edited comment to add Napster and Skype as examples of a distributed, peer-to-peer, yet centralized systems.
thanks for the explanations, make sense, but not sure if the general public will understand the concept of "distributed yet centralized".
you may want to check out this blog post by phil windley for a two/three dimensional rather than linear approach to terminology: http://www.windley.com/archives/2015/01/re-imagining_decentralized_and_distributed.shtml
@taoeffect please stop stating as fact things like:
These are your semantics, not global and commonly established semantics.
In the interest of making this the last time i have to talk about these damn diagrams, i will attempt clarification. This is without following my own semantics, which are slightly different. These are the most common accepted definitions of terms. You will note that these describe properties that are related, but neither orthogonal, nor in a linear spectrum.
You can look these up in {dictionaries, wikipedia, research papers, and more}. You can see that these refer to similar and overlapping concepts, but not a spectrum. We can shoehorn these into subsets in terms of the properties we care to highlight, but there is no singular spectrum or hierarchy here.
Yes, these are different from Paul Baran's categorization. Yes these are different from your categorization. Yes these are different from my categorization. We are all typically highlighting different features to make points.
Also, by these definitions, federated and peering are the ones that talk about autonomy of decision making, and the ones you mean. An ant colony is a typical example of a decentralized system, but that is a terrible example of autonomy as we typically do not associate ant colonies as paragons of autonomous decision making. The US Command and Control hierarchy is a decentralized system with clear protocols for local decision making in the event of network partitions (including capabilities like launching thermonuclear attacks).
We don't see federated nor peer-to-peer much in our literature. Federated is a dirty word in the "decentralize all the things" groups as it's too broad, and typically used to refer to federations of large participants (states, countries, mega corporations). peer-to-peer is a dirty word because it's typically (and erroneously) associated with piracy and copyright infringement.
It does not help alleviate confusion to push the terminology one likes the most as _THE ONE TRUE _ terminology, particularly when it makes simplifying assumptions that lose lots of information, and have stark counterexamples. (for example, putting the puppeteer hand for "distributed" is wrong, as you yourself admit). Please note that I'm not saying Paul Baran's diagram is better than yours. I'm saying both highlight different properties, and we should have a right to use the one we want. Paul Baran's helps tell a history, and thus is very useful. I -- and many, many other people -- will continue to use these for a long time.
I think the modern "decentralize all the things" movements like using the word "decentralized" because it is a great term: a single, clear word, it does not have legality baggage, it does not typically get used to refer to the behaviors of groups of huge, powerful entities (e.g. federations of mega corps), and it is accurate enough (it talks about moving decision-making to the edges). Thus we call for "decentralize all the things" instead of "federate all the things" or "peer all the things", both of which in some ways are more correct technically speaking, but are much worse terms to evoke clear meaning to the widest set of people (they summon other meanings which are not meant). This is perfectly and totally fine, and we all should carry on. But it does not mean that this is categorically right. Nor it means that we should chastise Paul Baran or people who use Paul Baran's diagrams.
you may want to check out this blog post by phil windley for a two/three dimensional rather than linear approach to terminology: http://www.windley.com/archives/2015/01/re-imagining_decentralized_and_distributed.shtml
This is a fantastic link, @peacekeeper! It does a great job of illustrating the different dimensions that these words have and is in line with the accepted technical definitions of the terms.
Great find! :smile: :+1:
@jbenet I thought we'd settled this discussion last time over dinner? Anyway, it looks like we both agree that these terms do not reflect a single spectrum (something I've always maintained). The blog post that @peacekeeper found does a great job of illustrating in near-perfect clarity the different spectrums these terms refer to. If you wish to debate this, let's do it over Skype or something, as that way we'll avoid filling people's inboxes.
Paul Baran's helps tell a history, and thus is very useful. I -- and many, many other people -- will continue to use these for a long time.
If you want to use that picture to tell history lessons, I have no problem with that.
But if you want to use his graphic as a way of describing what decentralized and distributed mean, then both I and you have a problem with that, as it's a graphic that does what you above so vehemently argued was a bad idea: putting these terms on a single spectrum. I agree with you, that's a terrible idea, and that's why I am looking forward to the day that graphic becomes a historical document, not a teaching tool for explaining these concepts.
And just to make sure there's no misunderstanding, notice I also criticized what you call "my diagram" for the same reasons, which is why I was so pleased to discover the blog post @peacekeeper linked to.
i think the baran diagrams became popular a few years ago, around the time when diaspora launched and then the ostatus/status.net community emerged. at that time people called facebook "centralized", diaspora was called "decentralized" or "federated", and things like bittorrent/gnunet/retroshare/etc. were called "distributed" or "serverless". at that time, the baran diagrams were super helpful for explaining all the various new ideas.
today as our understanding and diversity of architectures evolve, we simply have a need for more precise terminology.
My feeling is that the audience of this whitepaper is going to be primarily a business one; in that case, I recommend we prioritize clarity and simplicity (from the audience's view) over precision and depth.
I think that anyone interested in this area as a business sector probably has a vague understanding of each of these terms as trends, and probably a sense of their age (and therefore relative promise), probably in this order:
In other words, the last set of terms is probably going to be the freshest, and the one we can pack the most new offerings into. I know this sounds silly, but just look at all the names machine learning's gone through in the past 30 years ;)
I'm going to try throwing in an appendix discussing the differences with this picture and see how it looks. I'll make it a PR for commentary.
Closing since paper was published. Also, looking back, this was a very exciting and stimulating thread. Thanks for your commentary, everyone.
du5t, I could not agree more. Thank you for everything you did to pull this paper together and put it out.
On Sun, Mar 20, 2016 at 6:36 PM, du5t notifications@github.com wrote:
Closing since paper was published. Also, looking back, this was a very exciting and stimulating thread. Thanks for your commentary, everyone.
— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust/issues/50#issuecomment-199080830
A lot of terminology and jargon are unloaded on a less-technical audience in this paper. This issue is for tracking them and making sure they're well-treated. A glossary may be the best choice.