3.6 KiB
MSC4010: Push rules and account data
Push rules have a bespoke API
which clients use to retrieve, add, modify, and remove push rules. Any modifications
made using this API are sent to all clients via a m.push_rules
event in the
account_data
section in the
the next /sync
response.
The client-server API does not have any special behavior around using the
account data APIs
with the m.push_rules
type leading to different behavior on different homeservers:
- Synapse will accept the data and shadow the real push rules in
/sync
, but won't use the data when evaluating push rules. - Dendrite will return an HTTP 403 if you attempt to set
m.push_rules
via/account_data
. - Conduit has no protections for special account data. It will accept
m.push_rules
via/account_data
and use those when evaluating push rules.
The fully read marker
operates in a similar way and
servers must reject updating m.fully_read
via /account_data
.
Note that when attempting to set m.fully_read
via /account_data
the following
behavior is observed:
- Synapse will reject it with a 405 error (only for room account data).
- Dendrite will reject it with an HTTP 403 error.
Proposal
To make push rules data consistent with fully read markers, the following clarifications are offered:
-
The
m.push_rules
account data type becomes protected and cannot be set using the/account_data
API, similarly tom.fully_read
. -
"Rejected" means to use the 405 error response as documented:
This
type
of account data is controlled by the server; it cannot be modified by clients. Errcode:M_BAD_JSON
. -
m.push_rules
andm.fully_read
should be rejected for both global and room account data. -
Reading
m.push_rules
andm.fully_read
should be allowed (although note that currentlym.push_rules
only makes sense for global account data andm.fully_read
only makes sense for room account data). The format should match what is currently returned via/sync
.
The above rules shall also apply when deleting account data if MSC3391 is merged before this MSC.
Potential issues
It is possible that a client is currently storing data in the m.push_rules
(or global m.fully_read
) account data. After this change it could no longer
be updated, deleted, or retrieved. It seems unlikely that the data stored here
is done purposefully (and is likely the result of undefined behavior that this
MSC is attempting to fix).
Alternatives
An alternative would be to remove the current push rules API and have clients store all push rules in bulk. This would be subject to race conditions between clients.
A slight variation of the above would be to additionally define the /account_data/m.push_rules
endpoint as bulk modifying the push rules data. This could be seen as an alternative
to MSC3934.
Security considerations
None foreseen.
Unstable prefix
This is mostly clarifications and does not add any event types or new endpoints.
Dependencies
N/A