|
| 1 | +# Jitsi wrapper developer docs |
| 2 | + |
| 3 | +*If you're looking for information on how to set up Jitsi in your Riot, see |
| 4 | +[jitsi.md](./jitsi.md) instead.* |
| 5 | + |
| 6 | +These docs are for developers wondering how the different conference buttons work |
| 7 | +within Riot. If you're not a developer, you're probably looking for [jitsi.md](./jitsi.md). |
| 8 | + |
| 9 | +## Brief introduction to widgets |
| 10 | + |
| 11 | +Widgets are embedded web applications in a room, controlled through state events, and |
| 12 | +have a `url` property. They are largely specified by [MSC1236](https://github.com/matrix-org/matrix-doc/issues/1236) |
| 13 | +and have extensions proposed under [MSC1286](https://github.com/matrix-org/matrix-doc/issues/1286). |
| 14 | + |
| 15 | +The `url` is typically something we shove into an iframe with sandboxing (see `AppTile` |
| 16 | +in the react-sdk), though for some widgets special integration can be done. v2 widgets |
| 17 | +have a `data` object which helps achieve that special integration, though v1 widgets |
| 18 | +are best iframed and left alone. |
| 19 | + |
| 20 | +Widgets have a `postMessage` API they can use to interact with Riot, which also allows |
| 21 | +Riot to interact with them. Typically this is most used by the sticker picker (an |
| 22 | +account-level widget), though widgets like the Jitsi widget will request permissions to |
| 23 | +get 'stuck' into the room list during a conference. |
| 24 | + |
| 25 | +Widgets can be added with the `/addwidget <url>` command. |
| 26 | + |
| 27 | +## Brief introduction to integration managers |
| 28 | + |
| 29 | +Integration managers (like Scalar and Dimension) are accessible via the 4 squares in |
| 30 | +the top right of the room and provide a simple UI over top of bridges, bots, and other |
| 31 | +stuff to plug into a room. They are a separate service to Riot and are thus iframed |
| 32 | +in a dialog as well. They also have a `postMessage` API they can use to interact with |
| 33 | +the client to create things like widgets, give permissions to bridges, and generally |
| 34 | +set everything up for the integration the user is working with. |
| 35 | + |
| 36 | +Integration managers do not currently have a spec associated with them, though efforts |
| 37 | +are underway in [MSC1286](https://github.com/matrix-org/matrix-doc/issues/1286). |
| 38 | + |
| 39 | +## Widgets configured by integration managers |
| 40 | + |
| 41 | +Integration managers will often "wrap" a widget by using a widget `url` which points |
| 42 | +to the integration manager instead of to where the user requested the widget be. For |
| 43 | +example, a custom widget added in an integration manager for https://matrix.org will |
| 44 | +end up creating a widget with a URL like `https://integrations.example.org?widgetUrl=https%3A%2F%2Fmatrix.org`. |
| 45 | + |
| 46 | +The integration manager's wrapper will typically have another iframe to isolate the |
| 47 | +widget from the client by yet another layer. The wrapper often provides other functionality |
| 48 | +which might not be available on the embedded site, such as a fullscreen button or the |
| 49 | +communication layer with the client (all widgets *should* be talking to the client |
| 50 | +over `postMessage`, even if they aren't going to be using the widget APIs). |
| 51 | + |
| 52 | +Widgets added with the `/addwidget` command will *not* be wrapped as they are not going |
| 53 | +through an integration manager. The widgets themselves *should* also work outside of |
| 54 | +Riot. Widgets currently have a "pop out" button which opens them in a new tab and |
| 55 | +therefore have no connection back to Riot. |
| 56 | + |
| 57 | +## Jitsi widgets from integration managers |
| 58 | + |
| 59 | +Integration managers will create an entire widget event and send it over `postMessage` |
| 60 | +for the client to add to the room. This means that the integration manager gets to |
| 61 | +decide the conference domain, conference name, and other aspects of the widget. As |
| 62 | +a result, users can end up with a Jitsi widget that does not use the same conference |
| 63 | +server they specified in their config.json - this is expected. |
| 64 | + |
| 65 | +Some integration managers allow the user to change the conference name while others |
| 66 | +will generate one for the user. |
| 67 | + |
| 68 | +## Jitsi widgets generated by Riot itself |
| 69 | + |
| 70 | +When the user clicks on the call buttons by the composer, the integration manager is |
| 71 | +not involved in the slightest. Instead, Riot itself generates a widget event, this time |
| 72 | +using the config.json parameters, and publishes that to the room. If there's only two |
| 73 | +people in the room, a plain WebRTC call is made instead of using a widget at all - these |
| 74 | +are defined in the Matrix specification. |
| 75 | + |
| 76 | +The Jitsi widget created by Riot uses a local `jitsi.html` wrapper (or one hosted by |
| 77 | +`https://riot.im/app` for desktop users or those on non-https domains) as the widget |
| 78 | +`url`. The wrapper has some basic functionality for talking to Riot to ensure the |
| 79 | +required `postMessage` calls are fulfilled. |
| 80 | + |
| 81 | +**Note**: Per [jitsi.md](./jitsi.md) the `preferredDomain` can also come from the server's |
| 82 | +client .well-known data. |
| 83 | + |
| 84 | +## The Jitsi wrapper in Riot |
| 85 | + |
| 86 | +Whenever Riot sees a Jitsi widget, it ditches the `url` and instead replaces it with |
| 87 | +its local wrapper, much like what it would do when creating a widget. However, instead |
| 88 | +of using one from riot.im/app, it will use one local to the client instead. |
| 89 | + |
| 90 | +The wrapper is used to provide a consistent experience to users, as well as being faster |
| 91 | +and less risky to load. The local wrapper URL is populated with the conference information |
| 92 | +from the original widget (which could be a v1 or v2 widget) so the user joins the right |
| 93 | +call. |
| 94 | + |
| 95 | +Critically, when the widget URL is reconstructed it does *not* take into account the |
| 96 | +config.json's `preferredDomain` for Jitsi. If it did this, users would end up on different |
| 97 | +conference servers and therefore different calls entirely. |
| 98 | + |
| 99 | +**Note**: Per [jitsi.md](./jitsi.md) the `preferredDomain` can also come from the server's |
| 100 | +client .well-known data. |
0 commit comments