This removes the IS details (server and access token) from `requestToken` calls
to the HS, as long as the HS supports the new separate add and bind mode. In
this mode, all of the 3PID validation is handled by the HS, so the IS details
are not used.
Fixes https://github.com/vector-im/riot-web/issues/10933
This adds a way to test for MSC2290 support on the homeserver with separate add
and bind functions. It checks the unstable feature flag as well as the upcoming
r0.6.0 spec version.
Part of https://github.com/vector-im/riot-web/issues/10839
To avoid the same problem that happened with lazy-loading (see https://github.com/matrix-org/synapse/issues/5528).
Note that as of writing r0.6.0 is not yet released, however it is the next scheduled release of the client-server API.
This passes along the `id_access_token` to the HS, which it will need when
speaking v2 IS APIs to the IS.
Unfortunately, some HSes seem to explode when given this new parameter, so we
only pass it along for the moment if an unstable feature `m.id_access_token` is
also set.
Part of https://github.com/vector-im/riot-web/issues/10525
Defined in MSC2140
This changes the ICE server fallback to be disabled by default. The SDK consumer
will receive a new event in case the homeserver has no ICE servers of its own,
and can prompt the user to agree to the fallback if desired.
Part of https://github.com/vector-im/riot-web/issues/10173
For https://github.com/vector-im/riot-web/issues/10263
Starting/scheduling the backup won't help us because the token would be invalid from a server perspective. Instead, we should update what needs to be done and return a count.
event.getPushRules() may return null (for better or worse...).
Use client.getPushRulesForEvent which will calculate them if they
haven't already been calculated.
Fixes https://github.com/vector-im/riot-web/issues/10269
Note: The `call` argument previously defined in the SDK was never actually populated, and appears to be a documentation error when the definition was copied from `Call.incoming` directly above it.
Fixes https://github.com/vector-im/riot-web/issues/9421
This also adds a context to the ReEmitter so we have access to the Room at the time of read receipt. Without this, we have to bind handlers to every encrypted room (which is tedious to maintain) or figure out which room `$something` belong to (CPU intensive).
For reactions, there is a very little gained by encrypting the entire event, as
relation data is already kept in the clear. Event encryption for a reaction
effectively only obscures the event type, but the purpose is still obvious from
the relation data, so nothing is really gained. It also causes quite a few
problems, such as:
* triggers notifications via default push rules
* prevents server-side bundling for reactions
The reaction key / content / emoji value does warrant encrypting, but this will
be handled separately by encrypting just this value.
See https://github.com/matrix-org/matrix-doc/pull/1849#pullrequestreview-248763642
Fixes https://github.com/vector-im/riot-web/issues/10130
