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
- fix requestVerification in MatrixClient to match the function in crypto
- reorder the arguments so that the arguments actually do what they say they
do
- pass through the third argument, which was accidentally omitted
- ignore verification requests from ourselves
- also fix a comment
now that event can be replaced from Relations instead of Room
Also make `makeReplaced` non-destructive by not touching the original
event.content, so it can be undone by later calls.
This adds a read path for relations (gated behind an unstable option). A few
basic client-side grouping and sorting operations are supported. Consumers are
expected to ask the `EventTimelineSet` for a relation container when desired.
Fixes https://github.com/vector-im/riot-web/issues/9280
The server is unable to calculate encrypted highlights for us, so we calculate them. This also means the server always sends a zero for highlight_count, and therefore in sync.js we now trust our judgement over the server's. In future, this check will need to be altered to support server-side encrypted notifications if that happens. This fixes the part of 9280 where the badge count ends up disappearing unless the message received also happens to be a mention.
The changes in client.js are more to support rooms which are mentions only. Because the server doesn't send an unread_count for these rooms, the total notifications will always be zero. Therefore, we try and calculate that. In order to do that, we need to assume that our highlight count is also wrong and calculate it appropriately.
The code to migrate from the `sessionStore` to `cryptoStore` originally appeared
in https://github.com/matrix-org/matrix-js-sdk/pull/584 (2017-12-06). At this
point, it seems safe to assume most sessions that need migrating have already
done so. Removing this code simplifies store handling and removes the
`sessionStore` from most places in JS SDK.
