It's sad to see these kinds of posts from universities who were connected to the internet early on. (the blog is hosted on AS239)

This blog post itself served from HTTP/1.1 and IPv4 for me.

I guess the improving internet is handed over to the big companies who benefit them.

superkuh

I strongly disagree. HTTP/3 was a google's protocol and they and microsoft used their employees on the IETF to open-wash it. It is designed exclusively for the use cases of corporations and institutions to the detriment to the use cases of human persons. For example, you will not find any implementation of HTTP/3 that allows you to connect to another computer without that computer first getting continual approval from a third party corporation or institution. That is, you can't just connect to a friend's HTTP/3 web server, or your own HTTP/3 server on your LAN with any browser (or otherwise HTTP/3 client) out there. First you have to ask, say, LetsEncrypt for permission.

HTTP/3 is not for human people. It's for corporate people and it will serve them well. But please don't mistake not using HTTP/2 or HTTP/3 with their corporate crap as being backwards. It's the the other way around. I'll be sad when the web dies and all we're left with is Google's centrally controlled QUIC.

peterkelly

The problems you described are specific to implementations, not the protocol itself. I have read all of the QUIC specs in full (since I'm working on an implementation) and have seen nothing in any of them that mandates a centralised certificate infrastructure (caveat: I have not read the HTTP/3 spec, perhaps you could point out the relevant section if its in there). Of course, the most common use case requires this, but in that respect it's no different to HTTPS.

IPFS uses QUIC as one of its supported transport protocols, and this works in the most common implementation, Kubo [1]. The spec for the QUIC transport used in IPFS [2] indicates the same certificate trust policy as for the TLS protocol [3]. The latter, in turn, relies on peer-to-peer authentication with automatically-generated self-signed certificates containing a libp2p-specific additional extension.

IPFS is particularly well suited to the use case of personal websites you've mentioned, as it's specifically designed to operate without any form of centralisation.

[1] https://github.com/ipfs/kubo.

[2] https://github.com/libp2p/specs/tree/master/quic

[3] https://github.com/libp2p/specs/blob/master/tls/tls.md