MSC4119: Voluntary content flagging #4119
Conversation
There was a problem hiding this comment.
Implementation requirements:
- Client sends context events per MSC
- Client reacts to context events in an intelligent way (doesn't just require a single event before minimizing - at least 2 should be required ;)
| * If a "trusted" user flags content, the client applies the above actions immediately without waiting | ||
| for further confirmation. If the sender is partially trusted, the client may require a couple more | ||
| confirmations before actually minimizing the content. "Trusted" has a range of values: | ||
|
|
||
| * Untrusted - default value. | ||
| * Partially trusted - sender has a DM with the user. | ||
| * Trusted - user has explicitly listed the sender as a trusted person, or has cross-sign verified | ||
| the user. |
There was a problem hiding this comment.
Can we make it clear that this is an example of how to define a trusted user? Since that needs to be completely subjective. And it really shouldn't be based on having a DM or cross signing with them, since you have those already with people you don't trust. (for example, you can have DMs with people who you are explaining a ban to, or they just might not be very nice).
This is something that is way out of scope for this MSC and can't be bodged in on the side
| @@ -0,0 +1,114 @@ | |||
| # MSC4119: Voluntary content flagging | |||
There was a problem hiding this comment.
I wonder if this could be worded better? "Voluntary content flagging" sounds more like content warnings/content notices and spoilers.
There was a problem hiding this comment.
Suggestions are welcome. There is an amount of that in here as well.
| @@ -0,0 +1,114 @@ | |||
| # MSC4119: Voluntary content flagging | |||
There was a problem hiding this comment.
What was the design process behind this proposal? Was there research done to make sure that the proposal solves problems users have and does so in an adequate way? Was any research conducted on prior art? This RFC mentions Twitter community notes as a future extension, but it would be interesting to also mention Discourse's community flagging feature.
There was a problem hiding this comment.
This proposal is part of the design process: all MSCs are evaluated for usefulness as part of regular review, and can be accepted or rejected accordingly later in the process.
The history here is someone brought up a concern in the spec room about being able to hide reported content in their clients, but the spec obviously doesn't have that feature right now. It was realized that my half-written community notes MSC could be tweaked a bit to serve the purpose, and so I did that and opened it.
As this proposal is early in the review process, more research is certainly required. It starts with community notes because that was most familiar, but an evaluation of Discourse's community flagging feature would be good as well. I suspect that it'd still be kicked to a future MSC though.
| * If a "trusted" user flags content, the client applies the above actions immediately without waiting | ||
| for further confirmation. If the sender is partially trusted, the client may require a couple more | ||
| confirmations before actually minimizing the content. "Trusted" has a range of values: | ||
|
|
There was a problem hiding this comment.
IMO it would make sense to recommend that clients hide all messages sent by the respective person.
Rendered
In line with matrix-org/matrix-spec#1700, the following disclosure applies:
I am Director of Standards Development at The Matrix.org Foundation C.I.C., Matrix Spec Core Team (SCT) member, employed by Element, and operate the t2bot.io service. This proposal is written and published under my Element hat as a member of the Trust & Safety team, allocated to the Foundation.