* Introduce Membership TS type
* Adapt the Membership TS type to be an enum
* Add docstrings for KnownMembership and Membership
* Move Membership types into a separate file, exported from types.ts
---------
Co-authored-by: Stanislav Demydiuk <s.demydiuk@gmail.com>
* crypto.spec: make `keyResponder` a local var
it is never used between functions, so making it external was confusing
* Persist encryption state to the rust room list.
* `MatrixClient.shouldEncryptEventForRoom`: fix for rust crypto
Previously, we were not bothering to ask the Rust Crypto stack if it thought we
should be encrypting for a given room. This adds a new method to `CryptoApi`,
wires it up for legacy and Rust crypto, and calls it.
* Tests for persistent room list
* Replace `pendingEventEncryption` with a Set
We don't actually need the promise, so no need to save it.
This also fixes a resource leak, where we would leak a Promise and a HashMap
entry on each encrypted event.
* Convert `encryptEventIfNeeded` to async function
This means that it will always return a promise, so `encryptAndSendEvent` can't
tell if we are actually encrypting or not. Hence, also move the
`updatePendingEventStatus` into `encryptEventIfNeeded`.
* Simplify `encryptAndSendEvent`
Rewrite this as async.
* Factor out `MatrixClient.shouldEncryptEventForRoom`
* Inline a call to `isRoomEncrypted`
I want to deprecate this thing
... and replace a lot of calls to `MatrixClient.isRoomEncrypted` with it.
This is a lesser check (since it can be tricked by servers withholding the
state event), but for most cases it is sufficient. At the end of the day, if
the server witholds the state, the room is pretty much bricked anyway. The one
thing we *mustn't* do is allow users to send *unencrypted* events to the room.
* Support optional MSC3860 redirects
See `allow_redirect` across the media endpoints: https://spec.matrix.org/v1.9/client-server-api/#client-behaviour-7
* Update the tests
* Appease the linter
* Add test to appease SonarCloud
* Only add `allow_redirect` if the parameter is specified rather than defaulting to `false`
Signed-off-by: Michael Telatynski <7t3chguy@gmail.com>
---------
Signed-off-by: Michael Telatynski <7t3chguy@gmail.com>
Co-authored-by: Michael Telatynski <7t3chguy@gmail.com>
* Send authenticated /versions request
Implements [MSC4026](https://github.com/matrix-org/matrix-spec-proposals/pull/4026).
I believe this probably is as simple as this: it will mean that the versions
response can obviously change after logging in, but since the client is
constructed again with an access token, this should just work (?)
A remaining question is whether this needs to be optional. Opening the PR
to prompt the discussion. Apps might not expect it, but it's just the same
auth that we're sending to other endpoints on the same server.
* Fix tests
* Clear /versions cache on access token set
* Fix issue
* Fix jest test
* Fix even more jest failures
* Fix formatting
* Add a test
* Write test for older code
* Fix lint
* Rename method
* Make ctor deprecated
* Use sender instead of content.creator field on m.room.create events
* Restore room_version fields in fixtures
* Add test case for undefined sender scenario
* Stub implementation of `isCrossSigningReady`
* Stub implementation of `isSecretStorageReady`
* add tests to meet quality gate
* factor out common
* Remove accidentally-added file
* add deleteAccountData endpoint
* check server support and test
* test current state of memorystore
* interpret account data events with empty content as deleted
* add handling for (future) stable version of endpoint
* add getSafeUserId
* user getSafeUserId in deleteAccountData
* better jsdoc for throws documentation
