Robin d3f069e763 Keep tiles in a stable order (#2670)
* Keep tiles in a stable order

This introduces a new layer of abstraction on top of MediaViewModel: TileViewModel, which gives us a place to store data relating to tiles rather than their media, and also generally makes it easier to reason about tiles as they move about the call layout. I have created a class called TileStore to keep track of these tiles.

This allows us to swap out the media shown on a tile as the spotlight speaker changes, and avoid moving tiles around unless they really need to jump between the visible/invisible regions of the layout.

* Don't throttle spotlight updates

Since we now assume that the spotlight and grid will be in sync (i.e. an active speaker in one will behave as an active speaker in the other), we don't want the spotlight to ever lag behind due to throttling. If this causes usability issues we should maybe look into making LiveKit's 'speaking' indicators less erratic first.

* Make layout shifts due to a change in speaker less surprising

Although we try now to avoid layout shifts due to the spotlight speaker changing wherever possible, a spotlight speaker coming from off screen can still trigger one. Let's shift the layout a bit more gracefully in this case.

* Improve the tile ordering tests

* Maximize the spotlight tile in portrait layout

* Tell tiles whether they're actually visible in a more timely manner

* Fix test

* Fix speaking indicators logic

* Improve readability of marbles

* Fix test case

---------

Co-authored-by: Hugh Nimmo-Smith <hughns@element.io>
2024-11-06 09:36:48 +00:00
2024-11-01 01:16:40 +00:00
2024-07-24 13:00:13 +02:00
2024-11-05 22:51:22 +00:00
2023-04-06 17:59:48 +01:00
2024-11-06 09:36:48 +00:00
2021-12-20 16:59:39 +00:00
2023-08-28 17:14:40 -04:00
2021-10-14 17:41:59 -07:00
2022-05-03 14:24:04 +01:00
2022-05-03 14:24:04 +01:00
2023-06-30 18:46:10 -04:00
2024-10-18 16:39:02 -04:00
2023-01-20 10:51:28 -05:00
2023-01-03 10:48:48 +00:00
2024-09-06 10:21:49 +02:00
2024-11-04 09:54:13 +00:00
2024-09-03 16:18:34 -04:00

Element Call

Chat Localazy

Group calls with WebRTC that leverage Matrix and an open-source WebRTC toolkit from LiveKit.

For prior version of the Element Call that relied solely on full-mesh logic, check full-mesh branch.

A demo of Element Call with six people

To try it out, visit our hosted version at call.element.io. You can also find the latest development version continuously deployed to call.element.dev.

Host it yourself

Until prebuilt tarballs are available, you'll need to build Element Call from source. First, clone and install the package:

git clone https://github.com/element-hq/element-call.git
cd element-call
yarn
yarn build

If all went well, you can now find the build output under dist as a series of static files. These can be hosted using any web server that can be configured with custom routes (see below).

You may also wish to add a configuration file (Element Call uses the domain it's hosted on as a Homeserver URL by default, but you can change this in the config file). This goes in public/config.json - you can use the sample as a starting point:

cp config/config.sample.json public/config.json
# edit public/config.json

Because Element Call uses client-side routing, your server must be able to route any requests to non-existing paths back to /index.html. For example, in Nginx you can achieve this with the try_files directive:

server {
    ...
    location / {
        ...
        try_files $uri /$uri /index.html;
    }
}

By default, the app expects you to have a Matrix homeserver (such as Synapse) installed locally and running on port 8008. If you wish to use a homeserver on a different URL or one that is hosted on a different server, you can add a config file as above, and include the homeserver URL that you'd like to use.

Element Call requires a homeserver with registration enabled without any 3pid or token requirements, if you want it to be used by unregistered users. Furthermore, it is not recommended to use it with an existing homeserver where user accounts have joined normal rooms, as it may not be able to handle those yet and it may behave unreliably.

Therefore, to use a self-hosted homeserver, this is recommended to be a new server where any user account created has not joined any normal rooms anywhere in the Matrix federated network. The homeserver used can be setup to disable federation, so as to prevent spam registrations (if you keep registrations open) and to ensure Element Call continues to work in case any user decides to log in to their Element Call account using the standard Element app and joins normal rooms that Element Call cannot handle.

Configuration

There are currently two different config files. .env holds variables that are used at build time, while public/config.json holds variables that are used at runtime. Documentation and default values for public/config.json can be found in ConfigOptions.ts.

If you're using Synapse, you'll need to additionally add the following to homeserver.yaml or Element Call won't work:

experimental_features:
    msc3266_enabled: true

MSC3266 allows to request a room summary of rooms you are not joined. The summary contains the room join rules. We need that to decide if the user gets prompted with the option to knock ("ask to join"), a cannot join error or the join view.

Element Call requires a Livekit SFU behind a Livekit jwt service to work. The url to the Livekit jwt service can either be configured in the config of Element Call (fallback/legacy configuration) or be configured by your homeserver via the .well-known. This is the recommended method.

The configuration is a list of Foci configs:

"org.matrix.msc4143.rtc_foci": [
    {
        "type": "livekit",
        "livekit_service_url": "https://someurl.com"
    },
     {
        "type": "livekit",
        "livekit_service_url": "https://livekit2.com"
    },
    {
        "type": "another_foci",
        "props_for_another_foci": "val"
    },
]

Translation

If you'd like to help translate Element Call, head over to Localazy. You're also encouraged to join the Element Translators space to discuss and coordinate translation efforts.

Development

Frontend

Element Call is built against matrix-js-sdk. To get started, clone, install, and link the package:

git clone https://github.com/matrix-org/matrix-js-sdk.git
cd matrix-js-sdk
yarn
yarn link

Next, we can set up this project:

git clone https://github.com/element-hq/element-call.git
cd element-call
yarn
yarn link matrix-js-sdk

You're now ready to launch the development server:

yarn dev

Backend

A docker compose file is provided to start a LiveKit server and auth service for development. These use a test 'secret' published in this repository, so this must be used only for local development and never be exposed to the public Internet.

To use it, add a SFU parameter in your local config ./public/config.json: (Be aware, that this is only the fallback Livekit SFU. If the homeserver advertises one in the client well-known, this will not be used.)

"livekit": {
  "livekit_service_url": "http://localhost:7881"
},

Run backend components:

yarn backend

Test Coverage

Add a new translation key

To add a new translation key you can do these steps:

  1. Add the new key entry to the code where the new key is used: t("some_new_key")
  2. Run yarn i18n to extract the new key and update the translation files. This will add a skeleton entry to the public/locales/en-GB/app.json file:
    {
        ...
        "some_new_key": "",
        ...
    }
    
  3. Update the skeleton entry in the public/locales/en-GB/app.json file with the English translation:
    {
        ...
        "some_new_key": "Some new key",
        ...
    }
    

Documentation

Usage and other technical details about the project can be found here:

Docs

Description
No description provided
Readme 43 MiB
Languages
TypeScript 88.6%
CSS 10.3%
JavaScript 0.9%