DataChannel vs WebTransport

[backkem]

We now have two APIs in the spec for transferring data: a DataChannel-based one (LP2PDataChannel) and a WebTransport-based one (LP2PQuicTransport). Both have advantages and disadvantages:

• LP2PDataChannel
  • easer to use for simple message passing use-cases, see Supporting different payload types (String, Blob, ArrayBuffer) #13
  • is familiar to WebRTC users
  • it has message size limitations, see Large message considerations #11
  • multiplexed over the existing OpenScreenProtocol connection (as currently specified)
• LP2PQuicTransport
  • can be deemed more modern
  • comes with all the power of WebTransport (steam based, see Large message considerations #11)
  • comes with the API complexity of WebTransport.
  • using a dedicated QUIC connection for lower overhead (as currently specified)

I wanted to open this issue to discuss:

• If we want to keep both options. While they both have precedent (WebRTC & WebTransport) having both likely has a higher cost.
• If keeping both: do we want to put forward one over the other in the spec?
• If keeping one: It may be possible to polyfill the DataChannel API over the WebTransport one. Maybe it's also possible to allow the option to choose between a multiplexed (over OSP) or dedicated (new QUIC conn) WebTransport.

[backkem]

Muxing the QuicTransport over OSP seems possible: implementation experiment.

[backkem]

We (@backkem, @wangw-1991 and @anssiko) had a short discussion on this which confirms the status-quo: the DataChannel API is more easy to grok; the WebTransport API is more modern & powerful.