[Story] As a protection developer I can query a given mxid for a simple interval metric describing their level of participation in the community

[Gnuxie]

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

• 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.

Tasks

• [Task] Develop the participation metric #43

Issues

• Determining the relative duration of stay for members in the protected rooms set as a metric for protections Draupnir#466

[Gnuxie]

I don't know how many levels would make sense: but my more recent thoughts are like this:

Level 0: User has been encountered in the community, has no capability to do anything, and is consequently sent a welcome, faq coc etc. (They are given an allow list of emoji possibly so they can interact with the notice) (This is the most extreme level of protection for a community and can be skipped)
Level 1: User has acknowledged the welcome notice and is granted initial capabilities to interact with the community (they can send basic messages, write in threads, replies). Again expressed as capabilities they are allowed to use rather than not allowed. Embedded keys in events are restricted
Level 2: User's initial messages (the messages that qualify as "interaction" are also derived from an allowlist) have been seen by a moderator AND active community members. Capabilities are expanded to allow sending messages containing media under scrutiny and global media rate limit. (mentions, images, links all count to the same limit).
Level 3: User has sent a sufficient number of messages containing media that have been viewed by a moderator AND active community members. They no longer need to be watched as closely. Optionally disable safe guards.
Level 4: User is considered to be integral to the community and may use redact/report commands to clean up events from level 2 users and below.

[Gnuxie]

We can derive moderator "acknowledgement" of messages from when they send their own messages... not their read recipts.

For the welcome / acknowldgement / warning of users, it probably makes sense to have a DM with the user that they have to keep open or they get reset to level 0. Otherwise we will just have to send warnings directly into matrix rooms.

Works great for advertisement too i guess as an aside x3

[Gnuxie]

See https://marewolf.me/posts/draupnir/25/02.html#priorities-a-focus-on-on-boarding-users for the latest thought on this

[Gnuxie]

Some exploratory work was conducted here the-draupnir-project/Draupnir@main...gnuxie/user-familiarity. This work was suspended with project hydra being announced and the scope of the persistent store required to support the feature became increasingly complex. Particularly in interactions with the appservice mode of deploying Draupnir. To alleviate these concerns and to make persistent storage generic to Draupnir's revision system, the following was proposed: #69.