notifications silent in element x #1533

Closed
opened 2026-03-11 16:49:54 +00:00 by Reaster · 13 comments

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

"notification": {
"content": {
"body": "I'm floating in a most peculiar way.",
"msgtype": "m.text"
},
"counts": {
"missed_calls": 1,
"unread": 2
},
"devices": [
{
"app_id": "org.matrix.matrixConsole.ios",
"data": {},
"pushkey": "V2h5IG9uIGVhcnRoIGRpZCB5b3UgZGVjb2RlIHRoaXM/",
"pushkey_ts": 12345678,
"tweaks": {
"sound": "bing"
}
}
],
"event_id": "$3957tyerfgewrf384",
"prio": "high",
"room_alias": "#exampleroom:matrix.org",
"room_id": "!slw48wfj34rtnrf:example.com",
"room_name": "Mission Control",
"sender": "@exampleuser:matrix.org",
"sender_display_name": "Major Tom",
"type": "m.room.message"
}
}

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


				let mut device =
					Device::new(pusher.ids.app_id.clone(), pusher.ids.pushkey.clone());
				device.data.data.clone_from(&http.data);
				device.data.format.clone_from(&http.format);

				// Tweaks are only added if the format is NOT event_id_only
				if !event_id_only {
					device.tweaks.clone_from(&tweaks);
				}

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?

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 ```{ "notification": { "content": { "body": "I'm floating in a most peculiar way.", "msgtype": "m.text" }, "counts": { "missed_calls": 1, "unread": 2 }, "devices": [ { "app_id": "org.matrix.matrixConsole.ios", "data": {}, "pushkey": "V2h5IG9uIGVhcnRoIGRpZCB5b3UgZGVjb2RlIHRoaXM/", "pushkey_ts": 12345678, "tweaks": { "sound": "bing" } } ], "event_id": "$3957tyerfgewrf384", "prio": "high", "room_alias": "#exampleroom:matrix.org", "room_id": "!slw48wfj34rtnrf:example.com", "room_name": "Mission Control", "sender": "@exampleuser:matrix.org", "sender_display_name": "Major Tom", "type": "m.room.message" } } ``` 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 ``` let event_id_only = http.format == Some(PushFormat::EventIdOnly); let mut device = Device::new(pusher.ids.app_id.clone(), pusher.ids.pushkey.clone()); device.data.data.clone_from(&http.data); device.data.format.clone_from(&http.format); // Tweaks are only added if the format is NOT event_id_only if !event_id_only { device.tweaks.clone_from(&tweaks); } ``` 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?
Reaster changed title from default notifications silent in case event_id_only is set? to default notifications silent in element x 2026-03-11 16:50:17 +00:00
Reaster changed title from default notifications silent in element x to notifications silent in element x 2026-03-11 17:13:14 +00:00
Author

from what i understand, the spec don't specify that we should drop tweaks (clients[].tweaks) when event_id_only is set,

Homeserver behaviour

This describes the format used by “HTTP” pushers to send notifications of events to Push Gateways. If the endpoint returns an HTTP error code, the homeserver SHOULD retry for a reasonable amount of time using exponential backoff.

When pushing notifications for events, the homeserver is expected to include all of the event-related fields in the /notify request. When the homeserver is performing a push where the format is "event_id_only", only the event_id, room_id, counts, and devices are required to be populated.

Note that most of the values and behaviour of this endpoint is described by the Client-Server API’s Push Module.

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?

from what i understand, the spec don't specify that we should drop tweaks (clients[].tweaks) when event_id_only is set, ``` Homeserver behaviour This describes the format used by “HTTP” pushers to send notifications of events to Push Gateways. If the endpoint returns an HTTP error code, the homeserver SHOULD retry for a reasonable amount of time using exponential backoff. When pushing notifications for events, the homeserver is expected to include all of the event-related fields in the /notify request. When the homeserver is performing a push where the format is "event_id_only", only the event_id, room_id, counts, and devices are required to be populated. Note that most of the values and behaviour of this endpoint is described by the Client-Server API’s Push Module. ``` http://spec.matrix.org/v1.17/push-gateway-api/#post_matrixpushv1notify_request_device but synapse seems to do it anyway https://github.com/element-hq/synapse/blob/ae239280cb742968808ca1a4b7d7a84f67ca8177/synapse/push/httppusher.py#L492 maybe they get it right because tweaks would be set by default in their case?
Owner

Note that event_id_only exists 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.

Note that `event_id_only` exists 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.
Author

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)

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)
Owner

Duplicate of !1424 - clients should set the push rules they want to receive. Not including the "sound" tweak is correct per the current specification.

Duplicate of !1424 - clients should set the push rules they want to receive. Not including the "sound" tweak is correct per the current specification.
nex closed this issue 2026-03-11 17:22:16 +00:00
Author
fyi https://github.com/element-hq/element-x-ios/issues/5132
Author
https://github.com/matrix-org/matrix-rust-sdk/pull/6277
Owner

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.

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.

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_only or the push rules themselves.

As explained in MSC3575 [EDIT: previous versions of MSC4186 that are still in use], $ME and $LAZY in required_state are special sentinel values that Continuwuity must resolve. But currently, they are not treated in collect_required_state in src/api/client/sync/v5.rs. Only the sentinel value * is considered there.

In the Matrix Rust SDK used by Element X, get_push_room_context fails because context.state_changes.member(room_id, user_id) returns None. Box::pin(room.get_member(user_id)).await? works only occasionally, but this might be by design. And without get_push_room_context succeeding, 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_state in v5.rs to resolve $ME. Now, get_push_room_context doesn’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 $ME would be enough, but for completeness and conformity with MSC3575, $LAZY should not be neglected.

If this is correct, I hope someone more experienced with Rust and Matrix can do this soon.

I think I found the cause for this problem. It has nothing to do with `event_id_only` or the push rules themselves. As explained in ~[MSC3575](https://github.com/matrix-org/matrix-spec-proposals/blob/kegan/sync-v3/proposals/3575-sync.md#room-list-parameters)~ [EDIT: previous versions of [MSC4186](https://github.com/matrix-org/matrix-spec-proposals/blob/1786eeb7fd055b8757f51cb8c19904dd5b293891/proposals/4186-simplified-sliding-sync.md#special-values) that are still in use], `$ME` and `$LAZY` in `required_state` are special sentinel values that Continuwuity must resolve. But currently, they are not treated in `collect_required_state` in `src/api/client/sync/v5.rs`. Only the sentinel value `*` is considered there. In the Matrix Rust SDK used by Element X, [`get_push_room_context`](https://github.com/matrix-org/matrix-rust-sdk/blob/02c41e20ad8e9caafc5e0fc02984c7e42e364832/crates/matrix-sdk-base/src/response_processors/timeline.rs#L223) fails because `context.state_changes.member(room_id, user_id)` returns `None`. `Box::pin(room.get_member(user_id)).await?` works only occasionally, but this might be by design. And without `get_push_room_context` succeeding, 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_state` in `v5.rs` to resolve `$ME`. Now, `get_push_room_context` doesn’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 `$ME` would be enough, but for completeness and conformity ~with MSC3575~, `$LAZY` should not be neglected. If this is correct, I hope someone more experienced with Rust and Matrix can do this soon.
Owner

And without get_push_room_context succeeding, the Rust SDK never reaches the point where push rules are loaded and evaluated at all.

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)

> And without get_push_room_context succeeding, the Rust SDK never reaches the point where push rules are loaded and evaluated at all. 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_sync calls compute_status which seems to filter out notifications without the action notify only if push actions exist at all (see here). Then, a new NotificationItem is created, which has a field is_noisy. It’s set to None if no push actions exist (see here).

[`get_notifications_with_sliding_sync`](https://github.com/matrix-org/matrix-rust-sdk/blob/c04a97f706c457565e05e7311831c0e68dc5b8ad/crates/matrix-sdk-ui/src/notification_client.rs#L674) calls [`compute_status`](https://github.com/matrix-org/matrix-rust-sdk/blob/c04a97f706c457565e05e7311831c0e68dc5b8ad/crates/matrix-sdk-ui/src/notification_client.rs#L646) which seems to filter out notifications without the action `notify` only if push actions exist at all ([see here](https://github.com/matrix-org/matrix-rust-sdk/blob/c04a97f706c457565e05e7311831c0e68dc5b8ad/crates/matrix-sdk-ui/src/notification_client.rs#L653)). Then, a new `NotificationItem` is created, which has a field `is_noisy`. It’s set to `None` if no push actions exist ([see here](https://github.com/matrix-org/matrix-rust-sdk/blob/c04a97f706c457565e05e7311831c0e68dc5b8ad/crates/matrix-sdk-ui/src/notification_client.rs#L1022)).

@nex Are there already plans for this, or should this issue be reopened for better visibility? Or should I create a separate issue regarding $ME and $LAZY?

@nex Are there already plans for this, or should this issue be reopened for better visibility? Or should I create a separate issue regarding `$ME` and `$LAZY`?
Owner

I think a separate issue should be created

I think a separate issue should be created
Sign in to join this conversation.
No milestone
No project
No assignees
5 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
continuwuation/continuwuity#1533
No description provided.