Thanks for the list.
> You can generate domains freely using pubkeys and without coordinating with other devices, therefore enabling the browser to generate new sites at-will and to fork existing sites.
Not entirely sure what you mean,
- We can generates HTTP sites at will (all you need is an IP address);
- We have existing protocols for mirroring sites (not implemented universally, but nor is dat://);
- When you talk about pubkeys with coordination, there are obvious problems like the last paragraph of my original comment, right? Again, I'm probably misinterpreting what you're saying.
> Integrity checks & signatures within the protocol which enables multiple untrusted peers to 'host'.
Basically subresource integrity? Granted, with this protocol you can in theory retrieve objects from any peers (provided that they actually want to cache/pin your objects), not just the ones behind a revproxy/load balancer, so that's a potential win from decentralization.
> Versioned URLs
We can have that over HTTP, but usually it's not economical to host old stuff. In this case, someone still needs to pin the old stuff, no? I can see that client side snapshots could be more standardized, but we do have WARC with HTTP.
(EDIT: on second thought, it's much easier to implement on the "server"-side too.)
> Protocol methods to read site listings and the revision history
> Standard Web APIs for reading, writing, and watching the files on Websites from the browser.
You can build that on top of HTTP too.
My takeaway is it's simply a higher-level protocol than HTTP, so it's unfair to compare it to HTTP. Are there potential benefits from being decentralized? Yes. But most of what you listed comes from being designed as a higher-level protocol.