I'm all for decentralized apps, but before venturing into that kind of complexity, how about getting back control over the Web? It was created as decentralized net (if not in the blockchain sense) and is the work of an entire generation.
Current web tech is inherently centralizing. Say you want to create an experience like Instagram or Twitter, delivered via HTTP. You have to pay for bandwidth, CDNs, storage, app servers, DB servers, etc etc. At scale, it's millions a month. So only corporations can do it, and with a few exceptions (eg Craigslist, Stack Exchange) they end up monetizing and "growth hacking" in user hostile ways.
The big open question is: can we create an experience as compelling as Instagram or Twitter over the P2P web?
It's a hard technical challenge, and today the answer is no. But if we get there, then internet mass media can be delivered via open source projects over open protocols, with a bunch of competing clients to chose from. No central organization controls and monetizes the thing.
Like BitTorrent, but for applications more complex and interactive than just file sharing.
--
If you're interested, here are imo the most compelling projects in this space:
- Dat
- Beaker
- Augur
- OpenBazaar
- Patchwork / Secure Scuttlebutt
They are working on overlapping subsets of the same fundamental challenges, eg:
- How does a node choose what to download? The BitTorrent answer is "only things the user explicitly asked for". The blockchain answer is "the entire global dataset since the start of time". For something like a decentralized Twitter, both of those are unsatisfactory, you need something in between.
- How do you log in? Current systems either have no persistent identity at all (eg BitTorrent) or they just generate a local keypair, and it's your job to back it up and never lose it (eg SSB, Dat, all blockchain protocols). Both are unacceptable for wide-audience social media. Ppl lose their devices, get new devices, forget their password, etc all the time. They expect and rely on password reset, etc.
So there's a lot of hard tech and UX problems left unsolved, but also a lot of recent projects making solid progress
You can make some nice proof-of-concepts with a group of volunteers, but the effort required to provide a UX comparable to centralized services is going to take more than a handful of people working evenings and weekends.
Decentralized services generally do not afford the same monetization opportunities as central services. Decentralized proponents consider this a feature rather than a bug, but it leaves open the question: Who is going to pay for all of this?
Facebook had $20.4 billion in operating expenses in 2017. Less than 1/3 of that was the cost of its 25,000 employees (at the end of 2017). Facebook is spending more on its infrastructure than it is on all of its employees combined (and that much more when you reduce it to just engineers). Engineers are maybe 1/5 of its operating costs, including their all-in costs.
Both Facebook and Alphabet had roughly $15 billion in total capex for 2017. Data centers, networks, electricity, et al. cost a lot at that scale. It's not a pittance. Facebook spent ~$7 billion in 2017 on capital expenditures related to their network, data centers, etc.
Facebook's first Asia data center is a billion dollars to just start up.[1] When they put up new data centers in places like Henrico County VA, New Albany OH, or Newton County GA, it's similarly nearly a billion dollars a shot to start those up. Once you have dozens of those operating, it's billions of dollars per year to operate them all.
[1] https://money.cnn.com/2018/09/06/technology/facebook-singapo...
Two engineers can't do twice as much as one engineer. Perfecting the ordering of the news feed is significantly less valuable to users than just having a news feed in the first place. Building a speech-to-text engine that works 99% of the time costs hundreds of millions of dollars more than one that works 95% of the time, but is it worth that much to users? Think of the number of engineers at Facebook or Twitter who just work on infrastructure, or supporting other engineers, or perfecting ad placement to improve CTR by 0.5%. All of these are tangential to the core experience, in many cases required or at least valuable only because Facebook is so big.
I can't just pick on Facebook here; this is why all companies will always get disrupted. Massive layers of scale behind the scenes to support products that are fundamentally simple, combined with advancing publicly available technologies helping newcomers.
I think your point on UX/UI is an important point though. Open source has a turbulent history with functional UX. We’ve done an incredible job helping the technical communities understand why open source is important but because so many of us are technically focused, we’ve fallen somewhat short on helping UX and design focused communities understand why open projects are important, on a deep level, in much the same way technically focused understand.
If we’re aiming for mass adoptions across the spectrum, onboarding the UX/UI communities is as important as it was for the technically focused to understand.
Also, there is another point worth considering, someone recently made a convincing argument to me that sometimes mass adoption may not be a good thing. Mass adoption leads to eternal September and depending on what the project is, eternal September may destroy a community. A project with a solid technical foundation but difficult UX/UI experience can be a good barrier to prevent eternal September.
> It's a hard technical challenge, and today the answer is no.
This is why I completely dismiss almost every "distributed" solution. If you can show me a business model/design document for a distributed service that can scale to big tech levels, deliver a user experience that matches current solutions, while also incentivizing developers enough with money to get them to build it, I will be swayed. However, every solution I have seen makes massive tradeoffs that negatively affect all 3 criterias compared to current centralized solutions.
If you need another example google a tool called "git". It is used by almost all software developers nowadays and even by quite a few authors. You don't need to setup anything to use it. If you have ssh you can just share your text based data with others by giving them access to your repository's directory. I bet it transfers more MB/day than Twitter. But nobody counts it because it's so distributed that it's hard to put an owner label on it. (Although the originators can be named quite clearly.)
And sure, you can use git by itself and send the diffs to each other over email. However, then you have to deal with coordinating where the head is which is a pain across every node since it is constantly changing. Thus, most people don't do it that way and instead use a centralized service like github.
Why not send it via ssh? It's much easier. And if the data is not too big you don't send diffs but complete file states. Git usually calculates the diffs on the fly by comparing two file states.
Decentralized serving has just as much bandwidth, storage, and iron (if not more). Does it somehow make those resources cheaper?
For example, in 2016 a friend of mine and I made an electron app called WebTorrent Desktop. It has over a million downloads. The total bandwidth transfer so far is probably a lot--wild guess, maybe a few million dollars worth?
But it is free and open source and costs roughly $0 to run--just enough to keep the website up. That's the magic of decentralization--you're simply writing software. You're not running a service.
--
Consider the total monthly internet bill of all Twitter users combined. Extremely rough guess, 500 mil montly actives * $40/mo for Comcast or something = $20b per month.
The crowd has more than enough bandwidth, disk space, and CPU cycles to run services at any scale. That's another magical aspect of dapps: the total resources available to the system automatically scale with the number of users. It's up to us to figure out how to harness it.
That's the point.
Disclosure: I'm working in this field.