Bulk moderation API

[erkinalp]

Description

Add an API for mass moderation of any kind of group chat on Discord: guilds, lobbies and group channels.

Why This is Needed

Automoderation bots on Discord currently relying on subscribing to messages and reading them as posted. This requires trusting those bots. In addition, developers of some bots, such as MEE6, refrain from transistioning to new interaction API as they need to read messages anyway.

Alternatives Considered

A specific user or bot, approving all events before it gets propagated to other users. This is disconsidered because this has the very problem that this proposal intends to solve. And this would also create a single-point-of-failure for communities, making them more dependent on bots than they currently are.

Additional Details

The moderation API should allow those at a minimum:
*Server-side pattern matching for white- and blacklisting: This would be useful for copyright and plagiarism filters. Those patterns can either be uploaded by users or pre-prepared by Discord. The resulting API design should allow for both types of filters.
*Ability to flag particular messages to be good or bad to be considered in moderation of newer messages.
*Confidence scoring system for pattern matchers, so we can tune the sensitivity of the pattern-matching automoderator for various surrounding contexts.
*Pre-moderation ability. (satisfied by #4860)
*Ability to subject different user groups (a list of singular users and/or roles) to different moderation policies. (satisfied by #4860)

[john-bv]

I feel like this would be more a burden rather than a nice feature. Any filter system would rely on message events either way and your proposal could potentially cause extra latency when sending messages. The only thing I like about what you’re suggesting is the ability to subscribe to a user specific event, however even this is already doable with the current system with some simple checking.
(I only am commenting for the filter api)

[erkinalp]

Any filter system would rely on message events either way and your proposal could potentially cause extra latency when sending messages. The only thing I like about what you’re suggesting is the ability to subscribe to a user specific event

You misunderstood my proposal. In my proposal, the filtering would be applied server-side before the event gets propagated to any other users. So, it would appear perfectly transparent to users, no remove/edit message events will be generated out of such moderation.

[erkinalp]

This suddenly became useful again, with upcoming restriction of message reads of bots.

[MrAugu]

As a moderation bot developer, I do not think this is doable nor it's worth the overhead of such API because, at the end of the day, moderation relies on the messages and I feel like this would be more of a burdening punch in the face for such bots rather than helpful feature.

[msciotti]

For the sake of pure moderation, stopping events before they get sent to other users is definitely better than retroactively deleting them. However, that sort of "man in the middle" architecture is not something that Discord currently or plans to support. It would be a major change to our architecture, and would frankly be a huge load burden on someone implementing it to keep latency low at the scale at which Discord operates.

[erkinalp]

keep latency low at the scale at which Discord operates.

You could provide a per-guild/per-DM toggle to choose between high latency with accurate premoderation and low latency with postmoderation.