-
Notifications
You must be signed in to change notification settings - Fork 385
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
base: main
Are you sure you want to change the base?
Changes from 4 commits
3ea10a8
bdf19d8
843ffdd
7c2ed08
1250b1c
9975438
7b1c318
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
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
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I tested redacting a membership event - importantly, while |
||
|
||
## 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: | ||
|
||
##### `"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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 thehidden
level in #4179, but there is no equivalent of thespoiler
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)
There was a problem hiding this comment.
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