What worries me is that some people involved in standardisation seem to be of the opinion that WebTransport supersedes WebSocket. WS has become my go-to transport when I just need to be able to reliably send messages back and forth, whether or not the web is involved at all, and I don't see WebTransport as a replacement for that use case. I hope WS sticks around forever.
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, it's a shame most new technologies are arbitrarily banned from those use cases.
By making technologies available only in a "secure context", they're blocking them out of this whole category of use cases.
For the permanent installation case, it's typically easier to use mDNS domains since they're shorter. 'mediapc.local' is easier for guests to type than 'mediapc.local.mort.coffee' or whatever I'd end up with.
What would be a good solution is self-signed certificates, but that too is a non-option until all browser vendors downgrade the warning from a "Someone is trying to hack you!" style scare screen to a more informative "this is a self signed certificate, do you trust it?" style warning screen.
Gee thanks corporate overlords, whatever would we do without your cloying efforts to provide quote-unquote-"security"?
Having gone down the path of being able to just spin up "local" services that get a publicly routable (but most often firewalled off) ipv6 IPs and then good DNS integration is really neat... but still requires lots of technical chops. I wish that weren't the case
If you're suggesting getting using a non-unique DHCP-assigned local IP address, I don't understand what difference you think v6 does compared to v4.
For many of these systems, I don't control the user's router. I don't know how you imagine I'm supposed to create DNS records for each device when they're assigned some random IP address at some random network I don't control.
That quite naturally flows into the question: okay, how are these devices supposed to get global IPv6 addresses then?
https://thisbridgeistheroot.com/blog/dhcpv6-prefix-delegatio...
I still don't understand how this is supposed to help.
This helps because you don't have a NAT distinguishing between "local" and "global", all devices are in the global namespace.
All the comments after that have been about solving an arbitrary and ill-defined problem with goalposts that keep shifting from globally unique addresses to DNS hostnames to permanent addresses.
I assumed that the suggestion was that you could assign a device a permanent IPv6 address, because I can easily imagine that as a part of a solution to the HTTPS issue. When every device has a permanent IPv6 address, and if every device is reachable through said IPv6 address, you could, in principle, also automate assigning each device a DNS record and set up SSL that way. It would be a pretty terrible solution that's way more complicated than just using a local address over HTTP, but it makes sense.
I have no idea how to even begin translating maybe getting temporary unique addresses through DHCPv6 into a solution to the HTTPS issue.
Then again, you don't need a static address to get a TLS certificate. You don't need an address at all! All you need is a domain name.
How does your proposed suggestion of getting a static prefix from an ISP apply to those situations? Should I start calling customers to get them to ask their ISP for a static IP address?
> Then again, you don't need a static address to get a TLS certificate. You don't need an address at all! All you need is a domain name.
I don't understand what you think this solves.
https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_...
It's common to multiplex a WebSocket connection but you don't need that with WebTransport, while also avoiding head-of-line-blocking.
But yeah I wish WebTransport had a better TCP fallback. I still use WebSocket for that.
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.
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.
As of one month ago, Java still didn't have HTTP/3 support. Though it's apparently coming in March (with JDK 26).
But yeah the HTTP/3 integration definitely makes WebTransport harder to support. The QUIC connection needs to be shared between HTTP/3 and WebTransport.
Since libwebrtc is all in C++ and 'trusted' it can do stuff like faststart or have error correction/bandwidth estimation that is codec aware.
WebTransport in Chrome currently uses CUBIC but the Google folks want to turn on BBR everywhere. It uses the same QUIC implementation as HTTP/3 so it's going to be more battle hardened.
I've implemented SCTP before to hack in "datagram" support by spamming FORWARD-TSN. Fun fact: you can't use FORWARD-TSN if there's still reliable data outstanding. TSN is sequential after all, you have to drop all or nothing.
QUIC as a protocol is significantly better than SCTP. I really recommend the RFC
Also, what client libraries are there for Python, Rust etc. for WebTransport? Does it work with any HTTP/3/QUIC implementation?
EDIT: Think also about webgl1/2, webgpu, webxr, websocket, webrtc, webauthn ...
WebRTC supports peer-to-peer UDP connections as well. Thus it's better for use cases like low-latency games, video calling, and secure direct communication between devices.
A better push might be to make WebRTC more simple and modern, but I'm not sure if any standards committees are working on this yet.
* RTP over QUIC is promising https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-over...
Do you want a new PeerConnection API? Are you annoyed with the Offer/Answer model? Do you have beef with the protocols. The possibility are endless :)
WebRTC should be the universal networking primitive for the next phase of the web, but the API exposes too many implementation details – its abstractions leak.
This plus the overall weight of integrations limit mass adoption by developers.
Doesn't it require DTLS over UDP though?
It will help a ton with the low latency streaming we need to do in our eBPF based Linux performance tool. (https://yeet.cx)
Plus Safari is often the last browser to get certain features anyway.
ktpsns•2mo ago
silverwind•2mo ago
kaoD•2mo ago
Messing with firewalls in what way?
baggy_trough•2mo ago
CharlesW•2mo ago
chrismorgan•2mo ago
It’s like saying “I had a violin, why didn’t they make this new ‘orchestra’ thing behave the same way?”
If you’re willing to limit yourself to a single reliable bidirectional stream, abstracting over both WebTransport and WebSocket will be easy.
WebTransport, in its fullness, also pretty clearly depends on HTTP/3. Any implementation based on HTTP/1 or HTTP/2 (which is in progress) will lack unreliable delivery and independence of streams (due to using TCP), and possibly more features.
advisedwang•2mo ago
KPGv2•2mo ago
You can think about this with HTTP/1 vs HTTP/3: HTTP/3 isn't an extension of HTTP/1. It's radically different.