[WIP] Theoretical concept of a "thin widget wrapper" for popout-style widgets

[turt2live]

TODO:

• Fix runtime errors
• Actually load the correct widget from the correct room/account data
• Actually render the thing in a giant window

Ideas:

• Stub out the MatrixClientPeg to use memory/localstorage
• Stub out the Room as much as possible

---

Requires matrix-org/matrix-react-sdk#5645

---

Concept context:

We're looking to possibly have a thin wrapper in Matrix where desktop or other non-web clients can point users at to render the widget. The idea works best with scoped access tokens (a scifi concept at the moment), and having those tokens expire automatically. The general theory is that a user on IRC, some non-web desktop client, etc can click a link to the widget and have their account information magically transferred to a browser tab (through that scoped token).

We'd also want to keep the sync loop as light as possible (maybe only starting it if the widget requests to receive events), so we'd be hitting individual endpoints to pull out state from the room/account data. Anonymous access would be interesting (for the IRC user case).

Overall this is meant to replace the "popout" button URL on widgets so they actually work and don't fail 99.8% of the time. If that experiment goes well, we'll likely extract this out of Element and shove it into the Matrix space to help make widgets accessible to the non-web clients of the ecosystem.

[toger5]

How does the widget in this scenario communicate with the client? Or are the tokens used to communicate with a matrix server directly? Or is the widget running in a new client that is just strapped down to only have the widget in it. So from a matrix server point of view it is just a new client connected to the matrix account. (I am thinking about widgets that interact with room timelines/ post and read messages)

[turt2live]

There's 4 major approaches, none of which have been finalized:

1. This lives on a domain where someone already has a logged-in client (eg: app.element.io/wrapper). The wrapper then inherits credentials.
2. This lives on its own domain and re-uses the login logic from Element to get a valid session set up. The wrapper uses those credentials.
3. Some transport gets introduced where the widget can talk back to the client (to-device messages, custom transport, etc).
4. Scoped access tokens.

In all the cases, the wrapper is the client that the widget interacts with.

[andybalaam]

@turt2live are you still working on this?

[turt2live]

This PR and it's partner would be under the VoIP team these days, not me.

[toger5]

@andybalaam What is the background of reaching out about this PR?
This is nothing that is immediately required by any of our efforts. We might revisit it however for a fallback option to support matrix calls on clients not having it implemented (legacy el mobile for example). (It is just one of the idea however and als not really discussed yet.)

[andybalaam]

@andybalaam What is the background of reaching out about this PR?

We (the Element Web team) have an ongoing goal to reduce the number of unmerged PRs. This was raised as one that looks abandoned, so we were hoping to close it. Closing it won't cause it to be deleted, but just removes it from the list of things we consider in progress right now.

[andybalaam]

This PR and it's partner would be under the VoIP team these days, not me.

OK, so this looks abandoned. If anyone wants to revive it, go ahead here or as another PR. Thanks!

[toger5]

This is a good solution. As Andy said it would be good to not delete the branch for now since this could become a valuable reference