Doesn't WebTransport get you CA-less QUIC in browser? Via the server cert hashes thing? Like as long as it matches one of the hashes *you* provide then you're good?
Discussion
I didn't know that. I didn't consider WebTransport. I'm reading about it now.
I'm already both excited and bummed. A certificate hash isn't as good as a raw public key. With a raw public key I can a-priori know exactly what to expect before ever connecting. With a certificate hash I need to actually have the server certificate first which has a signature I could not predict a-priori. This can be worked around though. I really hate the baggage of certificates (X.509 is a nightmare of ancient crap). But the industry won't let it go.
i think many browsers do support HTTP/3 over QUIC and can do websockets with them, which means that you can support both if you add, probably, some header that requests HTTP/3 if its available if the client supports it and if the relay doesn't understand it, no problem, but if it does, it will upgrade to HTTP/3 web transport over QUICK
And the damn standard didn't bother to define clientCertificateHashes, only serverCertificateHashes.
You could in theory generate a self-signed cert once for a peer/server combo and cross fingers it never changes. Or at least is long-lived. The hash would then come from this cert and be distributed. Then tie the public key to that specific cert structure. Something like that? Dunno. Feels like there's room for jigging. Or use nostr for out-of-band, but that might get circular?
I am doing my own certicates. I am basically doing my own everything. 😛
Mostly because I want to be able to think about how things aught to work rather than how they do. I want my certs to map 1-1 with application scopes. Why? Because I don't want crappy applications anywhere near keys I didn't give them access to. Also you almost never want to use you master Identity key. Every time you unlock it is a chance for compromise. We can't expect grandmother to know good key hygiene
So WebTransport still fails us in a few ways:
* You still lose Tor support. Tor is TCP based.
* You can't connect to a server and verify it by it's public key, you have to have a hash of its certificate somehow
* Client-side certficates still use Web PKI, so can't be used for AUTH
* You layer on a lot of complexity (https://www.w3.org/TR/webtransport/ is not straightforward) with marginal benefits.
I agree with nostr:npub1w4jkwspqn9svwnlrw0nfg0u2yx4cj6yfmp53ya4xp7r24k7gly4qaq30zp about being "connection type agnostic". A message-based protocol can run over any transport, including bluetooth, or paper airplanes.
I think it's worth digging a little.
I'm not big on TOR at all, so if that's a game-changer then fair.
Tying a public key to a long-lived hash may be doable, though you'd need a refresh mechanism for when the browser forces. Again though worth digging.
For Web PKI I read chatter before on some kind of push for secondary authentication, who knows, all very new.
Complexity, no doubt.
But I will say that if the performance you get with iroh holds up then it might be worth every trade-off. For me, p2p with this kind of performance is just nuts. Never in my internet history.