|
| 1 | +# MSC4010: Push rules and account data |
| 2 | + |
| 3 | +Push rules have a [bespoke API](https://spec.matrix.org/v1.6/client-server-api/#push-rules-api) |
| 4 | +which clients use to retrieve, add, modify, and remove push rules. Any modifications |
| 5 | +made using this API are sent to all clients via a `m.push_rules` event in the |
| 6 | +`account_data` section in the |
| 7 | +[the next `/sync` response](https://spec.matrix.org/v1.6/client-server-api/#push-rules-events). |
| 8 | + |
| 9 | +The client-server API does not have any special behavior around using the |
| 10 | +[account data APIs](https://spec.matrix.org/v1.6/client-server-api/#client-behaviour-17) |
| 11 | +with the `m.push_rules` type leading to different behavior on different homeservers: |
| 12 | + |
| 13 | +* Synapse will accept the data and shadow the real push rules in `/sync`, but |
| 14 | + *won't use the data when evaluating push rules*. |
| 15 | +* Dendrite will return an HTTP 403 if you attempt to set `m.push_rules` via |
| 16 | + `/account_data`. |
| 17 | +* Conduit has no protections for special account data. It will accept `m.push_rules` via |
| 18 | + `/account_data` *and* use those when evaluating push rules. |
| 19 | + |
| 20 | +The [fully read marker](https://spec.matrix.org/v1.6/client-server-api/#fully-read-markers) |
| 21 | +operates in a similar way and |
| 22 | +[servers must reject updating `m.fully_read` via `/account_data`](https://spec.matrix.org/v1.6/client-server-api/#server-behaviour-10). |
| 23 | + |
| 24 | +Note that when attempting to set `m.fully_read` via `/account_data` the following |
| 25 | +behavior is observed: |
| 26 | + |
| 27 | +* Synapse will reject it with a 405 error (only for room account data). |
| 28 | +* Dendrite will reject it with an HTTP 403 error. |
| 29 | + |
| 30 | +## Proposal |
| 31 | + |
| 32 | +To make push rules data consistent with fully read markers, the following |
| 33 | +clarifications are offered: |
| 34 | + |
| 35 | +* The `m.push_rules` account data type becomes protected and cannot be set using |
| 36 | + the `/account_data` API, similarly to `m.fully_read`. |
| 37 | +* "Rejected" means to use the 405 error response as |
| 38 | + [documented](https://spec.matrix.org/v1.6/client-server-api/#put_matrixclientv3useruseridaccount_datatype): |
| 39 | + |
| 40 | + > This `type` of account data is controlled by the server; it cannot be modified |
| 41 | + > by clients. Errcode: `M_BAD_JSON`. |
| 42 | +* `m.push_rules` and `m.fully_read` should be rejected for both global and room |
| 43 | + account data. |
| 44 | +* Reading `m.push_rules` and `m.fully_read` should be allowed (although note that |
| 45 | + currently `m.push_rules` only makes sense for global account data and `m.fully_read` |
| 46 | + only makes sense for room account data). The format should match what is currently |
| 47 | + [returned via `/sync`](https://spec.matrix.org/v1.6/client-server-api/#push-rules-events). |
| 48 | + |
| 49 | +The above rules shall also apply when deleting account data if [MSC3391](https://github.com/matrix-org/matrix-spec-proposals/pull/3391) |
| 50 | +is merged before this MSC. |
| 51 | + |
| 52 | +## Potential issues |
| 53 | + |
| 54 | +It is possible that a client is currently storing data in the `m.push_rules` |
| 55 | +(or global `m.fully_read`) account data. After this change it could no longer |
| 56 | +be updated, deleted, or retrieved. It seems unlikely that the data stored here |
| 57 | +is done purposefully (and is likely the result of undefined behavior that this |
| 58 | +MSC is attempting to fix). |
| 59 | + |
| 60 | +## Alternatives |
| 61 | + |
| 62 | +An alternative would be to remove the current push rules API and have clients |
| 63 | +store all push rules in bulk. This would be subject to race conditions between |
| 64 | +clients. |
| 65 | + |
| 66 | +A slight variation of the above would be to *additionally* define the `/account_data/m.push_rules` |
| 67 | +endpoint as bulk modifying the push rules data. This could be seen as an alternative |
| 68 | +to [MSC3934](https://github.com/matrix-org/matrix-spec-proposals/pull/3934). |
| 69 | + |
| 70 | +## Security considerations |
| 71 | + |
| 72 | +None foreseen. |
| 73 | + |
| 74 | +## Unstable prefix |
| 75 | + |
| 76 | +This is mostly clarifications and does not add any event types or new endpoints. |
| 77 | + |
| 78 | +## Dependencies |
| 79 | + |
| 80 | +N/A |
0 commit comments