MSC3009: Websocket transport for client <--> widget communications #3009
Conversation
turt2live
added
proposal-in-review
proposal
| Regular HTTP might also work, as would Server-Sent Events, though these are inherently one-way or require | ||
| excessive resources to make two-way. Other efficient transports are not easily available on all platforms, | ||
| such as lower level TCP/UDP-based transports. |
There was a problem hiding this comment.
fair warning that other comments of this sort will be written off as malicious bikeshed - please include details of why the suggestion is better to avoid this designation
What are the benefits over websockets? Can web-based implementations more easily spin that up for bidirectional communications?
There was a problem hiding this comment.
QUIC has the benefit of including both TLS and framed multi-streaming in one protocol. Shedding UDP means we can also get rid of 8 bytes of redundant header (ports and payload size), that QUIC already communicates (connection ID and per-stream payload size). You would keep an even number of streams to establish a bidirectional connection in QUIC over IP. WebSockets, unlike QUIC, requires a long sequence of connection bootstrapping (2+RTT vs 1RTT for QUIC).
There was a problem hiding this comment.
How implementable is this for, say, element.io? Could element.io or any other web-based client easily create a QUIC communication channel?
I think this is more about availability than speed, as i interpret the primary objective of the MSC to have an easy-to-setup bidirectional channel for widgets. QUIC wouldn't pass under these requirements (unless i'm mistaken, and QUIC has gained prominent compatibility with application-facing APIs).
| over this alternative transport, for example. Similarly, there is nothing to pin to the screen and therefore | ||
| the widget's attempts to request an "always on screen" capability would be for naught. | ||
|
|
||
| ## Alternatives |
There was a problem hiding this comment.
we might also be able to make the homeserver a bouncer by having a "client ID" of sorts to give the widget and homeserver, which opens a communication channel between the widget and client regardless of platforms.
| There is a high likelihood that when a client spins up a websocket server that it'll be bound to localhost | ||
| without TLS. This could be problematic if widgets are transferring sensitive information over the API | ||
| which could be intercepted by local processes. This is akin to a malicious browser extension listening for | ||
| postmessage requests on `*`, however. |
There was a problem hiding this comment.
As far as i understand this opens an additional unauthenticated lisening port in the matrix client. So anything (including open web pages) might be able to connect to the matrix client and try to confuse it to break or do something unauthorized.
I think it would be better if the communication can be ensured to actually be from the widget. Passing a random string to the widget somehow that it needs to present in the first message on the websocket should mitigate such problems.
turt2live
added
the
needs-implementation
| @@ -0,0 +1,110 @@ | |||
| # MSC3009: Websocket transport for client <--> widget communications | |||
There was a problem hiding this comment.
none of this makes sense when we have to-device: https://github.com/matrix-org/matrix-doc/issues/3347
Rendered
Author's note: This is technically in review under the "we probably want alternative transports" flag, though websockets being the solution is questionable - see MSC for details.