Features of a post-HTTP Internet?

Ars-Fartsica asks: "We've been living with HTTP/HTML ("the web") for a quite a while now, long enough to understand its limits for content distribution, data indexing, and link integrity. Automatic indexing, stateful-ness, whole-network views (flyovers), smart caching (P2P), rich metadata (XML), built in encryption, etc are all fresh new directions that could yield incredible experiences. Any ideas on how you would develop a post-HTTP/HTML internet?"

The question indicates misunderstanding

[SpaceLifeForm]

The Internet is not just HTTP.

Please study TCP/IP better before you ask such a question again.

What about the non-HTTP Internet?

[Gothmolly]

You gloss over, with a sweep of your clueless wand, the rest of us who rely on the Internet for things like SMTP, SSH, Muds, Usenet, IM and VPNs.
Please don't assume that my Internet is the same as your Intarweb.

Re:Forget HTTP.

[0x0d0a]

This will never happen unless systems like cacert.org start to take off.

Or decentralized trust systems, but yes.

Basically 99% of the internet don't give a damn about certificates, and the ability for anonymity is more limited.

Not really. I can create multiple electronic personas, unless you're trying to enforce a 1:1 id:person ratio.

2. SPF-like protocols - This is the ability to discriminate who is and who isn't allowed to send email from a given domain. This will cause a few things:

Where "SPF-like protocols" means "authorization protocols", yes. The problem is really nothing more than an authorization protocol, and not a very good one at that.

I disagree with you that authorization should take place on a domain level (unfortunately, this is the approach that the SPF people use). By doing so, it means that, say, a single account at ford.com is ever compromised by a baddie, it means that the only solution with domain-level granularity systems is to ban the entire domain.