Why Decentralization Matters (medium.com)

Chris Dixon has an essay about the long-term promise of blockchain-based networks to upend web-based businesses such as Facebook and Twitter. He writes: When they hit the top of the S-curve, their relationships with network participants change from positive-sum to zero-sum. The easiest way to continue growing lies in extracting data from users and competing with complements over audiences and profits. Historical examples of this are Microsoft vs Netscape, Google vs Yelp, Facebook vs Zynga, and Twitter vs its 3rd-party clients. Operating systems like iOS and Android have behaved better, although still take a healthy 30% tax, reject apps for seemingly arbitrary reasons, and subsume the functionality of 3rd-party apps at will. For 3rd parties, this transition from cooperation to competition feels like a bait-and-switch. Over time, the best entrepreneurs, developers, and investors have become wary of building on top of centralized platforms. We now have decades of evidence that doing so will end in disappointment. In addition, users give up privacy, control of their data, and become vulnerable to security breaches. These problems with centralized platforms will likely become even more pronounced in the future.

Comments

Back in my day

[llamalad]

we used to call this a "sudden outbreak of common sense"

It's not new that overwhelming centralization is bad for everyone except those who share the profits of the resulting behemoth. It's not even new in technology - google "bell system breakup".

It's only news that people are starting to talk about it in the context of the current tech giants. The underlying theme is old hat.

Non-Sequitur

[StormReaver]

During the second era of the internet, from the mid 2000s to the present, for-profit tech companiesâSâ"âSmost notably Google, Apple, Facebook, and Amazon (GAFA)âSâ"âSbuilt software and services that rapidly outpaced the capabilities of open protocols.

This is total nonsense, as they did no such thing. When protocols were involved at all, these companies built their services on top of the same open protocols everyone else used (or could have used). Where these companies outpaced everyone else was in throwing obscene amounts of money at the patent system to keep out competitors (both real and imagined), and in building internal processes and technologies to support their rapid growths.

While decentralization matters, Blockchain seems to have utility in a rather narrow set of circumstances. It is certainly not anything even remotely close to the silver bullet its proponents make it out to be.

Ha ha right

[ceoyoyo]

Blockchain is going to save us all! Because it will surely be essential to creating a place for people to chat with their friends and share pictures (i.e. virtually all of social media). And people will flock to these new saviours because they haven't had the option to use open social media systems before. But wait! These have blockchain!

Someone the other day was all excited about using blockchain for scientific publishing. I suggested they use git, since it's an already existing blockchain based document tracking system with a well proven record. Huh?

I've arrived at the conclusion that the vast majority of people, including all the ones writing articles, actually have no idea what blockchains are.

Re:Ha ha right

[ceoyoyo]

Yup, that right there is what I mean. "Git is an scm... it has nothing to do with a blockchain...." Git is an scm, yeah. But scm is a description (and a very high level one at that) of what it does, not what it is or how it works.

The heart of git is a tree-type data structure where every node on the tree contains a database transaction. A transaction in a generalized database framework is anything that modifies the database. In git, those transactions are changes to the documents you're tracking (the "diffs" you mentioned*). But the nodes also contain other things... your name, e-mail address etc. Oh, and two more things: each node in the git tree contains the SHA hash of the previous node, and the SHA hash of itself including the hash of the previous node. This data structure is called a hash tree, or Merkle tree. The defining characteristic of such a tree is that, because each node's hash depends on the hash of the previous node, you can't change a node, or it's connections, without changing all the downstream nodes, and the integrity of the whole thing is pretty quick to verify. Is this sounding suspiciously familiar yet?

So back in 1991 some comp sci dudes were playing around with some ideas involving lists of records and timestamps and hashes and stuff (your spidey sense should definitely be tingling now....). A year later they wrote this paper about using Merkle trees to collect records together into blocks and make the whole thing more efficient. Then, a decade or so later, this guy Szabo cooked up an idea he called "bit gold" that was supposed to use these chains of hash-secured records as a kind of ledger, as the basis for a payment system. Fast forward another few years and somebody using the pseudonym "Satoshi Nakamoto" wrote some stuff about "block chains" (yes, whoever he was, he had a functional spacebar) and using them as a ledger system....

Anticipating the pedants, the currently sexy implementations of block chains have a wee problem with deciding who gets to add nodes to them, a problem which (usually) isn't shared by git. So if it makes you happier, imagine that I post my github address on Slashdot and whoever guesses the password gets to make a change to the repo, at which point I change the password to something else, et cetera. And we all periodically vote about whether each other's changes are shit or not.

* unlike other scms, git doesn't actually store diffs, it stores snapshots of changed files.

So Many Buzzwards.

[jellomizer]

Don't operate your business on one vendor.

Because if you do chances are you will get burned. Because such vendor will change or go out of business.

If you have to rely on a vendor, try to minimize its impact. Like I work in a Microsoft shop... That doesn't mean for me to go all hog into all the MS API's and use those special features, tempting they are.
No you write your code in a way that porting to a different platform in case MS drops support is relatively easy.

Even if you are dealing with an Open Source product, unless you are willing to take the torch and ready to fully support it, a project can stagnate, or just never become popular, or some personally causes support to drive off into an other direction.