# MSC4119: Voluntary content flagging

When a user on Matrix sends content which violates a room's code of conduct or a server's terms of
service, other users often [report](https://spec.matrix.org/v1.9/client-server-api/#reporting-content)
the event to expediate its removal. Clients typically offer to [ignore](https://spec.matrix.org/v1.9/client-server-api/#ignoring-users)
the sender as well, preventing further events from being shown to the reporter.

Most server implementations of the existing reporting system simply send the report to the server
administrators rather than the accused sender's server or applicable room moderators. This can lead
to some delay in the content being taken down, particularly when it is federated from a non-local
server. This proposal leaves improving the reporting communication line to another MSC, but does aim
to address expediated content removal where it's obvious that the content is against the rules.

With this MSC, when a user reports content they *should* be presented with an option to disclose to
the room that they submitted a report. Ideally, these disclosures would protect the sender's identity
to avoid targeted abuse, but for now this is left to a future MSC. Contributors for such a feature
should consider revealing the sender's identity to moderators to reduce abuse of the system.

This MSC's proposed system can additionally be expanded to social media use cases, similar to Twitter's
[Community Notes](https://en.wikipedia.org/wiki/Community_Notes) feature. For now, the added context
from this MSC is rather mechanical to suggest that other clients hide or blur the content.

## Proposal

Mentioned in the introduction, when a user reports content, their client should offer them an ability
to disclose to the room that a report was submitted. This is done by sending an `m.room.context` event
into the room, referencing the reported content. Clients may wish to consider requiring the user to
ignore the event sender as well, preventing retaliation until anonymous event sending is possible.

An `m.room.context` event looks similar to the following:

```jsonc
{
  // unused fields elided
  "type": "m.room.context",
  "content": {
    "m.relates_to": {
      "event_id": "$reported",
      "rel_type": "m.reference"
    },
    "m.flags": [
      // Flags are borrowed from MSC0001: Report reasons
      // TODO: Publish MSC0001
      "m.spam",
      "org.example.custom"
    ]
  }
}
```

`m.relates_to` is a standard [reference relation](https://spec.matrix.org/v1.9/client-server-api/#reference-relations)
to the reported event, or event which is getting context appended to it. `m.flags` acts as an
[Extensible Events Content Block](https://github.com/matrix-org/matrix-spec-proposals/blob/main/proposals/1767-extensible-events.md)
to allow for future expansion of the event, such as including text context akin to a Twitter Community
Note.

Clients can then make decisions based on the `m.room.context` events it sees. How the client processes
these data points is left as an implementation detail, though a suggested approach is:

* If several people append the same flag to an event, the event should be minimized or have a click
  barrier to prevent the content from being immediately accessible. The sender's avatar should additionally
  be blurred, and display name/user ID hidden if possible. "Several" may be defined as a percentage
  of room members in small-medium sized rooms, or 10+ senders in larger rooms.
* 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.

Through use of a future MSC, clients may also incorporate feedback about an `m.room.context` event
into their decision tree for when to minimize content. For example, poorly rated context events reduce
the chances of content being minimized.

Clients SHOULD NOT send `m.room.context` events until after a `/report` is sent. This is to ensure
that the content is at least reported to someone, and is more applicable when a revamped reporting
system is in place.

## Potential issues

As previously mentioned, this approach discloses who reported who to the whole room. While this is
helpful for other users to minimize content, it can result in targeted abuse or retaliation towards
the reporter. Clients are strongly encouraged to require the user to [ignore](https://spec.matrix.org/v1.9/client-server-api/#ignoring-users)
who they report to prevent the spread of the targeted abuse. In future, an MSC should be written to
permit anonymous events, thus hiding the sender. To prevent abuse of the system (ie: constantly flagging
everyone's events), senders should be disclosed to moderators but not other members of the room, if
possible. Note that this has its own privacy concerns, such as moderators (un)intentionally revealing
who is reporting who to non-moderators, thus resulting in targeted abuse again.

## Alternatives

[MSC3531](https://github.com/matrix-org/matrix-spec-proposals/pull/3531) is currently the major
alternative, though requires moderators to identify the content before the (typically) larger community
does.

Another alternative may be to expand [policy lists](https://spec.matrix.org/v1.9/client-server-api/#moderation-policy-lists)
to include event IDs, thus allowing clients (and users) to subscribe to "feeds" from trusted sources
and hide/minimize content accordingly.

## Security considerations

See potential issues. There are privacy concerns here.

## Unstable prefix

While this proposal is not considered stable, implementations should use `org.matrix.msc4119.room.context`
and `org.matrix.msc4119.flags` over the stable identifiers.

## Dependencies

This MSC has a soft dependency on MSC0001: Report reasons.
// TODO: Publish MSC0001