MSC4206: Moderation policy auditing and context

[Gnuxie]

Rendered

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

[turt2live]

Implementation requirements:

• Client sending context
• Client using context

[Johennes]

If m.policy.rule.context is also meant to be a state event, existing chat clients might not be able to render the context thread as they likely won't support threading on state events. This might not be a terrible problem other than being able to browse context rooms from a non-specialized client possibly being convenient.

[tulir]

The state key should also be defined if it's meant to be a state event (I'd assume it should copy the policy event's state key)

[Johennes]

Could it be expensive to find existing events in large policy lists given that you have to scan content on every context event? The bot could possibly work around that by keeping its own index.

[Gnuxie]

For providing context to moderation policies with hashed entities it will be desirable to include the plain text entity in the context. This is so that the moderators of a common policy list (such as CME) can verify in advance what entity the policy is targeting before they "encounter" the entity themselves and unmask it. This is to reduce the effects of mistakes where the wrong entity is entered into a list, or are masked for malicious purposes in otherwise collaborative environments.

[tulir]

This current flow would require 4 events: the policy itself, policy context root, start notice, actual context message(s)

I think it'd be better to attach an initial message into the context root itself (like a reason field) and create a thread later if discussion or additional info like images are necessary. I'd assume in most cases, moderators will just want to !neighnir ban @yarrgh:example.com <private context here>

[tulir]

The state key should also be defined if it's meant to be a state event (I'd assume it should copy the policy event's state key)