Make the following return Promises:
* `MatrixClient.getStoredDevicesForUser`
* `MatrixClient.getStoredDevice`
* `MatrixClient.setDeviceVerified`
* `MatrixClient.setDeviceBlocked`
* `MatrixClient.setDeviceKnown`
* `MatrixClient.getEventSenderDeviceInfo`
* `MatrixClient.isEventSenderVerified`
* `MatrixClient.importRoomKeys`
Remove `listDeviceKeys` altogether: it's been deprecated for ages, and since
applications are going to have to be changed anyway, they might as well use its
replacement (`getStoredDevices`).
initialising the crypto layer needs to become asynchronous. Rather than making
`sdk.createClient` asynchronous, which would break every single app in the
world, add `initCrypto`, which will only break those attempting to do e2e (and
in a way which will fall back to only supporting unencrypted events).
(as well as a similar bug in the test suite)
Turns out that `q.all(a, b)` === `q.all([a])`, rather than `q.all([a,b])`: it
only waits for the *first* promise - which means that `client.setGuestAccess`
would swallow any errors returned from the API.
* Implement API for setting RM
This is now stored on the server with similar treatment to RRs. The server will only store the specified eventId as the current read marker for a room if the event is ahead in the stream when compared to the existing RM. The exception is when the RM has never been set for this room for this user, in which case the event ID will be stored as the RM without any comparison.
This API also allows for an optional RR event ID to be sent in the same request. This is because it might be the common case for some clients to update the RM at the same time as updating the RR.
See design: https://docs.google.com/document/d/1UWqdS-e1sdwkLDUY0wA4gZyIkRp-ekjsLZ8k6g_Zvso/edit
See server-side PRs: https://github.com/matrix-org/synapse/pull/2120, https://github.com/matrix-org/synapse/pull/2128
* Make sync communicate with the sync accumulator via the store
* Consequently get rid of getSyncAccumulator as it's now
unnecessary.
* Make the bit that gets the saved sync response async, because
we'll need it to be when it's coming over postMessage from a
webworker.
* Functionality for msisdn signin
* Add methods to request tokens from synapse to do msisdn
verification
* Extend interactive-auth to work with m.email.identity (which
is significant since email auth is quite a chunk more complex).
* Oops, fix merge
* Fix lint
* Add submitMsisdnToken
* Support the bind_msisdn param to register
Change the bind_email flag to an object with keys 'email' and
'msisdn', backwards compatibly.
Delay the upload of one-time keys until we have received a sync *without any
to-device messages*. Doing so means that we can try to avoid throwing away our
private keys just before we receive the to-device messages which use them.
Once we've decided to go ahead and upload them, we keep uploading them in
batches of 5 until we get to the desired 50 keys on the server. We then
periodically check that there are still enough on the server.
On first connect, or after a disconnection, poll /sync with timeout=0 until
we get no to_device messages back. This will allow us to figure out whether we
have more to_device messages queued up for us on the server, which in turn will
help us fix a bug with clearing out one-time-keys too quickly.
In an attempt to make the rageshake logs a bit more useful, try to make the
logging a bit saner. Firstly, make sure we log every decryption failure, and
log it exactly once, rather than in several places. Also record when we receive
megolm keys. Also add some more explicit logging in the sync loop.
The user of the SDK is responsible for DIing the main components:
let store = new IndexedDBStore(
new IndexedDBStoreBackend(window.indexedDB),
new SyncAccumulator(),
});
await store.startup();
let client = matrix.createClient({store: store});
Pass a store into the Crypto object so that it doesn't need to make assumptions
about the EventEmitter, and use the new metadata on sync events to distinguish
between initialsyncs and normal syncs
