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

MSC3930: Polls push rules/notifications #3930

Merged
merged 10 commits into from
Aug 21, 2023
120 changes: 120 additions & 0 deletions proposals/3930-polls-notifications.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,120 @@
# MSC3930: Polls push rules/notifications
turt2live marked this conversation as resolved.
Show resolved Hide resolved

[MSC3381](https://github.com/matrix-org/matrix-spec-proposals/pull/3381) describes how chat polls can work,
though deliberately leaves out details on how push rules or notifications could work for such a feature.
This proposal aims to address that specific feature gap.

Readers should review MSC3381 to better understand how polls are intended to operate in a room.

Push rules are currently defined [here](https://spec.matrix.org/v1.5/client-server-api/#push-rules) in
specification.

## Proposal

In order to have polls behave similar to message events, the following underride push rules are defined.
turt2live marked this conversation as resolved.
Show resolved Hide resolved
Note that the push rules are mirrored from those available to `m.room.message` events.

```json
{
"rule_id": ".m.rule.poll_start_one_to_one",
"default": true,
"enabled": true,
"conditions": [
{"kind": "room_member_count", "is": "2"},
{"kind": "event_match", "key": "type", "pattern": "m.poll.start"}
turt2live marked this conversation as resolved.
Show resolved Hide resolved
],
"actions": [
"notify",
{"set_tweak": "sound", "value": "default"}
]
}
```

```json
{
"rule_id": ".m.rule.poll_start",
"default": true,
"enabled": true,
"conditions": [
{"kind": "event_match", "key": "type", "pattern": "m.poll.start"}
],
"actions": [
"notify"
]
}
```

```json
{
"rule_id": ".m.rule.poll_end_one_to_one",
"default": true,
"enabled": true,
"conditions": [
{"kind": "room_member_count", "is": "2"},
{"kind": "event_match", "key": "type", "pattern": "m.poll.end"}
],
"actions": [
"notify",
{"set_tweak": "sound", "value": "default"}
]
}
```

```json
{
"rule_id": ".m.rule.poll_end",
"default": true,
"enabled": true,
"conditions": [
{"kind": "event_match", "key": "type", "pattern": "m.poll.end"}
],
"actions": [
"notify"
]
}
```

Additionally, a new override rule is defined to suppress poll responses by default:

```json
{
"rule_id": ".m.rule.poll_response",
"default": true,
"enabled": true,
"conditions": [
{"kind": "event_match", "key": "type", "pattern": "m.poll.response"}
],
"actions": []
}
```

*Note*: Lack of `actions` means "don't do anything with matching events", or "don't notify".

Typically these rules would be kept in sync with the `m.room.message` rules they are based upon,
however there is no requirement to do so. A client's approach might be to only keep them in sync
while setting the values, rather than monitoring for changes to push rules.

Clients might find [MSC3934](https://github.com/matrix-org/matrix-spec-proposals/pull/3934) of value
for keeping the rules in sync, though this MSC does not require MSC3934.

For the purposes of [MSC3932](https://github.com/matrix-org/matrix-spec-proposals/pull/3932), the
push rules defined in this proposal are *not* affected by the room version limitations. This is due
to polls not inherently being room version-specific, unlike other extensible event structures. For
clarity, this means the push rules described here are treated the same as `.m.rule.master` (for
example) - they always apply, regardless of room version.

## Potential issues

The push rules for this feature are complex and not ideal. The author believes that it solves a short
term need while other MSCs work on improving the notifications system. Most importantly, the author
believes future MSCs which aim to fix notifications for extensible events in general will be a more
preferred approach over this MSC's (hopefully) short-term solution.

## Security considerations

None applicable - no new considerations need to be made with this proposal.

## Unstable prefix

While this MSC is not considered stable, implementations should use `org.matrix.msc3930.*` as a prefix
in place of `m.*`.
anoadragon453 marked this conversation as resolved.
Show resolved Hide resolved
turt2live marked this conversation as resolved.
Show resolved Hide resolved