Will there be a Distributed HTTP?

Being annoying to attack is not superior to the level of trust and certainty made possible with technologies such as DANE and DNSSEC. Which is to say that I agree with you that we should replace authority with better technology, but bitcoin is not such a better technology.

> Ultimately, it was a losing game, because of the inherent conflict of interest between software author and software user.

This is exactly what is broken with our current software business models. On-prem software is expensive to deploy and manage but gives users control of their data. SaaS software is cheap to deploy and manage but takes control of the user's data. We must find middle ground between the two models. A solution that takes the best of both on-prem software and cloud based SaaS services may be that middle ground, but it's going to require a globally federated cloud.

Here's an article from a few months talking about this concept: http://venturebeat.com/2015/05/09/goodbye-saas-hello-contain.... The basic premise is that ISVs should be able to deploy their stacks on-prem, similar to the way they deploy to their SaaS-based solutions today.

I've been kicking around a slightly modified vision for a new software model I call MSaaS for about 3 years now after spending an inordinate amount of time thinking about infrastructure trust. MSaaS is short for managed software as a service. The idea is to build a federated platform for storing/signing code and images used to deploy applications, infrastructure deployment targets which carry various levels of trust, and a method for payments and identity management for settling resource consumption, including development time.

First, MSaaS needs to have a means by which an ISV's software components, such as source code or images, can be placed an immutable data structure similar to a blockchain. IPFS' merkle DAG is one such example of a blockchain that allows for immutable, decentralized data storage with signing capabilities. It allows for a company to sign a given piece of code, stuff it, and the accompanying configuration information, into an immutable data store, and make it globally accessible in a trust-less manner (i.e. anyone can fetch it anonymously). Bits can be signed and/or encrypted using public keys where needed for privacy and security.

Side Note: IPFS has an interesting 'problem' with it in that if a node containing data goes away, it is lost from the network. That's actually acceptable here regarding the source code or images users would need to pull to run applications or services as the code could be pulled from one or more centralized repositories (Github) by a trusted authority, built into an image, re-signed and then placed back on the network on-demand. Keys/configuration bits could be shared in a similar manner, or handled a tad bit differently for backups.

Second, MSaaS will introduce the idea of multiple trusted deployment target endpoints, such as those provided by AWS, Digital Ocean, OpenStack running on-prem in a DC, or even your local computer. These deployment targets respond to cryptocurrency payments and provision themselves where the trust levels exist between parties (or depending on the use-case, don't exist) using the data stored in the previously mentioned merkle DAG/blockchain. The payments themselves represent identity in the form of signing keys (which can be related to the keys used to sign the code/images) and payment for resources, perhaps including a managed service provider along the way. For example, if your images need to be built from code, you enter into a relationship with XYZ Container Builders, Inc. and they become responsible for building and signing your images. Payment chains are used to tie these transactions together.

Finally, we'll need search engines to assemble all this together into a cohesive offering that anyone can join or use. Searches for trust, compute power, storage costs, network speeds, container specs, etc. can all be included in the results returned.

I would note that the first thing people usually ask when I talk about this stuff is "How can I trust XYZ provider with my data/code?". The answer is that you establish relationships with individuals who provide you software and/or infrastructure that is a fit based on your particular use-case's trust needs. If you have sensitive data you don't trust anyone with, then deploy the application on-prem in your own cloud and don't allow the software company to remotely manage it. If it's a CI test on a public repo, who cares who does that as long as consensus is reached on the outcome over time?

HTTP2 isn't, it's binary.

Version control is not a solution to the problem of shared state in a distributed system.

> Finally, cutting the server out of the equation is seen as an opportunity to reset the Web’s balance of power regarding cookies and other forms of tracking; if you don’t request content from its owner, but instead get it from a third party, the owner can’t track you.

This is somewhat of a concerning line. Off the bat, I imagine it's not outside of the realm of possibility that CDNs could collude with "trackers". Yes, idealistically, a completely distributed model performs in such a way that provides no favor to any particular individual. But I don't think it is anywhere near close enough to being proved that the free-rider problem won't skew the issue towards providing trackers a de facto centralization.

Also, this doesn't eliminate other bottlenecks, like tapping into internet exchange hubs. If there are too many CDNs with which to collude, there are certainly not too many hubs. It works better for them, actually, as they can start dragnetting traffic completely outside of even more modern tracking systems like Super Cookies.

We have long past the point that people can no longer intuitively understand what data they leak on the network.

A little bit confused here. HTTP is already distributed, right? It's an open protocol with a very large number of servers serving a variety of content with little to no coordination.