You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
matrix-spec/content/client-server-api/modules/moderation_policies.md

111 lines
4.7 KiB
Markdown

### Moderation policy lists
With Matrix being an open network where anyone can participate, a very
wide range of content exists and it is important that users are
empowered to select which content they wish to see, and which content
they wish to block. By extension, room moderators and server admins
should also be able to select which content they do not wish to host in
their rooms and servers.
The protocol's position on this is one of neutrality: it should not be
deciding what content is undesirable for any particular entity and
should instead be empowering those entities to make their own decisions.
As such, a generic framework for communicating "moderation policy lists"
or "moderation policy rooms" is described. Note that this module only
describes the data structures and not how they should be interpreting:
the entity making the decisions on filtering is best positioned to
interpret the rules how it sees fit.
Moderation policy lists are stored as room state events. There are no
restrictions on how the rooms can be configured (they could be public,
private, encrypted, etc).
There are currently 3 kinds of entities which can be affected by rules:
`user`, `server`, and `room`. All 3 are described with
`m.policy.rule.<kind>` state events. The `state_key` for a policy rule
is an arbitrary string decided by the sender of the rule.
Rules contain recommendations and reasons for the rule existing. The
`reason` is a human-readable string which describes the
`recommendation`. Currently only one recommendation, `m.ban`, is
specified.
#### `m.ban` recommendation
When this recommendation is used, the entities affected by the rule
should be banned from participation where possible. The enforcement of
this is deliberately left as an implementation detail to avoid the
protocol imposing its opinion on how the policy list is to be
interpreted. However, a suggestion for a simple implementation is as
follows:
- Is a `user` rule...
- Applied to a user: The user should be added to the subscriber's
ignore list.
- Applied to a room: The user should be banned from the room
(either on sight or immediately).
- Applied to a server: The user should not be allowed to send
invites to users on the server.
- Is a `room` rule...
- Applied to a user: The user should leave the room and not join
it
([MSC2270](https://github.com/matrix-org/matrix-spec-proposals/pull/2270)-style
ignore).
- Applied to a room: No-op because a room cannot ban itself.
- Applied to a server: The server should prevent users from
joining the room and from receiving invites to it.
- Is a `server` rule...
- Applied to a user: The user should not receive events or invites
from the server.
- Applied to a room: The server is added as a denied server in the
ACLs.
- Applied to a server: The subscriber should avoid federating with
the server as much as possible by blocking invites from the
server and not sending traffic unless strictly required (no
outbound invites).
#### Subscribing to policy lists
This is deliberately left as an implementation detail. For
implementations using the Client-Server API, this could be as easy as
joining or peeking the room. Joining or peeking is not required,
however: an implementation could poll for updates or use a different
technique for receiving updates to the policy's rules.
#### Events
The `entity` described by the state events is interpreted as a
[glob-style pattern](/appendices#glob-style-matching). Note that
rules against rooms can describe a room ID or room alias - the
subscriber is responsible for resolving the alias to a room ID if
desired.
{{% event event="m.policy.rule.user" %}}
{{% event event="m.policy.rule.room" %}}
{{% event event="m.policy.rule.server" %}}
#### Client behaviour
As described above, the client behaviour is deliberately left undefined.
#### Server behaviour
Servers have no additional requirements placed on them by this module.
#### Security considerations
This module could be used to build a system of shared blacklists, which
may create a divide within established communities if not carefully
deployed. This may well not be a suitable solution for all communities.
Depending on how implementations handle subscriptions, user IDs may be
linked to policy lists and therefore expose the views of that user. For
example, a client implementation which joins the user to the policy room
would expose the user's ID to observers of the policy room. In future,
[MSC1228](https://github.com/matrix-org/matrix-spec-proposals/pulls/1228) and
[MSC1777](https://github.com/matrix-org/matrix-spec-proposals/pulls/1777) (or
similar) could help solve this concern.