> I want to go one further: WHY does a regular user need to buy a human-readable domain name, maintain it, and pay for a hosting company to host on that domain?
Because there's no interest in that. Getting a domain name is already cheap and easy.
> Storing chunks of encrypted data using Kademlia DHT or similar [...]
I've yet to see any P2P system have low latency, high speed and high reliability.
> All underlying URLs would be non-human-readable and clients would display (possibly outdated) metadata like an icon and title (this metadata may change on the Web anyway). Storing and sharing could occur using QR codes, NFC bluetooth, Javascript variables, or anything else. For static files, the links could be content-addressable.
Why?
> The only “downside” is the inability to type in a URL.
Good luck saying to your friend the nice webstore you got your hoodie from is [insert non-readable non-pronounceable url].
> and third party private ownership/stewardship of user-submitted content would be far less of a foregone conclusion
This is unacceptable for law enforcement
> If you are intrigued by this architecture, and want to learn more or possibly get involved, contact greg+qbix followed by @ qbix.com - we are BUILDING IT!
I'm not trying to advertise, but Beaker browser does a real good job of making p2p delivery transparent to the end user. It's probably slower than most sites in normal usage, but certainly acceptable speeds for static sites, and it performs better under the hug-of-death a site gets when posted on Hacker News. :)
Plus, it already has existing methods to map DNS records or servers to the p2p records, so I can access dat://beakerbrowser.com/ or dat://epa.hashbase.io/ and get it served across the p2p network or pull it up offline if I've viewed it before.
Because there's no interest in that. Getting a domain name is already cheap and easy.
> Storing chunks of encrypted data using Kademlia DHT or similar [...]
I've yet to see any P2P system have low latency, high speed and high reliability.
> All underlying URLs would be non-human-readable and clients would display (possibly outdated) metadata like an icon and title (this metadata may change on the Web anyway). Storing and sharing could occur using QR codes, NFC bluetooth, Javascript variables, or anything else. For static files, the links could be content-addressable.
Why?
> The only “downside” is the inability to type in a URL.
Good luck saying to your friend the nice webstore you got your hoodie from is [insert non-readable non-pronounceable url].
> and third party private ownership/stewardship of user-submitted content would be far less of a foregone conclusion
This is unacceptable for law enforcement
> If you are intrigued by this architecture, and want to learn more or possibly get involved, contact greg+qbix followed by @ qbix.com - we are BUILDING IT!
Oh this is an ad...