-
Notifications
You must be signed in to change notification settings - Fork 290
feat(WidgetDriver): Add to-device support (without encryption) #4963
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
9f38056
to
9504745
Compare
f6bd24a
to
16171b6
Compare
16171b6
to
3445127
Compare
d1f9f49
to
50c0c2a
Compare
3445127
to
bb14445
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #4963 +/- ##
==========================================
+ Coverage 85.83% 85.85% +0.02%
==========================================
Files 325 325
Lines 36027 36110 +83
==========================================
+ Hits 30922 31002 +80
- Misses 5105 5108 +3 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
c70a005
to
64c5426
Compare
A new widget filter is required to add support for to-device events. This allows to let the widget only send and receive to-device events it has negotiated capabilities for.
It consists of the following changes: - add a `NotifyNewToDeviceEvent` ToWidget request (a request that will be sent to the widget from the client when the client receives a widget action over the widget api) - add the `SendToDeviceRequest` (driver request that will be sent from the widget and asks the driver to send a ToDevice event) - add the ToDeviceActions to the required enums: `IncomingMessage`(machine), `MatrixDriverResponse`, `FromWidgetResponse`, `FromWidgetRequest`, `MatrixDriverRequestData`
5d3078c
to
39ccdca
Compare
I'm going to let poljar handle this next week as I have very little context on it. |
… events via cs api) This also hooks up the widget via the machine actions. And adds toDevice events to the subscription.
9ff12fa
to
35199a7
Compare
…ity. This needs to be part of the send/read capabilities so that to-device keys can be used.
ad770d9
to
aa35aad
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this has a couple of flaws that need to be addressed, the biggest concern here is about the security when sending and receiving to-device messages.
I also left a bunch of less important nits, mainly to get the terminology consistent.
Please take a look at our contributing guide for our preferred commit styiling: https://github.com/matrix-org/matrix-rust-sdk/blob/main/CONTRIBUTING.md#commit-message-format.
The first commit also doesn't compile on its own, unless you want to fix that we'll have to squash merge this PR, otherwise using git bisect
(if we ever need that tool) becomes hard.
Finally, I think that this deserves a changelog entry. Our contributing guide should help you with that as well: https://github.com/matrix-org/matrix-rust-sdk/blob/main/CONTRIBUTING.md#writing-changelog-entries.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alright, almost good to go. Left two small nits.
fn try_into(self) -> Result<send_event_to_device::v3::Response, Self::Error> { | ||
match self { | ||
MatrixDriverResponse::MatrixToDeviceSent(response) => Ok(response), | ||
_ => Err(anyhow::Error::msg("bug in MatrixDriver, received wrong event response")), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's use serde::de::Error::custom()
instead. anyhow
should generally not be used in libraries, it's meant to be used in applications.
A serde error makes sense here I would say.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is now good to go.
The widget Driver should be able to send and receive to-device events. This is useful for element call encryption keys.
This PR focusses on the widget driver and machine logic. To send/communicate the events from the widget to the driver.
It skips any encryption logic. Some of the encryption logic will be part of crypto crate and the code in the widget driver crate should be kept minimal once the crypto crate is ready.