Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MSC4179: Moderation event hiding #4179

Draft
wants to merge 7 commits into
base: main
Choose a base branch
from
47 changes: 47 additions & 0 deletions proposals/4179-moderation-hidden.md
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Having a comparison to #3531 would be appreciated.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Based on a quick look, the differences I noticed:
The motivation is different. #3531 is primarily for hiding message events pending moderation, while #4179 is for hiding state events that have already happened but include content that one might not wish to be visible (such as a user with an offensive MXID getting banned)
#3531 is less granular. Its visibility: hidden corresponds to the hidden level in #4179, but there is no equivalent of the spoiler level. Additionally, #3531 uses a free-form string, which cannot be automatically matched on by a client, while #4179 uses a tag list (allowing someone to customize what events they are okay with seeing, and allowing optional fine-grained control over the completeness vs safety of room history per-client)
#3531 requires the sending of a separate event, while #4179 has no such race condition, plus piggy-backs off of edit events for changing the state.

I will note this down in the MSC (and should probably mention that it should support edits, unsure if it requires a mention or not)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Both have been noted in the MSC contents now

Original file line number Diff line number Diff line change
@@ -0,0 +1,47 @@
## Motivation
When an account with an offensive profile (profile picture, username...) is removed from a room,
many clients will render the profile with a message such as "<offensive name> was banned".
This essentially cements the string in the room history.
Comment on lines +2 to +4
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Redactions are intended to solve this, removing the display name details from the event. This can leave the user ID exposed though, which is not redactable.

Sending clients can also (arguably) decide to not send the display name.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am unsure I follow, redacting what exactly ? A ban is rendered by Element, and membership writes are non-redactable. The display name is included in the membership state but is only a part of the problem as the mxid could also be problematic.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Membership events are redactable because the profile information is there. The profile information is not critical to the protocol and can be redacted safely.

The user ID part is a bit more of a concern though, yes.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tested redacting a membership event - importantly, while content was stripped outside of membership, prev_content was left untouched, and as an example, Element renders prev_content even if content has been stripped.


## Proposal
Add a top-level `m.moderation_hidden` key to the content of an event. The format is as follows:
```
{
"level": <level:string>,
"tags": <tags:[string]>
}
```

`<level:string>` is a string referring to the *level* of percieved need to hide the event. Valid keys are:

Check warning on line 15 in proposals/4179-moderation-hidden.md

View workflow job for this annotation

GitHub Actions / Spell Check with Typos

"percieved" should be "perceived".

##### `"spoiler"`
Show the event's presence, but hide its contents.

##### `"hidden"`
Hide it by default, display for moderators and client debug views.

Tags is a list of strings representing content warnings that ought to be applied to the event.
Clients can choose to match on the tag list when deciding how to interpret the event.

Example:
```json
{
"level": "spoiler",
"tags": ["nsfw"]
}
```

## Client implementation
A client should offer a three-state option in its settings about the interpretation of the hints.
- Respect the hints
- Treat `hidden` as `spoiler`
- Ignore the hints

## Unstable prefix
Use `org.itycodes.msc4179.moderation_hidden` in place of `m.moderation_hidden`.

## Further work
Standardizing the list of tags

## Security implications
None known
Loading