MSC4179: Moderation event hiding #4179
Conversation
tranquillity-codes
changed the title
| 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. |
There was a problem hiding this comment.
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.
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.
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.
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.
There was a problem hiding this comment.
Having a comparison to #3531 would be appreciated.
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
Both have been noted in the MSC contents now
turt2live
added
proposal
|
When you get a chance, please sign off on your changes so this MSC is eligible for inclusion in the spec. |
|
Based on If you agree to this for your contribution, then all that's needed is to include the line in your commit or pull request comment: Signed-off-by: Tranquil Ity [email protected] |
|
Notice: I'll probably have to rework this due to not being able to figure out a way to handle this properly without introducing a new room version, so I'll redo it with a new room version (auth rules adjustment). Unsure whether I should edit this MSC or make a new one. This could still be fixed up, but it'd have limited usability as-is (due to only being able to be present when the membership event is sent, and being stripped if the membership event gets redacted). It's primarily oriented at displayname hiding, so I am thinking of introducing an |
Rendered