See my response to the certificates thing here: https://news.ycombinator.com/item?id=45820782#45956556
I don’t think these are a fit for an entire HTTP/3 or HTTP/2 stack with WebTransport anyway.
WebSockets is fine for these applications and won’t be going away.
> See my response to the certificates thing here
If you don’t care about validating the certificate you can skip all of the renewals and DNS setup and everything else. The client will complain that it can’t verify the certificate against anything trusted and you tell the client that’s okay, just ignore it and continue.
If you don’t care about encryption then you also don’t care about setting up the certificate properly. You put something in there to enable the connection and then have the client ignore the fact that it’s not verified.
If your complaint is that browsers show warning signs for certs that can’t be validated and those might scare other users, that’s not going away.
It doesn't imply that websockets would be deprecated by WebTransport. It's a goal to make WebTransport an easy choice.
> Also, it's messed up that WT is only available in HTTPS. There are so many cool use cases for web technologies in local contexts where HTTPS is not a practical option
WebTransport is relatively heavy compared to websockets. Once you consider all of the layers, HTTP/3, possible HTTP/2 fallback, and transports, adding TLS is minimal overhead for code size.
For contexts where setting up certificates is not practical, I assume the workaround will be to generate a self-signed certificate and then tell the client to ignore certificate validation problems.