MSC4388 won't have the full rendezvous URL encoded in the QR code,
instead it'll have a rendezvous ID.
So let's remove this accessors and use the `intent_data()` getter
instead.
MSC4388: https://github.com/matrix-org/matrix-spec-proposals/pull/4388
Since the intent is encoded differently in MSC4108 and MSC4388 it
doesn't make sense to publicly expose the binary constants for a
specific MSC in the public API.
This patch removes access to the binary constants and you only access to
a generic enum.
This patch modifies the QrLoginData, it now hides all its public fields
and appropriate getters have been created for it instead.
This is necessary to hide the MSC specific parts of the data type thus
allowing support of multiple versions of the data type.
Our current implementation of this QR code data type corresponds to the
data type defined in MSC4108. The data format has been updated a bit in
MSC4833 and thus we'll need to support both formats for a while.
This moves al the MSC4108-specific parts into a separate MSC-specific
submodule.
MSC4108: https://github.com/matrix-org/matrix-spec-proposals/pull/4108
Instead of going through `serde_json::to_value()` and then converting it
to canonical JSON to serialize it.
Currently `to_canonical_value()` has the same behavior internally as
here, but an upcoming change in Ruma makes it use its own `Serializer`
so it is directly serialized as a `CanonicalJsonValue` which should be
somewhat more efficient.
This upcoming change also removes the `CanonicalJsonError::SerDe`
variant, so it is not as straightforward to propagate
`serde_json::Error`s.
This commit also removes outdated `#[allow(clippy::…)]` attributes.
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
While https://github.com/matrix-org/matrix-rust-sdk/pull/6017 is mostly
functional, there are two issues:
- I did not process `changes.room_key_bundles_fully_downloaded` in
`matrix-sdk-sqlite`, meaning any updates made via `Changes` would not be
persisted;
- I used a non-encrypting `JsValue` serialisation for the same field in
`matrix-sdk-indexeddb`, which causes errors when passed to the
decryption-enabled deserializer.
Solutions:
- Process the aforementioned changes such that keys are added to SQLite;
- Use a non-encrypting deserialiser, since this is effectively a
hash-set, and the contents aren't sensitive.
Signed-off-by: Skye Elliot <actuallyori@gmail.com>
feat: Add `forwarder: ForwarderInfo` to `EncryptionInfo`.
Introduces `ForwarderInfo` which which exposes information about the forwarder of the keys with which an event was encrypted if they were shared as part of an [MSC4268](https://github.com/matrix-org/matrix-spec-proposals/pull/4268) room key bundle.
<!-- description of the changes in this PR -->
- Introduces a new enum `ForwarderData` as a wrapper for valid variants
of `SenderData` for which we can accept key bundles under MSC4268.
- Converts `forwarder_data` in `InboundGroupSession` and
`PickledInboundGroupSession` to use `Option<ForwarderData>` over
`Option<SenderData>`.
- [x] Public API changes documented in changelogs (optional)
---------
Signed-off-by: Skye Elliot <actuallyori@gmail.com>
This method will retrieve the database sizes if available and expose it in the client.
Note: the actual database size measuring is only implemented for the SQLite based stores
... with `merge_received_group_session`.
`merge_received_group_session` expands the logic of `compare_group_session` to
handle the fact that there is more than one axis of "better" or "worse" and we
may need to take the best bits of two copies of the session.
In order to correctly merge sessions, we need more granular comparisons between
two sessions than just "Better" or "Worse", so factor out a method that *just*
looks at the ratchet states.
This patch adds `CrossProcessLockGeneration`. A lock generation is an
integer incremented each time the lock is taken by another holder. If
the generation changes, it means the lock is _dirtied_. This _dirtying_
aspect is going to be expanded in the next patches. This patch focuses
on the introduction of this _generation_.
The `CrossProcessLock::try_lock_once` method, and
the `TryLock::try_lock` method, both returns a
`Option<CrossProcessLockGeneration>` instead of a `bool`: `true` is
replaced by `Some(_)`, `false` by `None`.
I find a single match statement easier to reason about than one nested in another.
Also, import `UnableToDecryptReason::*`, to shorten the match lines.
When constructing a key bundle, if we had received a key bundle ourselves, in
which one or more sessions was marked as "history not shared", pass that on to
the new user.
Benjamin Bouvier