[New in this version]
m.room.member events now keep join_authorised_via_users_server
in addition to other keys in content when being redacted.
Without the join_authorised_via_users_server property, redacted join events
can become invalid when verifying the auth chain of a given event, thus creating
a split-brain scenario where the user is able to speak from one server’s
perspective but most others will continually reject their events.
This can theoretically be worked around with a rejoin to the room, being careful
not to use the faulty events as prev_events, though instead it is encouraged
to use v9 rooms over v8 rooms to outright avoid the situation.
Issue #3373 has further information.
The full redaction algorithm follows.
Upon receipt of a redaction event, the server must strip off any keys not in the following list:
event_idtyperoom_idsenderstate_keycontenthashessignaturesdepthprev_eventsprev_stateauth_eventsoriginorigin_server_tsmembership
The content object must also be stripped of all keys, unless it is one of one of the following event types:
m.room.memberallows keysmembership,join_authorised_via_users_server.m.room.createallows keycreator.m.room.join_rulesallows keysjoin_rule,allow.m.room.power_levelsallows keysban,events,events_default,kick,redact,state_default,users,users_default.m.room.history_visibilityallows keyhistory_visibility.