3 ms·

I think WebTransport is cool. What worries me is that some people involved in standardisation seem to be of the opinion that WebTransport supersedes WebSocket.

by mort96 1y ago

I think WebTransport is cool. 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.

yladiz 1y ago
You should be able to use things like WebTransport locally, localhost is considered a secure context.
- mort96 1y ago
  192.168.0.x is not though
  - vscode-rest 1y ago
    port fwd through localhost?
    - mort96 1y ago
      You're missing the point. The useful thing is to run some service on the LAN, be it a web interface for a NAS, a web interface to control some lighting, a web interface into a media PC to do remote desktop type stuff or control media playback, a debug interface into some embedded product I'm working on, or a whole host of other things. The thing that makes web technologies useful for this is that it Just Works, from any other machine on the LAN (my laptop, my phone, a guest's phone, etc). By making technologies available only in a "secure context", they're blocking them out of this whole category of use cases.
      - jimvdv 1y ago
        You can get a free cert from letsencrypt using their dns challenge. No need to expose to the internet. Add a DNS record that points to the address of your LAN and it’ll make things even easier for your guests.
        mort96 1y ago
        Not interested in going through the effort of setting up a DNS record, go through the whole DNS challenge process, and go through a periodic manual renewal process, for every stupid little thing (many even just temporary things which don't even have a static DHCP lease). There's literally no advantage for my use case, except that I'd be allowed by the web standard bodies to use their shiny new toys that they artificially lock away otherwise. 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.
        sroussey 1y ago
        Self signed for 192.x would be one thing, self signed for gmail.com would be another.
        mort96 1y ago
        I would be perfectly happy with a solution where browsers show a scare screen for self-signed certificates on the public internet but a benign-looking "Do you want to trust this certificate?" screen for 192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12 or mDNS .local domains.
        fukka42 1y ago
        [dead]
      - 1y ago
  - addisonj 1y ago
    not disagreeing with your point here, or in the follow-ups of the pain of https for "local network" apps... but I really wish that we could get to a place where we could get away from this distinction. Obviously, ipv6 is not that easy or realistic, but that really is, imho, the "right" long term answer. 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
    - mort96 1y ago
      I work with embedded Linux stuff and MCU stuff where we make a significant number of units. Even in an IPv6 world, there's no way each of those would get their own public static IPv6 address with an associated DNS record just for the purpose of being able to spin up a debug web interface. It's explicitly desirable for these devices to not be reachable through the public Internet.
      - stavros 1y ago
        Well then you set your firewall to default-deny. It doesn't make sense to hobble the internet just because NATs are inadvertently a convenient firewall.
        mort96 1y ago
        And how do I assign the devices globally unique IP addresses? SLAAC is only for local addresses, right?
        stavros 1y ago
        Wouldn't IPv6 work for that?
        mort96 1y ago
        I don't know what you mean. I asked what process you would use to assign IPv6 addresses.
super256 1y ago
I just read the MDN article of WS and you are right: WT is indeed treated as the successor of WS (in many use cases), which I did not expect at all: 'Additionally, the WebTransport API is expected to replace the WebSocket API for many applications. WebTransport is a versatile, low-level API that provides backpressure and many other features not supported by either WebSocket or WebSocketStream, such as unidirectional streams, out-of-order delivery, and unreliable data transmission via datagrams.' https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_...
gr4vityWall 1y ago
Agreed. WebSocket works perfectly when someone wants a lightweight message-based protocol on top of TCP and doesn't want to implement it themselves, potentially in multiple languages. It being originally browser tech became a minor detail.
kixelated 1y ago
I like to frame WebTransport as multiple WebSocket connections to the same host, but using a shared handshake. 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.
- mort96 1y ago
  The thing is, I very rarely (or arguably never) have a use case which requires that one client has multiple connections to the same server. The thing I want is almost always to have a bidirectional stream of messages where messages arrive in order. Essentially a simple message envelope protocol on top of TCP.
  - kixelated 1y ago
    For sure, if you want an ordered/reliable stream then WebSocket is ideal. WebTransport is useful when you also want prioritization and semi-reliable networking, similar in concept to WebRTC data channels.
Aurornis 1y ago
Designed a protocol to supersede an old one is a good design goal. It makes encompassing all of the previous functionality and use cases a design priority. 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.
- layla5alive 1y ago
  There are material performance overheads to TLS
- mort96 1y ago
  Performance isn't really my main concern; I have some projects with configuration web GUIs running on MCUs where it could matter (especially the code size to include mbedtls), but most of the stuff I care about is on Linux machines which are powerful enough that it doesn't matter. See my response to the certificates thing here: https://news.ycombinator.com/item?id=45820782#45956556 https://news.ycombinator.com/item?id=45820782#45956556
  - Aurornis 1y ago
    > I have some projects with configuration web GUIs running on MCUs where it could matter 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.

by mort96 1y ago

yladiz 1y ago

You should be able to use things like WebTransport locally, localhost is considered a secure context.

mort96 1y ago
192.168.0.x is not though
- vscode-rest 1y ago
  port fwd through localhost?
  - mort96 1y ago
    You're missing the point. The useful thing is to run some service on the LAN, be it a web interface for a NAS, a web interface to control some lighting, a web interface into a media PC to do remote desktop type stuff or control media playback, a debug interface into some embedded product I'm working on, or a whole host of other things. The thing that makes web technologies useful for this is that it Just Works, from any other machine on the LAN (my laptop, my phone, a guest's phone, etc). By making technologies available only in a "secure context", they're blocking them out of this whole category of use cases.
    - jimvdv 1y ago
      You can get a free cert from letsencrypt using their dns challenge. No need to expose to the internet. Add a DNS record that points to the address of your LAN and it’ll make things even easier for your guests.
      - mort96 1y ago
        Not interested in going through the effort of setting up a DNS record, go through the whole DNS challenge process, and go through a periodic manual renewal process, for every stupid little thing (many even just temporary things which don't even have a static DHCP lease). There's literally no advantage for my use case, except that I'd be allowed by the web standard bodies to use their shiny new toys that they artificially lock away otherwise. 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.
        sroussey 1y ago
        Self signed for 192.x would be one thing, self signed for gmail.com would be another.
        mort96 1y ago
        I would be perfectly happy with a solution where browsers show a scare screen for self-signed certificates on the public internet but a benign-looking "Do you want to trust this certificate?" screen for 192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12 or mDNS .local domains.
      - fukka42 1y ago
        [dead]
    - 1y ago
- addisonj 1y ago
  not disagreeing with your point here, or in the follow-ups of the pain of https for "local network" apps... but I really wish that we could get to a place where we could get away from this distinction. Obviously, ipv6 is not that easy or realistic, but that really is, imho, the "right" long term answer. 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
  - mort96 1y ago
    I work with embedded Linux stuff and MCU stuff where we make a significant number of units. Even in an IPv6 world, there's no way each of those would get their own public static IPv6 address with an associated DNS record just for the purpose of being able to spin up a debug web interface. It's explicitly desirable for these devices to not be reachable through the public Internet.
    - stavros 1y ago
      Well then you set your firewall to default-deny. It doesn't make sense to hobble the internet just because NATs are inadvertently a convenient firewall.
      - mort96 1y ago
        And how do I assign the devices globally unique IP addresses? SLAAC is only for local addresses, right?
        stavros 1y ago
        Wouldn't IPv6 work for that?
        mort96 1y ago
        I don't know what you mean. I asked what process you would use to assign IPv6 addresses.

super256 1y ago

I just read the MDN article of WS and you are right: WT is indeed treated as the successor of WS (in many use cases), which I did not expect at all: 'Additionally, the WebTransport API is expected to replace the WebSocket API for many applications. WebTransport is a versatile, low-level API that provides backpressure and many other features not supported by either WebSocket or WebSocketStream, such as unidirectional streams, out-of-order delivery, and unreliable data transmission via datagrams.' https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_...

gr4vityWall 1y ago

Agreed. WebSocket works perfectly when someone wants a lightweight message-based protocol on top of TCP and doesn't want to implement it themselves, potentially in multiple languages. It being originally browser tech became a minor detail.

kixelated 1y ago

I like to frame WebTransport as multiple WebSocket connections to the same host, but using a shared handshake. 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.

mort96 1y ago
The thing is, I very rarely (or arguably never) have a use case which requires that one client has multiple connections to the same server. The thing I want is almost always to have a bidirectional stream of messages where messages arrive in order. Essentially a simple message envelope protocol on top of TCP.
- kixelated 1y ago
  For sure, if you want an ordered/reliable stream then WebSocket is ideal. WebTransport is useful when you also want prioritization and semi-reliable networking, similar in concept to WebRTC data channels.

Aurornis 1y ago

Designed a protocol to supersede an old one is a good design goal. It makes encompassing all of the previous functionality and use cases a design priority. 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.

layla5alive 1y ago
There are material performance overheads to TLS
mort96 1y ago
Performance isn't really my main concern; I have some projects with configuration web GUIs running on MCUs where it could matter (especially the code size to include mbedtls), but most of the stuff I care about is on Linux machines which are powerful enough that it doesn't matter. See my response to the certificates thing here: https://news.ycombinator.com/item?id=45820782#45956556 https://news.ycombinator.com/item?id=45820782#45956556
- Aurornis 1y ago
  > I have some projects with configuration web GUIs running on MCUs where it could matter 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.