5 ms·

Is there any alternative we could use? WebRTC is not it - that's much more complex than just simple client-server communication. Also, HTTP 3 is standardized -

Is there any alternative we could use? WebRTC is not it - that's much more complex than just simple client-server communication. Also, HTTP 3 is standardized - isn't it weird that we can't actually use it from a browser?

aaaaaaaaaaab 4y ago
HTTP 3? Oh, you mean the thing that used to be HTTP-over-QUIC, another “standard” unilaterally declared by Google :-)
- superkuh 4y ago
  I'm with ya, but it wasn't just google. Google easily convinced the other megacorps like Microsoft that QUIC was good for their use cases and together they managed to whitewash it through the IETF. It wasn't just google. But it is just mega-corps. QUIC is a bad standard for human persons but excellent for corporate persons. As for webtransport, this is the first time I'm hearing of it. My browsers definitely don't support it.
  - kmeisthax 4y ago
    >QUIC is a bad standard for human persons but excellent for corporate persons. ...er, why? It keeps packet loss from slowing down site loading (as much as is possible). I'm not sure how this is "bad for human persons".
    - jrockway 4y ago
      I think that most of the objection is that with HTTP/1.1 you can type "telnet example.com 80" and type out an HTTP request and read the reply. I see similar arguments about why JSON is better than protocol buffers. All the necessary keys are on your keyboard. At the end of the day, I just write a tool to do these binary-exchanges for me. If I need to send a protocol buffer message to some server, I just write a program to do that. It's 3 lines of code. If I do it a lot, I check it in and write documentation. There are plenty of reusable generic mechanisms that already exist, too. curl for all of your HTTP request needs. OpenAPI to make an app that talks to your custom API. People tend to draw the line exactly at their current level of understanding. A few years ago, people would say "SSL is only for corporations", but with Let's Encrypt, you don't see that come up anymore. They're comfortable not having keys on their keyboard that can do the TLS handshake, because they now understand the server-side and client-side tooling, and the obscurity of a binary protocol they can't type out is no longer an impediment to productivity. Soon, they'll be comfortable with HTTP/3 as well.
    - superkuh 4y ago
      You can't use QUIC without CA based TLS. There do not exist CAs run by human persons that have root certs in popular browers. They are all run by incorporated entities. It is bad that a human person trying to connect to another human person cannot do so without the continuing approval of a third party corporate person. For companies and institutions this requirement makes perfect sense. It's a great protocol for doing business. But for human people it introduces yet another layer of centralizing complexity for legal and social pressures to be applied and abuses to be enforced. It also makes setting up a webserver even more complex forcing more centralization in hosting. And not that anyone cares, but you can't legally use QUIC over amateur radio like you can HTTP or even HTTPS with a null cypher self signed cert.
      - WHATDOESIT 4y ago
        Let's Encrypt doesn't work with HTTP 3 or what do you mean? Human persons need strong encryption much more than legal persons. Legal persons can't die/have their health damaged/be thrown in prison/be lynched by a mob. This is a way to make it available to everyone. It's not hard to setup your CA and add a profile with it if you just want to communicate with other human persons and it must be HTTP 3. Of course browsers don't include random humans' CAs... I am happy about that. And why don't you just use HTTP 1/2 over amateur radio? That your 0.0000001% usecase (don't tell me you yourself do it more often) isn't supported doesn't mean the whole thing is bad.
- seabrookmx 4y ago
  gQUIC != QUIC, though it definitely inspired it (the same way SPDY inspired HTTP/2). QUIC went through the IETF and HTTP/3 is supported in all modern browsers now. It also has a lot of technical advantages over previous versions. Google doesn't always do the right thing but I haven't heard a solid argument over why their contributions to QUIC and HTTP/3 are bad.
- intelVISA 4y ago
  I just want QUIC over QUIC (QUICly) but I don't have the same lobby power over the IETF sadly.
CharlesW 4y ago
> Also, HTTP 3 is standardized - isn't it weird that we can't actually use it from a browser? According to https://caniuse.com/http3 https://caniuse.com/http3, HTTP/3 is live now in both Chrome and Firefox, and is available behind "Experimental Features" in Safari.
- WHATDOESIT 4y ago
  Yeah, the browser can download a page via HTTP 3 - sure. My point is, I want to be able to use the full capabilities at my discretion from my JS code, not just a "dumb" fetch(...). HTTP 3 can do more than just offer webpages for download. And WebTransport is exactly that.
saurik 4y ago
WebRTC is more complex than "simple client-server communication", but is it really more complicated than QUIC? It is literally just SCTP over DTLS with only a SMALL bit of ICE (I think almost none when using ice-lite) for the equivalent use case...
- deleted 4y ago
  [deleted]

aaaaaaaaaaab 4y ago

HTTP 3? Oh, you mean the thing that used to be HTTP-over-QUIC, another “standard” unilaterally declared by Google :-)

superkuh 4y ago
I'm with ya, but it wasn't just google. Google easily convinced the other megacorps like Microsoft that QUIC was good for their use cases and together they managed to whitewash it through the IETF. It wasn't just google. But it is just mega-corps. QUIC is a bad standard for human persons but excellent for corporate persons. As for webtransport, this is the first time I'm hearing of it. My browsers definitely don't support it.
- kmeisthax 4y ago
  >QUIC is a bad standard for human persons but excellent for corporate persons. ...er, why? It keeps packet loss from slowing down site loading (as much as is possible). I'm not sure how this is "bad for human persons".
  - jrockway 4y ago
    I think that most of the objection is that with HTTP/1.1 you can type "telnet example.com 80" and type out an HTTP request and read the reply. I see similar arguments about why JSON is better than protocol buffers. All the necessary keys are on your keyboard. At the end of the day, I just write a tool to do these binary-exchanges for me. If I need to send a protocol buffer message to some server, I just write a program to do that. It's 3 lines of code. If I do it a lot, I check it in and write documentation. There are plenty of reusable generic mechanisms that already exist, too. curl for all of your HTTP request needs. OpenAPI to make an app that talks to your custom API. People tend to draw the line exactly at their current level of understanding. A few years ago, people would say "SSL is only for corporations", but with Let's Encrypt, you don't see that come up anymore. They're comfortable not having keys on their keyboard that can do the TLS handshake, because they now understand the server-side and client-side tooling, and the obscurity of a binary protocol they can't type out is no longer an impediment to productivity. Soon, they'll be comfortable with HTTP/3 as well.
  - superkuh 4y ago
    You can't use QUIC without CA based TLS. There do not exist CAs run by human persons that have root certs in popular browers. They are all run by incorporated entities. It is bad that a human person trying to connect to another human person cannot do so without the continuing approval of a third party corporate person. For companies and institutions this requirement makes perfect sense. It's a great protocol for doing business. But for human people it introduces yet another layer of centralizing complexity for legal and social pressures to be applied and abuses to be enforced. It also makes setting up a webserver even more complex forcing more centralization in hosting. And not that anyone cares, but you can't legally use QUIC over amateur radio like you can HTTP or even HTTPS with a null cypher self signed cert.
    - WHATDOESIT 4y ago
      Let's Encrypt doesn't work with HTTP 3 or what do you mean? Human persons need strong encryption much more than legal persons. Legal persons can't die/have their health damaged/be thrown in prison/be lynched by a mob. This is a way to make it available to everyone. It's not hard to setup your CA and add a profile with it if you just want to communicate with other human persons and it must be HTTP 3. Of course browsers don't include random humans' CAs... I am happy about that. And why don't you just use HTTP 1/2 over amateur radio? That your 0.0000001% usecase (don't tell me you yourself do it more often) isn't supported doesn't mean the whole thing is bad.
seabrookmx 4y ago
gQUIC != QUIC, though it definitely inspired it (the same way SPDY inspired HTTP/2). QUIC went through the IETF and HTTP/3 is supported in all modern browsers now. It also has a lot of technical advantages over previous versions. Google doesn't always do the right thing but I haven't heard a solid argument over why their contributions to QUIC and HTTP/3 are bad.
intelVISA 4y ago
I just want QUIC over QUIC (QUICly) but I don't have the same lobby power over the IETF sadly.

CharlesW 4y ago

> Also, HTTP 3 is standardized - isn't it weird that we can't actually use it from a browser? According to https://caniuse.com/http3 https://caniuse.com/http3, HTTP/3 is live now in both Chrome and Firefox, and is available behind "Experimental Features" in Safari.

WHATDOESIT 4y ago
Yeah, the browser can download a page via HTTP 3 - sure. My point is, I want to be able to use the full capabilities at my discretion from my JS code, not just a "dumb" fetch(...). HTTP 3 can do more than just offer webpages for download. And WebTransport is exactly that.

saurik 4y ago

WebRTC is more complex than "simple client-server communication", but is it really more complicated than QUIC? It is literally just SCTP over DTLS with only a SMALL bit of ICE (I think almost none when using ice-lite) for the equivalent use case...

deleted 4y ago
[deleted]