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.

Reply to this note

Please Login to reply.

Discussion

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