MSC4211: WebXDC on Matrix #4211
Conversation
It is most likely full of errors
You can tell I'm not good at this. Also signed off. Signed-off-by: lda <[email protected]>
:( Signed-off-by: lda <[email protected]>
tulir
added
proposal
There was a problem hiding this comment.
Implementation requirements:
- Client
There was a problem hiding this comment.
Personally, I'd like to see feedback from a web client regarding how difficult this would be to implement, including the required sandboxing.
| @@ -0,0 +1,156 @@ | |||
| # MSC4211: WebXDC on Matrix | |||
There was a problem hiding this comment.
Isnt WebXDC just a widget with less functionality or am I missing something? Not sure if we need a second widget api 🤔
There was a problem hiding this comment.
I've already mentionned this in the "Alternatives" section:
Widgets(MSC1236), while powerful, also suffer from a similar agnosticity problem with
other platforms, and has been noted as not having a "[...] canonical document to describe
[it]" last year. WebXDC also has stricter security concerns(e.g: clients cannot have
sensitive information leaked, unlike widgets), thus making it safer.
There was a problem hiding this comment.
I think the lack of a canonical document is a Matrix spec issue rather than a shortcoming of widgets themselves? IIUC, the main selling point of WebXDC appears to be that it doesn't require another server.
There was a problem hiding this comment.
I think the lack of a canonical document is a Matrix spec issue rather than a shortcoming of widgets themselves?
Seeing it like that, yeah, will correct that back
IIUC, the main selling point of WebXDC appears to be that it doesn't require another server.
It also is. WebXDC is mostly self-contained (and here, the only real requirement is that you can actually get a MXC URI of the actual WebXDC container)
There was a problem hiding this comment.
Its super cool to see someone looking into matrix+WebXDC. I have spend some time looking into it as well and liked the potential.
My appraoch during this investigation was to build a WebXDC container widget. It would load the WebXDC content and forward messages back and forth. It could also take care of putting everything into threads (this is the only way we can have proper back pagination with the widget api as of today) and abstract all this "bridging work" away from the client.
As mentioned before this would be sth each client would need to support.
proposals/4211-webxdc.md
Outdated
| Another way to have interactive content in rooms would be to use an integration manager. | ||
| However, these would require an additional server to be setup(which are not maintained), | ||
| and would effectively be limited to the Matrix ecosystem only, instead of being platform- | ||
| agnostic. | ||
| Widgets(MSC1236), while powerful, also suffer from a similar agnosticity problem with | ||
| other platforms, and has been noted as not having a "[...] canonical document to describe | ||
| [it]" last year. WebXDC also has stricter security concerns(e.g: clients cannot have | ||
| sensitive information leaked, unlike widgets), thus making it safer. |
There was a problem hiding this comment.
I would love to see a WebXDC widget container alternative section.
As described here: #4211 (comment)
also suffer from a similar agnosticity problem with
other platforms
Clients would then support WebXDC through the widget api (dont need to implement both and we have WebXDC for some cases as a valid option to reach larger audiences
would be to use an integration manager
The integration manager is not strictly required. It is possible to also add widgets as a client feature or manually.
additional server to be setup
this is still true even if the widget setup itself does not require an integration manager the widget needs to be hosted somewhere. A method to load the widget from a matrix media repository would be very interesting.
|
Cheers! Looking forward to see WebXDC in Matrix! |
| @@ -0,0 +1,162 @@ | |||
| # MSC4211: WebXDC on Matrix | |||
There was a problem hiding this comment.
- How does this interact with clients that do not, or can't include a web runtime?
- I'd been thinking about a similar MSC to be able to define how a given event type would be rendered. This would allow non-chat clients to interoperate with chat clients more clearly, by being able to specify that eg. a bug tracker can have it's events be rendered as "User opened new issue xyz".
Rendered