notifications silent in element x #1533
Labels
No labels
Blocked
Bug
Changelog
Added
Changelog
Missing
Changelog
None
Cherry-picking
Database
Dependencies
Dependencies/Renovate
Difficulty
Easy
Difficulty
Hard
Difficulty
Medium
Documentation
Enhancement
Good first issue
Help wanted
Inherited
Matrix/Administration
Matrix/Appservices
Matrix/Auth
Matrix/Client
Matrix/Core
Matrix/E2EE
Matrix/Federation
Matrix/Hydra
Matrix/MSC
Matrix/Media
Matrix/T&S
Merge
Merge/Manual
Merge/Squash
Meta
Meta/CI
Meta/Packaging
Priority
Blocking
Priority
High
Priority
Low
Security
Status
Confirmed
Status
Duplicate
Status
Invalid
Status
Needs Investigation
Support
Wont fix
old/ci/cd
old/rust
No milestone
No project
No assignees
5 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
continuwuation/continuwuity#1533
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
hi, seems that in the case of element x, it need the tweaks field to be set, else would (?) default to silent notifications
the "tweaks"field in this example
https://spec.matrix.org/v1.17/push-gateway-api/#post_matrixpushv1notify_request_device
"A dictionary of customisations made to the way this notification is to be presented. These are added by push rules."
at first i tought it was this at cause
mod.rs line 427
but apparently (jade) event_id_only that deactivate tweaks register is a good behaviour,
in that case maybe tweaks should have some kind of default values?
default notifications silent in case event_id_only is set?to default notifications silent in element xdefault notifications silent in element xto notifications silent in element xfrom what i understand, the spec don't specify that we should drop tweaks (clients[].tweaks) when event_id_only is set,
http://spec.matrix.org/v1.17/push-gateway-api/#post_matrixpushv1notify_request_device
but synapse seems to do it anyway
github.com/element-hq/synapse@ae239280cb/synapse/push/httppusher.py (L492)maybe they get it right because tweaks would be set by default in their case?
Note that
event_id_onlyexists because push notifications may be sent through intermediaries, and we want to avoid leaking metadata - clients are expected to fetch the actual event to display notifications. This is unlikely to be the issue.i still don't understand why "tweaks" would be a privacy issue, the spec don't precise to remove it, only synapse does it, but maybe never using tweaks when event_id_only is set and always using a default value for it would be a valid fix (i guess)
Duplicate of !1424 - clients should set the push rules they want to receive. Not including the "sound" tweak is correct per the current specification.
fyi
https://github.com/element-hq/element-x-ios/issues/5132
https://github.com/matrix-org/matrix-rust-sdk/pull/6277
For anyone finding this issue, the matrix spec defines that messages should notify, but not make a sound (i.e. quiet notifications): https://spec.matrix.org/v1.17/client-server-api/#default-override-rules:~:text=%7D%0A%20%20%20%20%5D%0A%7D-,.m.rule.message,-Matches%20all%20chat
The reason this does not happen on Synapse is because Synapse's default push rules differ from the specification. Continuwuity is doing this correctly.
You can make them noisy by using another client, like Element Web, to modify the notification settings to make them noisy.
It’s not just Synapse; Dendrite pushing audio is also normal. This is likely a characteristic of Matrix 2.0, though the older specifications haven't been updated.,Even those who create rules can make mistakes.
I think I found the cause for this problem. It has nothing to do with
event_id_onlyor the push rules themselves.As explained in
MSC3575[EDIT: previous versions of MSC4186 that are still in use],$MEand$LAZYinrequired_stateare special sentinel values that Continuwuity must resolve. But currently, they are not treated incollect_required_stateinsrc/api/client/sync/v5.rs. Only the sentinel value*is considered there.In the Matrix Rust SDK used by Element X,
get_push_room_contextfails becausecontext.state_changes.member(room_id, user_id)returnsNone.Box::pin(room.get_member(user_id)).await?works only occasionally, but this might be by design. And withoutget_push_room_contextsucceeding, the Rust SDK never reaches the point where push rules are loaded and evaluated at all.With Synapse,
context.state_changes.member(room_id, user_id)returns the member correctly.For testing purposes, I modified
collect_required_stateinv5.rsto resolve$ME. Now,get_push_room_contextdoesn’t fail anymore and Element X sets notifications to noisy as defined in the push rules.That means, for this issue, implementation of proper handling of
$MEwould be enough, but for completeness and conformitywith MSC3575,$LAZYshould not be neglected.If this is correct, I hope someone more experienced with Rust and Matrix can do this soon.
How would this result in silent notifications then? I would've assumed this would've resulted in no/missed notifications (which, granted, is another issue we've heard of from time to time, so probably worth looking into anyway)
get_notifications_with_sliding_synccallscompute_statuswhich seems to filter out notifications without the actionnotifyonly if push actions exist at all (see here). Then, a newNotificationItemis created, which has a fieldis_noisy. It’s set toNoneif no push actions exist (see here).@nex Are there already plans for this, or should this issue be reopened for better visibility? Or should I create a separate issue regarding
$MEand$LAZY?I think a separate issue should be created
$MEand$LAZYinrequired_stateare not resolved #1661