MSC3531: Letting moderators hide messages pending moderation

[Yoric]

Rendered

Preview: https://pr3531--matrix-org-previews.netlify.app

[turt2live]

A bot hosted by who? Does the visibility of the content really change the liability?

[Yoric]

No, it's the expunge part that would change the liability. Rephrasing.

[piegamesde]

I'm a bit baffled by the fact nobody talks about users hiding their own messages. (Or maybe it is implied by the implementation of the mechanism and I missed it, in that case I'd like to have it noted explicitly). There are a few valid use cases to hide own messages and I see no reason to limit this to moderators only. For reference, GitHub has a pretty good message hiding feature.

Speaking of GitHub, they enumerate the following possible reasons for hiding a message: Spam, Abuse, Off Topic, Outdated, Duplicate, Resolved. I'd suggest putting most of these as "presets" while allowing custom fields as well (this also rises the question about translation btw).

[uhoreg]

Can you explain what would be the use case for a user hiding their own message, that isn't already covered by users redacting their own message (if the user sent a message but doesn't want it shown any more), or using the <details> tag (if the user sends a long message that they don't want to take a lot of space unless someone is interested in reading the whole thing)?

[piegamesde]

This would be useful in cases where the user wants to retract a message without redacting it, so that it can still be read by others. A common usage for this on GitHub is to mark messages as resolved.

More generally though, this is about symmetry: users can redact their messages, moderators can redact others' messages. If moderators can hide others' messages, why should users not be able to hide their own?

[Yoric]

I like the idea a lot.

The main difficulty is that it introduces a few corner cases that are a bit tougher to specify:

• can a moderator show a message hidden by a user?
• how do you specify interactions between a moderator showing/hiding, a user showing/hiding and redacting the messages between the visibility change messages?

For the time being, I'd probably prefer leaving the MSC as is and introducing self-hiding as a followup.

Clarifying this position in Alternatives.

[kevincox]

IIUC this won't prevent hidden messages from being seen by non-moderator users. It will just provide enough information such that clients may hide them. Basically this does not hide messages from a motivated non-moderator user but it is expected that cooperative clients don't see the messages (once they are aware of the hiding).

[turt2live]

These two fields should not be part of the relation - they should be under the event content.

[kegsay]

This is too confusing with the existing m.history_visibility as client code inevitably just refers to "visibility: e.g JS SDK has:

• MAX_NUMBER_OF_VISIBILITY_EVENTS_TO_SCAN_THROUGH
• this.visibilityEvents
• EVENT_VISIBILITY_CHANGE_TYPE

All of which the average developer would expect this to be https://spec.matrix.org/latest/client-server-api/#room-history-visibility - please change your terminology to avoid confusing developers. Possible suggestions of non-overloaded terms:

• hidden
• invisible
• quarantine (though has some overlap with Synapse I think)
• pending_review
• flagged
• pending_moderation

[kegsay]

Without server changes, this feels very half-baked because it's just a best-effort hiding process. This may be unacceptable to users and create a bad UX if I hide my sensitive message only to realise later that it's visible to other users because they aren't using Element. That being said, basically any kind of hiding process like this is basically impossible to guarantee, like unsending emails, it's just whether or not this will occur frequently enough to impact users experience or not.

[kegsay]

I have no idea why this doesn't mention what I see is the obvious solution here: make them state events. E.g:

{
    type: "m.pending_moderation",
    state_key: "@user-who-wants-to-moderate",
    content: {
        hidden: [ "$aaa", "$bbb", "$ccc" ]
    }
}

This has numerous benefits over having them as state events:

• You are guaranteed to get all the event IDs which need to be moderated. At present not only can you miss some if you don't scrollback enough, it also just doesn't work reliably over federation because the server will not be requesting all of these visibility events.
• You can apply power level checks to the user who sent the state event to ensure they are authorised to hide the events, as with this MSC.
• You open up the ability for users to hide their own messages by letting them use their own user ID in the state_key.
• Once a decision has been made, just remove the event ID from the array.
• Avoids race conditions with setting events as hidden - the presence of the event ID in any valid state event means it is hidden, though perhaps for different reasons.

I haven't fully thought this through, but it seems to be a more expressive and reliable solution to this problem that this proposal. Please add it to the Alternatives section.

[deepbluev7]

I think this could use an explicit mention, that this is NOT sent as a state event, even though the power level check to apply it uses a state event PL. Tbh, I would probably prefer to introduce a top level powerlevel like for redactions for this, since this would be quite irregular otherwise.

[carlbordum]

I am not commenting on the proposed solution, but want to chime in with another motivation for this. For Cactus Comments a common request is the ability to "approve" comments before they are showed on a users website. It would be great if this use case could be kept in mind.