MSC4205: Hashed moderation policy entities

[Gnuxie]

Rendered

Implementations:

• Meowlnir: Add support for MSC4204 and MSC4205 maunium/meowlnir#4
• matrix-protection-suite: Add support for MSC4204 (takedown) and MSC4205 (hashed entities) Gnuxie/matrix-protection-suite#88
• Draupnir: Support for room policies with hashed entity and org.matrix.msc4204.takedown recommendation in Synapse the-draupnir-project/Draupnir#761
  • Example protection: Add BlockInvitationOnServer protection. the-draupnir-project/Draupnir#777

Signed-off-by: Gnuxie Gnuxie@protonmail.com

[turt2live]

Implementation requirements:

• Client sending hashes
• Client using hashes

[tulir]

Many places in matrix use url-safe and/or unpadded base64, so if this is standard, it should probably be mentioned explicitly

[deepbluev7]

I think these events should have a distinct event type. Otherwise parsing the event is dependent on the recommendation, which both excludes ban recommendations from being hashed as well as makes parsing of events harder and technically is a backwards incompatible change. Something like m.hashed_policy.rule.user or similar could work for example.

[Gnuxie]

So, from my perspective there are policies in the wild that exist with omitted fields already, including the entity field. These were created by the now unmaintained spam police bot in an attempt to keep the context for a policy after unbanning a user.

The omission of entity, and the addition of the unstable hashes property, under the stable m.policy.rule.room, has not to my knowledge produced any significant problems for clients that have naive parsing of policy rules. Issues have also not yet been reported in implementation. But maybe there should be a requirement for a client to implement specific rendering for takedowns (gomuks might already) so that we can be sure.