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.

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

MSC3664: Pushrules for relations #3664

Open
wants to merge 22 commits into
base: main
Choose a base branch
from
Open
Changes from 1 commit
Commits
Show all changes
22 commits
Select commit Hold shift + click to select a range
d5f43bb
Pushrules for relations
deepbluev7 Jan 21, 2022
53a4607
Mention beeper implementation
deepbluev7 Jan 21, 2022
fa8fc97
Remove my misunderstanding of push rule naming in synapse.
deepbluev7 Jan 21, 2022
b90cdb6
Rule order, clarifications and thread discussion
deepbluev7 Jan 24, 2022
a6eebe7
fix typo
deepbluev7 Jan 24, 2022
0161daa
Update proposals/3664-notifications-for-relations.md
deepbluev7 Jan 24, 2022
242a65c
value -> pattern
deepbluev7 Jan 24, 2022
070babc
Define how a client can check for support
deepbluev7 Jan 24, 2022
06b5393
Clarify pattern and key more
deepbluev7 Jan 24, 2022
f2a5c57
Update proposals/3664-notifications-for-relations.md
deepbluev7 Jan 25, 2022
aebe3e9
Update proposals/3664-notifications-for-relations.md
deepbluev7 Jan 25, 2022
1ead1da
Remove partial solution for threads in favour of a different proposal
deepbluev7 Jan 26, 2022
6e1d1bb
Mention issues with unexposed notification settings
deepbluev7 Jan 26, 2022
3a288b6
Apply suggestions from code review
deepbluev7 Feb 1, 2022
df9aab5
Fix conflict with threading MSC
deepbluev7 May 24, 2022
00b0ef9
Apply suggestions from code review
deepbluev7 May 24, 2022
519b95d
Update proposals/3664-notifications-for-relations.md
deepbluev7 May 24, 2022
c9d55e2
Add capabilities flag
deepbluev7 Oct 27, 2022
22e67c4
Apply suggestions from code review
deepbluev7 Oct 27, 2022
7248826
Clarify rule ignored <-> condition evaluated to false
deepbluev7 Oct 27, 2022
69fe03e
Clarify how key and pattern work
deepbluev7 Oct 27, 2022
b1897fa
Update proposals/3664-notifications-for-relations.md
deepbluev7 Nov 1, 2022
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
Prev Previous commit
Next Next commit
Clarify pattern and key more
Signed-off-by: Nicolas Werner <nicolas.werner@hotmail.de>
  • Loading branch information
deepbluev7 committed Jan 24, 2022
commit 06b539379bb1812ccf2f70130a034a0055f56d04
24 changes: 10 additions & 14 deletions proposals/3664-notifications-for-relations.md
Original file line number Diff line number Diff line change
@@ -45,19 +45,15 @@ messages.
- `key` (optional): The dot-separated field of the event to match, e.g. `content.body`
or `sender`. If it is not present, the condition should match all events,
that have a relation of type `rel_type`.
- `pattern` (optional): The glob-style pattern to match against. Patterns with
no special glob characters should be treated as having asterisks prepended
and appended when testing the condition. If this is not present, it should
match everything if the specific key is present.
- `pattern` (optional): The glob-style pattern to match against.

`key` and `pattern` have exactly the same meaning as in `event_match`
conditions, the wording is taken from the current spec. The wording of that is
currently debated in https://github.com/matrix-org/matrix-doc/issues/2637 and
this MSC just follows whatever the spec does for `event_match`.
conditions. See https://github.com/matrix-org/matrix-doc/issues/2637 for a
clarification of their behaviour.

`key` and `pattern` are optional to allow you to enable or suppress all
richvdh marked this conversation as resolved.
Show resolved Hide resolved
notifications for a specific event type. For example one could suppress
notifications for all events in
notifications for a specific relation type. For example one could suppress
notifications for all events with a realation from
deepbluev7 marked this conversation as resolved.
Show resolved Hide resolved
[threads](https://github.com/matrix-org/matrix-doc/pull/3440) and all
richvdh marked this conversation as resolved.
Show resolved Hide resolved
[edits](https://github.com/matrix-org/matrix-doc/pull/2676) with the following
two conditions:
@@ -76,11 +72,11 @@ two conditions:
}
```

Without a `key` the push rule can be evaluated without fetching the related to
event. If only `key` is present, `pattern` should be assumed to be `*`, which
allows you to match for a field being present regardless of its value. If only
`pattern` is present, servers should return an error when setting the rule.
Clients should ignore the `pattern` field if there is no `key` field.
Without a `key` and `pattern` the push rule can be evaluated without fetching
the related to event. If one of those two fields is missing, a server should
prevent those rules from being added with the appropriate error code. (A client
wouldn't have a choice but to ignore those keys if the server failed to prevent
the rule from being added.)
deepbluev7 marked this conversation as resolved.
Show resolved Hide resolved

A client can check for the `related_event_match` condition being supported by
testing for an existing `.m.rule.reply` in the default rules.