MSC4075: MatrixRTC notifications & call ringing#4075
Conversation
Signed-off-by: Timo K <toger5@hotmail.de>
Signed-off-by: Timo K <toger5@hotmail.de>
Signed-off-by: Timo K <toger5@hotmail.de>
turt2live
added
A-VOIP
proposal
Signed-off-by: Timo K <toger5@hotmail.de>
Signed-off-by: Timo K <toger5@hotmail.de>
See: [MSC4075]( matrix-org/matrix-spec-proposals#4075) Signed-off-by: Timo K <toger5@hotmail.de>
See: [MSC4075]( matrix-org/matrix-spec-proposals#4075) Signed-off-by: Timo K <toger5@hotmail.de>
See: [MSC4075]( matrix-org/matrix-spec-proposals#4075) Signed-off-by: Timo K <toger5@hotmail.de>
See: [MSC4075]( matrix-org/matrix-spec-proposals#4075) Signed-off-by: Timo K <toger5@hotmail.de>
See: [MSC4075]( matrix-org/matrix-spec-proposals#4075) Signed-off-by: Timo K <toger5@hotmail.de>
See: [MSC4075]( matrix-org/matrix-spec-proposals#4075) Signed-off-by: Timo K <toger5@hotmail.de>
|
@toger5 You've added some implementations in the PR description. Do these implement the MSC in full, or are there parts of the MSC that are still lacking implementation? |
|
Yes it's implemented in full. At least on the platforms shown in the description (EW). There are optional configurations that are still missing. (Allowing to send a notification to a specific subset of users) but the API for this is already part of the SDK. There is no ui for this however and we are not sure we want that in EW. |
Signed-off-by: Timo K <toger5@hotmail.de>
github-project-automation
Bot
moved this to Tracking for review
in Spec Core Team Workflow
#6207) <!-- description of the changes in this PR --> Updates ruma from ruma/ruma@289bee8 to ruma/ruma@89dab44 see 4250d65 Depends on this ruma PR github.com/ruma/ruma/pull/2383 Support for reading the intent from the notification event (m.call.intent in notification event as per matrix-org/matrix-spec-proposals#4075) Parity with js-sdk implementation https://github.com/matrix-org/matrix-js-sdk/blob/bd6547c0814e11b41e79de3cc9d0d4ecf7648272/src/matrixrtc/types.ts#L150 - [ ] I've documented the public API Changes in the appropriate `CHANGELOG.md` files. - [ ] I've read [the `CONTRIBUTING.md` file](https://github.com/matrix-org/matrix-rust-sdk/blob/main/CONTRIBUTING.md), notably the sections about Pull requests, Commit message format, and AI policy. - [ ] This PR was made with the help of AI. <!-- Sign-off, if not part of the commits --> <!-- See CONTRIBUTING.md if you don't know what this is --> Signed-off-by:
|
|
||
| ### Client behaviour on receiving a `m.rtc.notification` event | ||
|
|
||
| On retrieval, the client should not render the event in the timeline. |
There was a problem hiding this comment.
I'm working on an implementation for Fractal (https://gitlab.gnome.org/World/fractal/-/issues/1720) and I believe this should be the event to anchor a rendering of the call in the timeline. If we're in a MatrixRTC world, what else would we use?
There was a problem hiding this comment.
The long term plan on no matrixRTC timeline rendering is to use the m.rtc.member events they mark join and leaves.
A time based overlap computation of join/leave intervals (member sessions) will then be used to compute a historic call.
Similar to how we currently group other timeline events in clients (e.g. UserA and 10 other users join the room)
a new item would combine all the session information (UserA and 8 others participated in a call from X.XX until Y.YY)
There was a problem hiding this comment.
But using the notification event is an acceptable stop gap. There are discussions if we want a specific notification as part of the m.call MSC instead of a general purpose m.notification event.
(mostly because that would allow a notification acknowlege response, which is needed for a reliable ring feedback UX)
So pls dont put too much time into the m.rtc.notification based approach. Make it simple.
Feel free to explore the "time based overlap computation of join/leave intervals" approach. It probably needs work in the rust sdk since this would be where the code should life.
If you look into this I would be very happy to be kept in the loop (ping me once a plan is laid out in an issue). (I already did some consideration on this topic and it would be unfortunate to waste resources due to a lack of communication)
There was a problem hiding this comment.
I think it should be added to the MSC then, since it mentions this shouldn't be rendered, that it points to an MSC that contains the part that would be rendered. Otherwise this is confusing looking at this from the application side.
… internal discussions Signed-off-by: Johannes Marbach <n0-0ne+github@mailbox.org>
| - `sender_ts`:\ | ||
| The local timestamp on the sending device when the event was emitted. This is used in combination | ||
| with `lifetime` to evaluate if the notification event is valid. To mitigate clients lying about | ||
| the `sender_ts`, this value has to be checked against `origin_server_ts`. Receivers SHOULD use | ||
| `origin_server_ts` if `|sender_ts - origin_server_ts| > 20000 ms`. |
There was a problem hiding this comment.
Should we clarify why we trust the sender's local time to be more accurate than the sending server's local time?
Signed-off-by: Johannes Marbach <n0-0ne+github@mailbox.org>
Johennes
changed the title
m.rtc.notification Call Ringing and Notifications
14 participants
Rendered
To-do:
04635eb(#4075)m.rtc.notificationevent (depreceatem.call.notify) ruma/ruma#21997c996bb(#4075)m.rtc.notificationevent (depreceatem.call.notify) ruma/ruma#21996362c23(#4075)m.rtc.notificationevent (depreceatem.call.notify) ruma/ruma#2199lifetimeconcept makes sense. It allows the sending client to know/control when the receiver stops ringing. Additional precautions need to take place to not allow for infinite rings. This is part of6362c23(#MSC4075)Dependencies:
Implementations: