Almost all existing protections use a very crude way of determining how long a user has been participating in a community and then discriminating against newer users. The current method involves watching for new joiners in a given protected room since the startup of the bot (there's no persistence), and cannot consider the user's participation in the rest of the protected rooms. This not only leads to lots of false positives, but is also easy to evade and cannot be configured.
By deriving a simple interval rating for each user in the community we can not only reduce the number of false positives and improve the consistency of the protection, but the metric will also be easy to understand and can be configurable as a simple threshold. Changing the level is also simple for a metric that only has 5 different values.
Acceptance Criteria
The range of values for the metric is no more than 0-5.
The metric is not based on how long a user has been present in the ProtectedRoomsSet, but is instead based on participation (for example whether they have sent a message in each ordinal interval of time that maps back to the metric).
This is to increase the chances that the user has been "seen" by a moderator and the rest of the community so they are more likely to have a feel for the user and know that they are not just a bot or brigade or something.
All existing protections that discriminate against new joiners should be reworked to use the metric instead of their existing adhoc systems.
Description
Almost all existing protections use a very crude way of determining how long a user has been participating in a community and then discriminating against newer users. The current method involves watching for new joiners in a given protected room since the startup of the bot (there's no persistence), and cannot consider the user's participation in the rest of the protected rooms. This not only leads to lots of false positives, but is also easy to evade and cannot be configured.
By deriving a simple interval rating for each user in the community we can not only reduce the number of false positives and improve the consistency of the protection, but the metric will also be easy to understand and can be configurable as a simple threshold. Changing the level is also simple for a metric that only has 5 different values.
Acceptance Criteria
ProtectedRoomsSet, but is instead based on participation (for example whether they have sent a message in each ordinal interval of time that maps back to the metric). This is to increase the chances that the user has been "seen" by a moderator and the rest of the community so they are more likely to have a feel for the user and know that they are not just a bot or brigade or something.Issues