The solution I thing will come up is again hashes. Now we have hashes for file handling (in git), hashes for users in Google+, hashes for money (bitcoin). I think we are going towards a world full of hashes (pun half-intended).
If we had a single hash used for identifiying a piece of content (eg a given blog post, the home for this blog, a comment to this blog post), then a web site would just be a hash table, you would ask for hash 3ed44a2d38 and get the content. That may include other hashes. Then search engines would just be weighted keyword->hash tables. Content would be passed along servers and proxies in a p2p way. Because hash is unique to a content, you won't care if the bits are served by X or Y, as long as the hash checks.
Then no need for domain names anymore: Wanna go to BBC website? Search for BBC and pray your search engine has it as #1. Wanna bookmark the home of BBC website or an article? Store the hash.
Issues:
- Over reliance on search engine and links. Answer: we do have this issue already.
- Authentication of content: is this really BBC website? This can be fixed similarly to current certification system, and you would certify your main home's hash.
- BS! That's no real hash! What do I mean? Yes, right, the main issue is that content is changing, so a real hash would be changing too. I said google user id is a hash, that's wrong (or is it?), it looks like one though. I have been fiddling too much with git recently. For me the best of the world is when files, dirs, actions, everything is unique, unmodifiable, and identified per its hash. Any modification of the state of the world generates new content, relations, and their hashes. Infinite history for free. But how to apply this to the Web? Can we? Nearing one o'clock in the morning here: I may clarify tomorrow.