Skip to content
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.

Sign up for GitHub

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

MSC3994: Display why an event caused a notification #3994

Draft
wants to merge 5 commits into
base: main
Choose a base branch
from
Draft

MSC3994: Display why an event caused a notification #3994

Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
fcc161d
Display why an event caused a notification
Apr 6, 2023
409ec0c
Use underscores in property names
Apr 11, 2023
550326d
update property names, add msc number
Apr 11, 2023
69bba03
add extra note about client side push processing
Apr 11, 2023
d1f116e
add more detail about alternative
Apr 11, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
32 changes: 32 additions & 0 deletions proposals/3994-display-notification-reason.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,32 @@
# MSC3994: Display why an event caused a notification

Currently users may not understand why a particular event caused a notification. This can be confusing, lead to notification fatigue, and make creating a custom notification setup difficult.

Currently it is not possible to identify which push rule triggered an action (notification/highlight/ping) for an event without rerunning push processing for that event on the client.

By identifying which rule triggered an action clients can reduce user confusion and enable better management of push rules.

For example: a user receiving pings for a keyword they forgot they had configured can easily understand the pings, and remove the keyword rule.

## Proposal

Extend the `Notification` object returned by [`GET /notifications`](https://spec.matrix.org/latest/client-server-api/#listing-notifications) to include the `kind` and `rule_id` of the executed push rule.
`kind` and `rule_id` (along with `room_id` and `profile_tag` already present) will enable the client to uniquely identify the matched rule locally if necessary.

| Name | Type | Description |
|--|--|--|
| `rule_kind` | [push rule kind](https://spec.matrix.org/latest/client-server-api/#push-rules) (`override` \| `content` \| `room` \| `sender` \| `underride`) | `kind` of the executed push rule |
| `rule_id` | string | `rule_id` of the executed push rule |


## Alternatives

Let clients determine the executed push rule. This would mean rerunning push processing client-side on notifications fetched from `/notifications`.
Clients likely already do client-side push processing in many cases. For example, Element Web runs client-side push rule processing for encrypted events, and on `/sync` response.

## Security considerations

N/A

## Unstable prefix
While this MSC is not included in the spec `rule_kind` and `rule_id` should use the unstable prefixes `org.matrix.msc3994.rule_kind` and `org.matrix.msc3994.rule_id` respectively