Open richvdh opened 6 years ago
Related: matrix-org/matrix-spec-proposals#463
Somehow I managed to miss this when digging for event validation information :(
Given the validation rules are almost certainly going to need to be a rooms v2 thing, I think we should go a bit more strongly down the path of validation. In general, the things listed to be considered in the draft seem sensible. I only have a few specific concerns:
creator
on create events: https://github.com/matrix-org/matrix-doc/issues/1193content
of the event - can we get away with using the content hash instead of relying on the content
field? My concern is that float data is useful in IoT and similar scenarios, and the devices parsing the floating points are likely to be aware of the troubles in doing so.
content
. On the point of figuring out how to handle invalid events, considering they would have already gone through the auth rules I don't think it's a good idea to reject them outright at the validation step. If the event is permitted to be in the room, then we should allow it to be there. That being said, servers should consider a soft failure approach to prevent badly formatted events from making it down to clients.
As a more minor point, the spec should clarify how events are meant to flow through the various algorithms. It's not entirely clear if validation is done before or after the auth rules, for instance.
To answer the question of "what about v1 rooms?", I think we should just say there that validation should be relaxed and only applied where it strictly applies (ie: use if membership == "join"
rather than if membership not in [kick, ban, leave, join]
).
see also matrix-org/matrix-spec#504
schema compliance:
whether it has all the required fields listed at matrix.org/docs/spec/server_server/unstable.html#persistent-data-unit-schema
- whether those fields (and the optional ones) have the expected types, and match the relevant grammars, including length limits
Note that the expectations here are sensitive to the room version in play; see #1044 #1045.
whether it has all the required fields listed at https://matrix.org/docs/spec/server_server/unstable.html#persistent-data-unit-schema
Doesn't seem to be enforced (fully) by any server implementation, see #1904
We should clearly specify how to validate an event that has been received over federation, and how the receiving server should behave when validation fails.
The sorts of things we should consider checking include:
content.membership
is a known valuestate_key
, depending on its event typeorigin
matches the sender sending the event, for pushed transactions.sender
andevent_id
match theorigin
(except for join events)creator
on a create event matches thesender
and theroom_id
prev_events
Parts of this list overlap with the rules already set out for Authorization of PDUs.
Synapse currently checks many, but not all, of the things on this list, so there may well be rooms in existence which do not conform. Starting to check them now is problematic in that it may prevent servers from participating in those existing rooms. We should therefore consider whether it is reasonable to apply any additional checks now, or which should wait for a future room version.
We should also define the behaviour when a validation check is not met: should we ignore such events, or reject incoming pushes? For pulls, should we try to get the events from elsewhere?