It's not a formal feature of Matrix yet, so we should try and avoid people relying on it. This makes it appear as a private API and is very clearly labeled as not intended for use.
Do the lazy loading check in the batch of things we do before
starting a sync rather than at client start time, so we don't fail
to start the client if we can't hit the HS to determine LL support.
Fixes https://github.com/vector-im/riot-web/issues/7455
As you don't always have your own member with lazy loading
of members enabled, looking at the sync response section
where a room appears is the most reliable way of determining
the syncing user's membership in a room.
Before we already used this to read the
current room membership with `room.getMyMembership()`,
but we were still using the `RoomMember.membership` event
to detect when the syncing user's membership changed.
This event will help make those checks work well with LL enabled.
Have the keepalive promise return a boolean indicating whether it
detected a connectivity failure or not. Use this to only emit
CATCHUP if there was a connectivity error, to try & suppress
the state flip-flopping back & forth between CATCHUP and ERROR
in the case where we have connectivity but the sync is returning
and error for whatever reason.
This is according to the state diagram in client.js.
This will show a spinner at the bottom of a room again
while the catchup sync is in progress,
which seems to have broken at some point.
this will load members in case of LL and could take quite some time
The two async actions performed by onCryptoEvent is saving the crypto config
to the roomlist store and fetching the room members to track.
Both are guarded against double calls so not awaiting this should be fine.
to determine where a room should show up in the room list, we need to know
our membership type. But with lazy loading, we might not have our own member
if we weren't recently active in the room. Using getSyncedMembership can be
used to fallback if the users membership is not yet available.
When joining a room we were peeking into, we duplicated all the
state events into the timeline. Put back the old behaviour of just
setting them as state events, with copious commentary on how wrong
this seems.
Remove the call to /keys/changes when we do an incremental syn
where the old sync token doesn't match the one in the device list
store. To allow us to do this, always save the device list store
before saving the sync data, so we can safely assume the device
list store is at least as fresh as the sync token in the sync store.
Thread save functions through to allow this, add a delay parameter
so the sync can save the device list immediately and skip the wait,
and add a wantsSave() method so the sync can skip saving the device
list if the sync store isn't going to save anyway.
Fixes https://github.com/vector-im/riot-web/issues/6068
This should behave identically, but the code here appeared to be
identical to the code in initialiseState, so let's use it (it also
has an extra sanity check in there that we only init empty timelines).
so that we have push rules loaded into the client after doing
a cached sync (so that the client can assume that we do have
push rules, even if it was loaded from a cached sync).
These rules will be updated once `getPushRules` is completed
prior to the first networked sync.
* Allow a mode of operation without HS connection
Instead of blocking the first sync on getting the push rules and
filter, load sync data from disc.
When the client comes online, the push rules will be acquired and
a sync cycle started. This could be immediate if the client is
already online.
This could be a breaking change for clients that get push rules
before a successful sync has been done.
* Check whether we share an e2e room with user IDs in the 'left'
field of /keys/changes: there's no guarantee we no longer share
any e2e rooms with these users
* Reset everyone's tracking status on an initial sync - just
re-fetching device lists for all users we're currently tracking
isn't good enough since room memberships may have changed.
* Fix typo in test
* Message sending works again, but
* Marking multiple devices known (ie. 'send anyway') is very slow
because it writes all device info out each time
* Support for non-indexedb stores not written yet
* No migration
Travis Ralston