There is some hope that WebRTC and other p2p technologies might alleviate the problem but then the task of punching through firewalls with techniques like STUN falls on developers. I'm not seeing an industry-led campaign to standardize a true p2p protocol based on something like UDP, because it would undermine the profits of data producers.
I could go into how the proper layering of TCP should have been IP->UDP->TCP instead of IP->TCP and a whole host of technical mistakes such as inability to set the number of checksum bits, use alternatives to TCP header compression, or even use jumbo frames over broadband, but what it all comes down to is that what we think of as “the internet” (connection-oriented reliable streams and the client/server model) is not really compatible with a distributed content-addressable connectionless internet that can work with high latencies and packet loss.
I think if this network existed, then extending HTTP to operate in a p2p fashion wouldn’t be all that complicated. Probably the way it would work is that you’d request data by hash instead of by address, and local caches would send you the pieces that match like BitTorrent. Most of the complexity will center around security, but I think Bitcoin and other networks of trust point the way to being able to both prove one’s identity and surf anonymously.
Tim Berners-Lee may not be thinking about the problem at this level but we need more people with his clout to get the ball rolling. I wasted a lot of time attempting to write a low-level stream API over UDP for networked games before zeromq or WebRTC existed and ended up failing because there are just too many factors that made it nondeterministic. It’s going to have to be a group effort and will probably require funding or at least a donation of talent from people familiar with the pitfalls to get it right. Otherwise I just don’t think a new standard (one that makes recommendations instead of solving the heart of the problem) is going to catch on.
You know, the speed at which SPDY has caught on has given me hope. Admittedly, that's at the application layer, but I think if Google were to get behind an initiative to create a better TCP, it would actually have a chance at working. Historically, Google's incentives were properly aligned with a decentralized Internet, but Google is more and more a content producer. So I'm not sure.
Until then, we'll have to rely on servers to bootstrap peer-to-peer networks, even Bitcoin, Bittorrent, and yes, WebRTC.
I don't think Google has much interest in a decentralized web. Google, along with Facebook, are two of the prime examples of a centralized web.
http://highscalability.com/google-architecture
Unfortunately, with the existing architecture and infrastructure along with the team resources, they are focusing more on the algorithms of machine intelligence and AI.
You might find QUIC interesting (being implemented on chrome):
http://blog.chromium.org/2013/06/experimenting-with-quic.htm...
The "SPDY" application layer its implemented on top of it.. working at UDP.. so in theory, one can implement other sorts of applications layers on top of it..
Not as NAT friendly as you might think. There's a fair bit of discussion in the QUIC design document[0] around how NATs screw up the protocol and how to mitigate the problem.
[0] https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqs...
The WebRTC connection is bootstrapped through a server (STUN and TURN), but that's the case with almost all peer-to-peer software (take a look into how Bitcoin or Bittorrent is bootstrapped if you don't believe me). But anyone can run a STUN and/or TURN server.
Once the connection is bootstrapped, it's entirely peer-to-peer between browsers.
It's the current philosophy of "web apps" and not "hypertext" that isn't decentralization.
The problem is not technical, it's social, political and economical.