Server wide anti-spam and moderation tools and documentation

[erikjohnston]

Administrating a public Synapse instance with registration turned on can be quite labour intensive if spammers decide to try and attack it. We have some tooling for this, but it's a) quite immature and b) relatively undocumented.

Ideally, we'd have a document that lays out best practice for running an open Synapse instance with a play book with what to do if spammers strike.

This could include:

• consider using a captcha
• consider requiring an email, and potentially ban known temporary email providers.
• adding support for [Idea] User permissions on a server #7731, where permissions are lowered for new users
• adding better tooling around the new (and undocumented) shadow banning functionality
• adding registration approval that can be temporarily (or permanently turned on) Registration approval and new user moderation #6911
• ... and more

[richvdh]

worth noting that https://matrix.org/docs/guides/moderation covers a bunch of these topics, and I'd encourage people facing abuse problems to familiarise themselves with that document as a starting point.

That's not to say that better documentation and/or tooling wouldn't be useful.

[clokep]

We also did recently add the shadow-banning feature in v1.20.0, it is currently under-documented, however.

[DerRidda]

I have also discovered a limitation of the shadow banning feature; it is apparently only working for users that are registered to that server. I have a very concrete use case of a user evading bans by repeatedly creating new users on matrix.org and engaging on our server.

An approach that would also allow to ban users from other servers by operating on the event level is needed to really make that feature work, otherwise the backdoor is huge and wide open for any publicly federated servers.

[hex-m]

Another possible measure: "invite codes" instead of open registration. https://github.com/matrix-org/matrix-doc/issues/518