No, that's rather easy for up-to-date browsers. The real reason is that dumb middle proxies might cache/mangle HTTP/2 requests to the point that it simply fails hard, but encryption makes those concerns go away. Yes, there are proxies that can decrypt TLS, but due to how negotiation of HTTP/2 works in TLS (ALPN), dumb proxies will simply not send the signals that it's HTTP/2 capable.

This is meh excuse. If you want your browser to connect to a gopher server, you type gopher://example.com. If you want to use http2, http2://example.com should work. (I know, I know, everyone removed Gopher support a few years ago. Same idea though.)

Having said all that, I just copied the certs out of here https://cs.opensource.google/go/go/+/refs/tags/go1.24.0:src/... and use them to do browser/http2 stuff locally. Why steal Go's certificates? Because it took 1 second less than making my own!

Using http2 as protocol in the URL makes the initial transition complex: One can't share links between different users and clients and from other websites with a guarantee of the "best" experience for the user. Not to mention all old links outside the control of the server operator.

Hey, thanks for this. It saves me even more than 1 second!

Which browsers/libraries trust these? Or does the go tool chain install them?

Nothing trusts them, they're just regular self-signed certificates. There is no benefit to using these over your own self-signed certificates except that you don't have to ask your LLM for the commands to generate them ;)

And of course once you trust them on localhost, you expose yourself to some risk, since the whole world can get a copy of the key.