Does a thirdparty protocol lookup to the homeserver to get the
corresponding native/virtual user for a matrix ID. Stores the
mappings in room account data. Involves some slightly nasty workarounds
for that fact that room account data has no local echo.
Currently just by adding /holdcall and /unholdcall slash commands
The only place the hold status of the call is currently represented
is when the call is a voice call and you're viewing a different room:
it's not wired up when you're viewing the room because that currently
uses the room status bar which it won't do with the new UI.
Also convert VideoFeed to typescript, and remove videoview because
it essentially just managed the fullscreen functionality, but we'll
want and 'on hold' representation (and probably chrome for hagnup etc)
in the fullscreen UI too, so let's just make CallView the thing that
gets fullscreened.
and remove the old conference call stuff while we're at it: enough
time should have passed since those mistakes that we can move on.
The old conference call rooms will still appear for anyone whose
account dates back to that time, but they've presumably been appearing
in any other matrix client they used too.
If the Secure Backup required mode is set the client `.well-known` file, then
this will ensure that everyone already inside the app is required to complete
setup matching that policy.
Fixes https://github.com/vector-im/element-web/issues/14954
We use `RoomListStore` as a singleton, and don't want the ugly `2` at the end of the actual store instance, so here we rename it to something half-decent.
Either shows an informational dialog telling you the name has changed,
or a more naggy one if the user needs to log in on a different URL.
The new URL (if any) is hardcoded based on the current URL, and also
with a bonus config param in case other deployments need to do similar.
For https://github.com/vector-im/riot-web/issues/14035
**This option is not recommended as it completely obliterates all chances of being able to support someone with a broken room list. It is intended for specific testing scenarios only.**
This is more general maintenance than performance as the RoomList doesn't need to be generating layouts for the sublists, and it certainly doesn't need to be creating a bunch of extra ones.
The sublists are perfectly capable of getting their own layout instance and using it, and we are perfectly able to limit the number of these things we create through the session's lifespan.
