From 7294da17993977f423f4853feeecf3f5a7233017 Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Fri, 15 Apr 2022 14:04:31 -0400 Subject: [PATCH 01/15] Add initial MSC for a push rule for threads. --- ...sh-rules-for-mutually-relationed-events.md | 204 ++++++++++++++++++ 1 file changed, 204 insertions(+) create mode 100644 proposals/3772-push-rules-for-mutually-relationed-events.md diff --git a/proposals/3772-push-rules-for-mutually-relationed-events.md b/proposals/3772-push-rules-for-mutually-relationed-events.md new file mode 100644 index 00000000000..3c477266234 --- /dev/null +++ b/proposals/3772-push-rules-for-mutually-relationed-events.md @@ -0,0 +1,204 @@ +# MSC3772: Push rule for mutually related events + +It is useful for users to be able to control getting notified for events which +relate to events they have shown interest in. This is useful if: + +* Another user replies to a thread the user has also replied to, i.e. the user is + interested in a thread and wants to know when others respond. +* Another user has voted in a poll the user has voted in, i.e. the user wants to + know the results of a poll as people vote for it. +* For "subscribing" to or "following" a thread or poll.[^1] + +## Proposal + +## New push rule condition: ``relation_match`` + +A new push rule condition is proposed to match against other events which relate +to the same event as the current event. Unlike [MSC3664](https://github.com/matrix-org/matrix-spec-proposals/pull/3664), +which matches against the *related event*, this proposes matching against the *relation +of other events*. Such a condition could look like this: + +```json +{ + "kind": "relation_match", + "rel_type": "m.thread", + "sender": "@me:my.server" +} +``` + +This condition can be used to notify me whenever someone sends a reply to a thread +that I have also replied to. For example, if there's a thread on event `A` and +I have sent event `B`, the rule could match event `C` from another user. + +```mermaid +flowchart RL + C-->A + B-->A +``` + +The condition can include the following fields to check: + +* `rel_type`: The relation type of the other event to the parent event. +* `sender` (optional): The sender of the other event. +* `type` (optional): The type of the other event. + +Another example would be to be notified of a poll closing (from +[MSC3381](https://github.com/matrix-org/matrix-spec-proposals/pull/3381)), but +only if the user has voted in it: + +```json +[ + { + "kind": "event_match", + "key": "type", + "pattern": "m.poll.end" + }, + { + "kind": "relation_match", + "rel_type": "m.reference", + "sender": "@me:my.server", + "type": "m.poll.response" + } +] +``` + +(Note that the `type` is important since `m.reference` is used in multiple contexts.) + +For example, to match against any reply in a thread that the requester (`@me:my.server`) +has also replied to. + +A client can check for the `relation_match` condition being supported by testing +for an existing `.m.rule.thread_reply` in the default rules (see below). + +### A push rule for threads + +For users to easily track notification of threads they have interacted with the +following default push rule is proposed: + +```json5 +{ + "rule_id": ".m.rule.thread_reply", + "default": true, + "enabled": true, + "conditions": [ + { + "kind": "related_event_match", // from MSC3664 + "rel_type": "m.thread", + "key": "sender", + "pattern": "@me:my.server" + }, + { + "kind": "relation_match", + "rel_type": "m.thread", + "sender": "@me:my.server" + } + ], + "actions": [ + "notify" + ] +} +``` + +This matches: + +* When there is a reply to a thread that has the user's message as the root message. + (Note that this uses `related_event_match` from [MSC3664](https://github.com/matrix-org/matrix-spec-proposals/pull/3664).) +* When there is a reply to a thread that the user has also replied to. + +This should be an underride rule, since it can't be a content rule and should be +overridden when setting a room to mentions only. It should be placed just before +`.m.rule.message` in the list. This ensures you get notified for replies to threads +you're interested in. The actions are the same as for `.m.rule.message` and +`m.rule.encrypted`. + +Note that an encrypted form of this rule is not needed since relation information +and metadata required for it to function is not encrypted. + +## Potential issues + +### Performance + +Most push rules for mutually related events will need a lookup into metadata on +other events. This causes additional implementation complexity and can potentially +be expensive. The fields available for the `relation_match` are chosen to be event +and relation metadata to avoid requiring evaluation against the event contents +of many events. + +### Client implementation + +This may be difficult for clients to implement (as they may not know every related +event without fetching many events locally), but for the default case of matching +against the sender's events it should be reasonable to implement. + +Additionally, it should be possible to implement this for encrypted rooms server +side due to [event relations not being encrypted](https://github.com/matrix-org/matrix-spec/issues/660). +There may not be enough information for a client to understand why an unread +notification came from a relation, however. + +### Updating default push rules + +As mentioned in [MSC3664](https://github.com/matrix-org/matrix-spec-proposals/pull/3664), +adding a new rule could cause notifications for users who have previously disabled +notifications. This is made worse by clients potentially not yet having UI to +disable the notifications. Overall it is seen as an improvement that allows users +to have finger grain control of notifications in threads. + +## Alternatives + +### Alternative to push rules + +There have been thoughts to replace push rules (see [MSC2785](https://github.com/matrix-org/matrix-spec-proposals/pull/2785)) +or to circumvent them (see [MSC2654](https://github.com/matrix-org/matrix-spec-proposals/pull/2654)) +for some notification work, but since they are the current system used for notification +it seems prudent to build on top of them instead of blocking behind work that is +not finished. + +### `sender` field + +All of the given examples are only relevant when the current user also has a +relation to same parent event as the current event being checked. This could be +assumed instead of having a `sender` field, but would be less flexible. For +example, it would not be possible to create a rule such as "notify me of any thread +which includes a poll in it". + +## Security considerations + +N/A + +## Unstable prefix + +While this feature is in development the following unstable prefixes should be used: + +* `relation_match` --> `org.matrix.MSC3772.relation_match` + +## Dependencies + +This MSC depends on the following MSCs, which at the time of writing have not yet +been accepted into the spec: + +* [MSC3664](https://github.com/matrix-org/matrix-spec-proposals/pull/3664): Pushrules for relations + +This MSC depends on the following MSCs, which have been accepted into the spec, +but have yet to be released: + +* [MSC2674](https://github.com/matrix-org/matrix-doc/pull/2674): Event Relationships +* [MSC3440](https://github.com/matrix-org/matrix-spec-proposals/pull/3440): Threading via `m.thread` relation + +[^1]: This is already possible today, but it is a useful example to consider. +For threads which a user is interested in a push rule can be added with the +following condition: + +```json +[ + { + "kind": "event_match", + "key": "content.relates_to.rel_type", + "pattern": "m.thread" + }, + { + "kind": "event_match", + "key": "content.relates_to.event_id", + "pattern": "$thread_root" + } +] +``` From a57c6a7d45608e4245b5b9e57b09a3b89bcee322 Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Mon, 25 Apr 2022 13:11:41 -0400 Subject: [PATCH 02/15] Clarify error conditions. --- proposals/3772-push-rules-for-mutually-relationed-events.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/proposals/3772-push-rules-for-mutually-relationed-events.md b/proposals/3772-push-rules-for-mutually-relationed-events.md index 3c477266234..13e50cf8685 100644 --- a/proposals/3772-push-rules-for-mutually-relationed-events.md +++ b/proposals/3772-push-rules-for-mutually-relationed-events.md @@ -70,6 +70,11 @@ has also replied to. A client can check for the `relation_match` condition being supported by testing for an existing `.m.rule.thread_reply` in the default rules (see below). +Matching is done on a best effort, when evaluating the push rule against an event +if the server (or client) doesn't know of any other events which meet the specified +conditions than the rule should not be matched and processing continues with the +next push rule. + ### A push rule for threads For users to easily track notification of threads they have interacted with the From cde203c08275ac6825fd96e8b4fa89cf4cb87992 Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Tue, 26 Apr 2022 14:50:28 -0400 Subject: [PATCH 03/15] Fix capitalization. Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> --- proposals/3772-push-rules-for-mutually-relationed-events.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/3772-push-rules-for-mutually-relationed-events.md b/proposals/3772-push-rules-for-mutually-relationed-events.md index 13e50cf8685..8f76c5d60c0 100644 --- a/proposals/3772-push-rules-for-mutually-relationed-events.md +++ b/proposals/3772-push-rules-for-mutually-relationed-events.md @@ -174,7 +174,7 @@ N/A While this feature is in development the following unstable prefixes should be used: -* `relation_match` --> `org.matrix.MSC3772.relation_match` +* `relation_match` --> `org.matrix.msc3772.relation_match` ## Dependencies From 2d185a1858ceaa79dec09172af33a53df0127177 Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Tue, 26 Apr 2022 15:06:12 -0400 Subject: [PATCH 04/15] Clarify proposal. Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> --- proposals/3772-push-rules-for-mutually-relationed-events.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/proposals/3772-push-rules-for-mutually-relationed-events.md b/proposals/3772-push-rules-for-mutually-relationed-events.md index 8f76c5d60c0..9e651eec44a 100644 --- a/proposals/3772-push-rules-for-mutually-relationed-events.md +++ b/proposals/3772-push-rules-for-mutually-relationed-events.md @@ -15,8 +15,8 @@ relate to events they have shown interest in. This is useful if: A new push rule condition is proposed to match against other events which relate to the same event as the current event. Unlike [MSC3664](https://github.com/matrix-org/matrix-spec-proposals/pull/3664), -which matches against the *related event*, this proposes matching against the *relation -of other events*. Such a condition could look like this: +which matches against the *related event*, this proposes matching against *other events +with the same relation*. Such a condition could look like this: ```json { From f7003e19abcfbae9d32668535ab39bee18c12460 Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Tue, 26 Apr 2022 15:08:23 -0400 Subject: [PATCH 05/15] Clarify proposal. Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> --- proposals/3772-push-rules-for-mutually-relationed-events.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/3772-push-rules-for-mutually-relationed-events.md b/proposals/3772-push-rules-for-mutually-relationed-events.md index 9e651eec44a..d4a153379c4 100644 --- a/proposals/3772-push-rules-for-mutually-relationed-events.md +++ b/proposals/3772-push-rules-for-mutually-relationed-events.md @@ -70,7 +70,7 @@ has also replied to. A client can check for the `relation_match` condition being supported by testing for an existing `.m.rule.thread_reply` in the default rules (see below). -Matching is done on a best effort, when evaluating the push rule against an event +Matching is done on a best effort basis: when evaluating the push rule against an event, if the server (or client) doesn't know of any other events which meet the specified conditions than the rule should not be matched and processing continues with the next push rule. From a6a52ea732991e524ab3cb020283ecb7b8999c88 Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Tue, 26 Apr 2022 15:04:53 -0400 Subject: [PATCH 06/15] Add a link. --- proposals/3772-push-rules-for-mutually-relationed-events.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/proposals/3772-push-rules-for-mutually-relationed-events.md b/proposals/3772-push-rules-for-mutually-relationed-events.md index d4a153379c4..9fa238d0173 100644 --- a/proposals/3772-push-rules-for-mutually-relationed-events.md +++ b/proposals/3772-push-rules-for-mutually-relationed-events.md @@ -13,8 +13,9 @@ relate to events they have shown interest in. This is useful if: ## New push rule condition: ``relation_match`` -A new push rule condition is proposed to match against other events which relate -to the same event as the current event. Unlike [MSC3664](https://github.com/matrix-org/matrix-spec-proposals/pull/3664), +A new [push rule condition](https://spec.matrix.org/v1.2/client-server-api/#conditions-1) +is proposed to match against other events which relate to the same event as the +current event. Unlike [MSC3664](https://github.com/matrix-org/matrix-spec-proposals/pull/3664), which matches against the *related event*, this proposes matching against *other events with the same relation*. Such a condition could look like this: From 4687ced95efafca2e4da0142ab521668d3131e71 Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Tue, 26 Apr 2022 15:10:05 -0400 Subject: [PATCH 07/15] Remove unneeded line. --- proposals/3772-push-rules-for-mutually-relationed-events.md | 3 --- 1 file changed, 3 deletions(-) diff --git a/proposals/3772-push-rules-for-mutually-relationed-events.md b/proposals/3772-push-rules-for-mutually-relationed-events.md index 9fa238d0173..a68fc950e47 100644 --- a/proposals/3772-push-rules-for-mutually-relationed-events.md +++ b/proposals/3772-push-rules-for-mutually-relationed-events.md @@ -65,9 +65,6 @@ only if the user has voted in it: (Note that the `type` is important since `m.reference` is used in multiple contexts.) -For example, to match against any reply in a thread that the requester (`@me:my.server`) -has also replied to. - A client can check for the `relation_match` condition being supported by testing for an existing `.m.rule.thread_reply` in the default rules (see below). From 1d9389a439e43e5d3e9c18316a1757960826ae24 Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Tue, 26 Apr 2022 15:15:35 -0400 Subject: [PATCH 08/15] Create two default push rules. --- ...sh-rules-for-mutually-relationed-events.md | 54 ++++++++++++------- 1 file changed, 36 insertions(+), 18 deletions(-) diff --git a/proposals/3772-push-rules-for-mutually-relationed-events.md b/proposals/3772-push-rules-for-mutually-relationed-events.md index a68fc950e47..b27d155f2ef 100644 --- a/proposals/3772-push-rules-for-mutually-relationed-events.md +++ b/proposals/3772-push-rules-for-mutually-relationed-events.md @@ -76,11 +76,26 @@ next push rule. ### A push rule for threads For users to easily track notification of threads they have interacted with the -following default push rule is proposed: +following default push rules are proposed. + +Each rule should be a [default underride rule](https://spec.matrix.org/latest/client-server-api/#default-underride-rules), +since it can't be a content rule and should be overridden when setting a room to +mentions only. They should be placed just before `.m.rule.message` in the list. +This ensures you get notified for replies to threads you're interested in. The +actions are the same as for `.m.rule.message` and `m.rule.encrypted`. + +Note that an encrypted form of these rules are not needed since relation information +and metadata required for it to function is not encrypted. + +#### Threaded replies to the user's message + +To receive notification that there is a reply to a thread that has the user's +message as the root message. (Note that this uses `related_event_match` from +[MSC3664](https://github.com/matrix-org/matrix-spec-proposals/pull/3664).) ```json5 { - "rule_id": ".m.rule.thread_reply", + "rule_id": ".m.rule.thread_reply_to_me", "default": true, "enabled": true, "conditions": [ @@ -89,7 +104,25 @@ following default push rule is proposed: "rel_type": "m.thread", "key": "sender", "pattern": "@me:my.server" - }, + } + ], + "actions": [ + "notify" + ] +} +``` + +#### Replies to threads the user has replied to + +To receive notification when there is a reply to a thread that the user has also +replied to. + +```json5 +{ + "rule_id": ".m.rule.thread_reply", + "default": true, + "enabled": true, + "conditions": [ { "kind": "relation_match", "rel_type": "m.thread", @@ -102,21 +135,6 @@ following default push rule is proposed: } ``` -This matches: - -* When there is a reply to a thread that has the user's message as the root message. - (Note that this uses `related_event_match` from [MSC3664](https://github.com/matrix-org/matrix-spec-proposals/pull/3664).) -* When there is a reply to a thread that the user has also replied to. - -This should be an underride rule, since it can't be a content rule and should be -overridden when setting a room to mentions only. It should be placed just before -`.m.rule.message` in the list. This ensures you get notified for replies to threads -you're interested in. The actions are the same as for `.m.rule.message` and -`m.rule.encrypted`. - -Note that an encrypted form of this rule is not needed since relation information -and metadata required for it to function is not encrypted. - ## Potential issues ### Performance From 3c375b7c4c42dedacbec990473e50724ba81f2ff Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Mon, 16 May 2022 07:55:35 -0400 Subject: [PATCH 09/15] More unstable prefixes. --- proposals/3772-push-rules-for-mutually-relationed-events.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/proposals/3772-push-rules-for-mutually-relationed-events.md b/proposals/3772-push-rules-for-mutually-relationed-events.md index b27d155f2ef..379fae6dca3 100644 --- a/proposals/3772-push-rules-for-mutually-relationed-events.md +++ b/proposals/3772-push-rules-for-mutually-relationed-events.md @@ -191,6 +191,8 @@ N/A While this feature is in development the following unstable prefixes should be used: * `relation_match` --> `org.matrix.msc3772.relation_match` +* `.m.rule.thread_reply_to_me` --> `.org.matrix.msc3772.thread_reply_to_me` +* `.m.rule.thread_reply` --> `.org.matrix.msc3772.thread_reply` ## Dependencies From 68b826ecb3c36e83c9c33436322d0ff6c423e5f2 Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Tue, 17 May 2022 12:55:41 -0400 Subject: [PATCH 10/15] Reference MSC3816. --- .../3772-push-rules-for-mutually-relationed-events.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/proposals/3772-push-rules-for-mutually-relationed-events.md b/proposals/3772-push-rules-for-mutually-relationed-events.md index 379fae6dca3..1803f5e224e 100644 --- a/proposals/3772-push-rules-for-mutually-relationed-events.md +++ b/proposals/3772-push-rules-for-mutually-relationed-events.md @@ -3,8 +3,8 @@ It is useful for users to be able to control getting notified for events which relate to events they have shown interest in. This is useful if: -* Another user replies to a thread the user has also replied to, i.e. the user is - interested in a thread and wants to know when others respond. +* Another user replies to a thread the user has also replied to, i.e. the user has + participated in a thread and wants to know when others respond. * Another user has voted in a poll the user has voted in, i.e. the user wants to know the results of a poll as people vote for it. * For "subscribing" to or "following" a thread or poll.[^1] @@ -75,8 +75,9 @@ next push rule. ### A push rule for threads -For users to easily track notification of threads they have interacted with the -following default push rules are proposed. +For users to easily track notification of threads they have participated in (as +defined in [MSC3816](https://github.com/matrix-org/matrix-spec-proposals/pull/3816)) +the following default push rules are proposed. Each rule should be a [default underride rule](https://spec.matrix.org/latest/client-server-api/#default-underride-rules), since it can't be a content rule and should be overridden when setting a room to @@ -200,6 +201,7 @@ This MSC depends on the following MSCs, which at the time of writing have not ye been accepted into the spec: * [MSC3664](https://github.com/matrix-org/matrix-spec-proposals/pull/3664): Pushrules for relations +* [MSC3816](https://github.com/matrix-org/matrix-spec-proposals/pull/3816): Clarify Thread Participation This MSC depends on the following MSCs, which have been accepted into the spec, but have yet to be released: From 6d271882dcb032c43e5fa271c08fa4a7ee31f142 Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Tue, 17 May 2022 13:01:10 -0400 Subject: [PATCH 11/15] Fix footnote. --- proposals/3772-push-rules-for-mutually-relationed-events.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/proposals/3772-push-rules-for-mutually-relationed-events.md b/proposals/3772-push-rules-for-mutually-relationed-events.md index 1803f5e224e..e9025c9e466 100644 --- a/proposals/3772-push-rules-for-mutually-relationed-events.md +++ b/proposals/3772-push-rules-for-mutually-relationed-events.md @@ -7,7 +7,7 @@ relate to events they have shown interest in. This is useful if: participated in a thread and wants to know when others respond. * Another user has voted in a poll the user has voted in, i.e. the user wants to know the results of a poll as people vote for it. -* For "subscribing" to or "following" a thread or poll.[^1] +* For "subscribing" to or "following" a thread or poll.[1](#f1) ## Proposal @@ -209,7 +209,7 @@ but have yet to be released: * [MSC2674](https://github.com/matrix-org/matrix-doc/pull/2674): Event Relationships * [MSC3440](https://github.com/matrix-org/matrix-spec-proposals/pull/3440): Threading via `m.thread` relation -[^1]: This is already possible today, but it is a useful example to consider. +[1]: This is already possible today, but it is a useful example to consider. For threads which a user is interested in a push rule can be added with the following condition: @@ -227,3 +227,5 @@ following condition: } ] ``` + +[↩](#a1) From 03e84e0f2d5b441efae3d8cf70b54d034aaedf18 Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Tue, 17 May 2022 13:11:39 -0400 Subject: [PATCH 12/15] Remove an example which is already possible. --- ...sh-rules-for-mutually-relationed-events.md | 45 ++++++++++--------- 1 file changed, 23 insertions(+), 22 deletions(-) diff --git a/proposals/3772-push-rules-for-mutually-relationed-events.md b/proposals/3772-push-rules-for-mutually-relationed-events.md index e9025c9e466..43c481d1d6c 100644 --- a/proposals/3772-push-rules-for-mutually-relationed-events.md +++ b/proposals/3772-push-rules-for-mutually-relationed-events.md @@ -7,7 +7,6 @@ relate to events they have shown interest in. This is useful if: participated in a thread and wants to know when others respond. * Another user has voted in a poll the user has voted in, i.e. the user wants to know the results of a poll as people vote for it. -* For "subscribing" to or "following" a thread or poll.[1](#f1) ## Proposal @@ -183,6 +182,29 @@ assumed instead of having a `sender` field, but would be less flexible. For example, it would not be possible to create a rule such as "notify me of any thread which includes a poll in it". +### Manually subscribing to interesting threads + +An alternative could be for clients to manually subscribe to threads that the +user relies to, which is possible today: + +```json +[ + { + "kind": "event_match", + "key": "content.relates_to.rel_type", + "pattern": "m.thread" + }, + { + "kind": "event_match", + "key": "content.relates_to.event_id", + "pattern": "$thread_root" + } +] +``` + +For user which heavily users threads, this could cause a significant number of +push rules to be added. + ## Security considerations N/A @@ -208,24 +230,3 @@ but have yet to be released: * [MSC2674](https://github.com/matrix-org/matrix-doc/pull/2674): Event Relationships * [MSC3440](https://github.com/matrix-org/matrix-spec-proposals/pull/3440): Threading via `m.thread` relation - -[1]: This is already possible today, but it is a useful example to consider. -For threads which a user is interested in a push rule can be added with the -following condition: - -```json -[ - { - "kind": "event_match", - "key": "content.relates_to.rel_type", - "pattern": "m.thread" - }, - { - "kind": "event_match", - "key": "content.relates_to.event_id", - "pattern": "$thread_root" - } -] -``` - -[↩](#a1) From 02c72caf0b9e22bc2bf1edcc6fa4f814e2801426 Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Fri, 20 May 2022 10:04:19 -0400 Subject: [PATCH 13/15] Clarify what are glob patterns. --- proposals/3772-push-rules-for-mutually-relationed-events.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/proposals/3772-push-rules-for-mutually-relationed-events.md b/proposals/3772-push-rules-for-mutually-relationed-events.md index 43c481d1d6c..a51b47698b4 100644 --- a/proposals/3772-push-rules-for-mutually-relationed-events.md +++ b/proposals/3772-push-rules-for-mutually-relationed-events.md @@ -39,8 +39,8 @@ flowchart RL The condition can include the following fields to check: * `rel_type`: The relation type of the other event to the parent event. -* `sender` (optional): The sender of the other event. -* `type` (optional): The type of the other event. +* `sender` (optional): A glob pattern to match against the sender of the other event. +* `type` (optional): A globa pattern to match against the type of the other event. Another example would be to be notified of a poll closing (from [MSC3381](https://github.com/matrix-org/matrix-spec-proposals/pull/3381)), but From f008452f6c697e39a6217d95ce007dfa33e64105 Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Tue, 24 May 2022 09:38:02 -0400 Subject: [PATCH 14/15] Various updates. --- ...sh-rules-for-mutually-relationed-events.md | 47 ++++++++++--------- 1 file changed, 25 insertions(+), 22 deletions(-) diff --git a/proposals/3772-push-rules-for-mutually-relationed-events.md b/proposals/3772-push-rules-for-mutually-relationed-events.md index a51b47698b4..c54d0ee8fd5 100644 --- a/proposals/3772-push-rules-for-mutually-relationed-events.md +++ b/proposals/3772-push-rules-for-mutually-relationed-events.md @@ -26,9 +26,10 @@ with the same relation*. Such a condition could look like this: } ``` -This condition can be used to notify me whenever someone sends a reply to a thread -that I have also replied to. For example, if there's a thread on event `A` and -I have sent event `B`, the rule could match event `C` from another user. +This condition matches whenever someone sends a reply to a thread that `@me:my.server` +has also replied to. For example, if there's a thread on event `A` and +`@me:my.server` has sent event `B`, the rule would match event `C` sent from +another user. ```mermaid flowchart RL @@ -38,9 +39,11 @@ flowchart RL The condition can include the following fields to check: -* `rel_type`: The relation type of the other event to the parent event. -* `sender` (optional): A glob pattern to match against the sender of the other event. -* `type` (optional): A globa pattern to match against the type of the other event. +* `rel_type`: The relation type of the mutually related event to the parent event. +* `sender` (optional): A glob pattern to match against the sender of the mutually + related event. +* `type` (optional): A globa pattern to match against the type of the mutually + related event. Another example would be to be notified of a poll closing (from [MSC3381](https://github.com/matrix-org/matrix-spec-proposals/pull/3381)), but @@ -62,15 +65,16 @@ only if the user has voted in it: ] ``` -(Note that the `type` is important since `m.reference` is used in multiple contexts.) +(Note that the `type` is important since `m.reference` is used in multiple contexts, +see [MSC3267](https://github.com/matrix-org/matrix-doc/pull/3267).) A client can check for the `relation_match` condition being supported by testing for an existing `.m.rule.thread_reply` in the default rules (see below). -Matching is done on a best effort basis: when evaluating the push rule against an event, -if the server (or client) doesn't know of any other events which meet the specified -conditions than the rule should not be matched and processing continues with the -next push rule. +Matching is done on a best effort basis: when evaluating the push rule against an +event, if the server (or client) doesn't know of any other events which meet the +specified conditions than the rule should not be matched and processing continues +with the next push rule. ### A push rule for threads @@ -79,13 +83,13 @@ defined in [MSC3816](https://github.com/matrix-org/matrix-spec-proposals/pull/38 the following default push rules are proposed. Each rule should be a [default underride rule](https://spec.matrix.org/latest/client-server-api/#default-underride-rules), -since it can't be a content rule and should be overridden when setting a room to +since it isn't a content rule and should be overridden when setting a room to mentions only. They should be placed just before `.m.rule.message` in the list. This ensures you get notified for replies to threads you're interested in. The actions are the same as for `.m.rule.message` and `m.rule.encrypted`. -Note that an encrypted form of these rules are not needed since relation information -and metadata required for it to function is not encrypted. +Note that an encrypted form of these rules are not needed since the relation +information and metadata required for these rules to function is not encrypted. #### Threaded replies to the user's message @@ -176,16 +180,15 @@ not finished. ### `sender` field -All of the given examples are only relevant when the current user also has a -relation to same parent event as the current event being checked. This could be -assumed instead of having a `sender` field, but would be less flexible. For -example, it would not be possible to create a rule such as "notify me of any thread -which includes a poll in it". +The examples are only relevant when the current user also has a relation to same +parent event as the event being processed. This proposal could be simplified to +require that instead of having a `sender` field. This would reduce flexibility, +while not dramatically simplifying implementation. ### Manually subscribing to interesting threads An alternative could be for clients to manually subscribe to threads that the -user relies to, which is possible today: +user replies to, which is possible today: ```json [ @@ -202,8 +205,8 @@ user relies to, which is possible today: ] ``` -For user which heavily users threads, this could cause a significant number of -push rules to be added. +This could cause a significant number of push rules to be added for a user which +interacts with many threads. ## Security considerations From 049e238d74e3bae7963d00e26cfe0def3d493ffe Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Tue, 24 May 2022 09:39:06 -0400 Subject: [PATCH 15/15] Fix typo. --- proposals/3772-push-rules-for-mutually-relationed-events.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/3772-push-rules-for-mutually-relationed-events.md b/proposals/3772-push-rules-for-mutually-relationed-events.md index c54d0ee8fd5..061920ba940 100644 --- a/proposals/3772-push-rules-for-mutually-relationed-events.md +++ b/proposals/3772-push-rules-for-mutually-relationed-events.md @@ -42,7 +42,7 @@ The condition can include the following fields to check: * `rel_type`: The relation type of the mutually related event to the parent event. * `sender` (optional): A glob pattern to match against the sender of the mutually related event. -* `type` (optional): A globa pattern to match against the type of the mutually +* `type` (optional): A glob pattern to match against the type of the mutually related event. Another example would be to be notified of a poll closing (from