[FEATURE] Reporter reputation system

[CoralineAda]

All contributions, including pull requests, issues, and comments, are governed by our code of conduct.

Is your feature request related to a problem? Please describe.

We need to track a given account's reputation.

Desired solution

Create a reputation system for accounts. Reputation is influenced by:

• Number of dismissed reports over a given threshold
• Incidence of 404 and 302 errors triggered (indicates suspicious activity)
• Traffic origin (Tor exit nodes and proxies)
• Account hits a maximum limit for certain activities (# submitted reports, # abuse reports submitted for example)? Not sure on this one.
• Other factors?

[CoralineAda]

Dependent on #132

[noahgibbs]

This description suggests to me that you're eventually going to want an Event Sourcing-style model for this data, and it's probably worth planning for up front.

Specifically, you're going to wind up including information from other known entities (users, moderators, subjects of reports) in the reputation score at some point, because how could you not? And the reputation of those known entities is going to be relevant (e.g. don't downgrade reputation based on mass anonymous reports, stop counting reports from a moderator you've had to dismiss.)

It's not impossible to formulate a huge matrix algorithm to do this based on all your current estimates of everybody's reliability and fully take the present knowledge into account. That's how Google would do it. But it's much easier to replay a stream of events and for each one, use what you currently know about all parties to re-score the effects of those events.

(If this sounds like an anti-brigading/mass-reporting tool, that's because this is also how you write those. The requirements on the data model are very similar.)

As a side effect, an Event-Sourcing-type architecture gives you a full audit trail for every activity you use it for, and make it much easier to separate read/append/write permissions on your data stores. It also gives you the ability to re-evaluate the event stream so errors in counters won't normally cost you information.

On the minus side, it's an uncommon app architecture and a bit of a pain to set up. You don't 100% have to do it with an event-sourcing-type tool (e.g. Kafka,) it's doable in a database. But no matter how you do it, it changes how you read and write all the relevant structures :-/ It can be done incrementally, but that only helps a bit.