From 634af8e77a9c251dd37f73888a9f33b35a380b49 Mon Sep 17 00:00:00 2001 From: gnuxie Date: Wed, 12 Mar 2025 22:36:34 +0000 Subject: [PATCH 1/6] Initial version i guess. --- proposals/0000-approval-disapproval.md | 140 +++++++++++++++++++++++++ 1 file changed, 140 insertions(+) create mode 100644 proposals/0000-approval-disapproval.md diff --git a/proposals/0000-approval-disapproval.md b/proposals/0000-approval-disapproval.md new file mode 100644 index 00000000000..87edbefcc35 --- /dev/null +++ b/proposals/0000-approval-disapproval.md @@ -0,0 +1,140 @@ +# MSC0000: Approve and Disapprove ratings for moderation policies + +Currently, when watching a moderation policy list, there is no way to express +approval or disapproval of certain policies. + +Typically, Matrix moderation tooling requires that moderators accept all +policies within a moderation policy list in an all-or-nothing approach. We call +this profile of policy list subscription _direct propagation_: any policy that +appears on a watched list with _direct propagation_ semantics are directly +considered and actioned by tooling. Examples of this include Mjonlir & Draupnir. + +For example: `charity`, the moderator of `cat-community.example.com`, cannot +subscrbe to the list, `#bat-coc-bl:bat-community.example.org` without accepting +all of the existing policies. This is problematic because `charity`'s friend +`bob` was banned from the list for arguing with a moderator. `charity` respects +the ban in the bat community, but still needs to be able to interact with their +friend. + +Addtionaly, this all-or-nothing approach increases the amount of trust that +moderators place onto the curators of moderation policy lists. As watching a +list gives the list curators the ability to manage members within the +subscribing community. + +For example: `luna`, the moderator of `bat-community.example.com` notices that +`cat-community.example.com` is watching the list, and uses their power to ban +more of `charity`'s friends. + +These problems lead to situations where communities avoid watching other +moderation policy lists entirely, either because of a few policies that they +take issue with, or it is simply unsafe to do so because of the level of trust +placed on the curators of a list when watching them. + +## Proposal + +We introduce a new moderation policy meta rating event type, +`m.policy.rule.approval`. This policy exists purely for moderators to express +their approval or disapproval for policies in other lists. + +Content Schema: + +```yaml +properties: + rating: + description: |- + A binary rating of either string literals approve or disapprove. + type: string + enum: + - approve + - disapprove + event_id: + type: string + description: |- + The event ID of the moderation policy that this is a rating for. + example: "$some_event_id" +type: object +required: + - rating + - event_id +``` + +Example: + +```json +{ + "sender": "@luna:bat-community.example.com", + "type": "m.policy.rule.approval", + "content": { + "rating": "approve", + "event_id": "$wioefjwoijefo:example.com" + }, + "state_key": "lciRM4XTjq9bj3QMawAbXFH7pCRJEvft34ZmhGBNsxc=" +} +``` + +### Discussion + +These policies allow for moderation tools to develop _approval +only_[^approval-only] policy list subscription modes. Whereby policies are only +considered from a list when they have been approved by a moderator. Please note, +that due to the _lazy_ nature of matching, the workload on moderators for +approving policies when watching a list will be minimal[^minimal-workload]. + +Additionally, subscriptions that use _direct propagation_ can remove policies +from consideration that have been _disapproved_ by a moderator. + +[^approval-only]: https://github.com/the-draupnir-project/planning/issues/4 + +[^minimal-workload]: + They will only have to approve policies that are matching encountered + entities. For example, there is no need to approve a policy banning a user + that has not been encountered yet as they have not attempted to join any + known room. + +The examples given in this proposal have so far only considered the application +of these ratings to the room level. However In the future, if policy lists are +considered for consumption within clients for the purpose of blocking on a user +level, these ratings provide a fundamental primivive for a subjective +distributed reputation system. + +## Potential issues + +### Direct propagation of approval ratings + +If moderation tools implement the proposal naively, it's possible that approval +ratings themselves can be considered alongside normal moderation policies. For +example, `charity` is watching the list `#bat-coc-bl:bat-community.example.com` +curated by `luna` with a _direct propagation_ policy list subscription profile. +`charity` is also watching the list `#people-i-hate:bat-community.example.com` +with an _approval only_ subscription profile. `luna` notices this, and approves +policies from `#people-i-hate:bat-community.example.com` within the +`#bat-coc-bl:bat-community.example.com` list. If `charty`'s tooling naively +propagates the approval ratings, then their tool will enact policies from +`#people-i-hate:bat-community.example.com`. + +#### Mitigation + +To prevent this, implementations SHOULD use an allowlist of senders when +considering `m.policy.rule.approval` ratings by default, rather than the +specifics of a policy list subscription profile. + +## Alternatives + +### Local storage + +Approval ratings could be kept on local storage rather than in policy rooms. +However, this would reduce the potential for interoperation of different tools +and clients. + +## Security considerations + +See ptoential issues. + +## Unstable prefix + +The event type `m.policy.rule.approval` will use the unstable type +`org.matrix.msc0000.approval`. + +## Dependencies + +None From 5a1aa2585eb26db6861d5f589eb0df0b10d69abe Mon Sep 17 00:00:00 2001 From: gnuxie Date: Wed, 12 Mar 2025 22:43:15 +0000 Subject: [PATCH 2/6] MSC4273. --- ...0-approval-disapproval.md => 4273-approval-disapproval.md} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename proposals/{0000-approval-disapproval.md => 4273-approval-disapproval.md} (98%) diff --git a/proposals/0000-approval-disapproval.md b/proposals/4273-approval-disapproval.md similarity index 98% rename from proposals/0000-approval-disapproval.md rename to proposals/4273-approval-disapproval.md index 87edbefcc35..7c79139bd30 100644 --- a/proposals/0000-approval-disapproval.md +++ b/proposals/4273-approval-disapproval.md @@ -1,4 +1,4 @@ -# MSC0000: Approve and Disapprove ratings for moderation policies +# MSC4273: Approve and Disapprove ratings for moderation policies Currently, when watching a moderation policy list, there is no way to express approval or disapproval of certain policies. @@ -133,7 +133,7 @@ See ptoential issues. ## Unstable prefix The event type `m.policy.rule.approval` will use the unstable type -`org.matrix.msc0000.approval`. +`org.matrix.msc4273.approval`. ## Dependencies From 20518bd17911f7d5ac65253fc8f75ae24fb3bc76 Mon Sep 17 00:00:00 2001 From: gnuxie Date: Wed, 12 Mar 2025 22:50:51 +0000 Subject: [PATCH 3/6] typo --- proposals/4273-approval-disapproval.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/4273-approval-disapproval.md b/proposals/4273-approval-disapproval.md index 7c79139bd30..9ff117cb2d4 100644 --- a/proposals/4273-approval-disapproval.md +++ b/proposals/4273-approval-disapproval.md @@ -94,7 +94,7 @@ from consideration that have been _disapproved_ by a moderator. The examples given in this proposal have so far only considered the application of these ratings to the room level. However In the future, if policy lists are considered for consumption within clients for the purpose of blocking on a user -level, these ratings provide a fundamental primivive for a subjective +level, these ratings provide a fundamental primitive for a subjective distributed reputation system. ## Potential issues From 3fd71dbd6a267a91fccc06566ec808ac3788ae30 Mon Sep 17 00:00:00 2001 From: gnuxie Date: Wed, 12 Mar 2025 23:16:38 +0000 Subject: [PATCH 4/6] Add Alternative: Anti-ban. --- proposals/4273-approval-disapproval.md | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) diff --git a/proposals/4273-approval-disapproval.md b/proposals/4273-approval-disapproval.md index 9ff117cb2d4..8da513c61dc 100644 --- a/proposals/4273-approval-disapproval.md +++ b/proposals/4273-approval-disapproval.md @@ -126,6 +126,31 @@ Approval ratings could be kept on local storage rather than in policy rooms. However, this would reduce the potential for interoperation of different tools and clients. +### Anti-ban + +Moderation bots can use anti-ban moderation policies that can make entities +immune to other policies with the `ban` recommendation. +[Meowlnir](https://github.com/maunium/meowlnir) currently implements a form of +anti-ban via "unban" policies, so that if an unban policy is found before a ban +policy, the unban takes precedence and the ban is ignored. This has the benefit +of not requiring an existing policy to disapprove of. And their effect remains +regardless of duplicate `ban` policies. + +This approach does however have a few drawbacks: + +- anti-ban policies are specific to the `ban` recommendation, and are not + generic to policies of all recommendation types. + + - As a consequence, it is also harder to use anti-ban ratings in recommender + systems compared to approve/disapprove ratings. + +- anti-ban requires careful consideration in policy list subscription profiles, + as naive implementation provides a vector for entities immune to any future + action unless the list is unwatched or a policy revoked. + +- anti-ban policies cannot express disapproval of content within a policy, such + as a specific reason or context for the policy. + ## Security considerations See ptoential issues. From 72d9993063547c973c3daed7a29c1ba600c66bbf Mon Sep 17 00:00:00 2001 From: gnuxie Date: Thu, 13 Mar 2025 00:08:16 +0000 Subject: [PATCH 5/6] Add copy propagation alternative. --- proposals/4273-approval-disapproval.md | 30 ++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) diff --git a/proposals/4273-approval-disapproval.md b/proposals/4273-approval-disapproval.md index 8da513c61dc..d77a6457980 100644 --- a/proposals/4273-approval-disapproval.md +++ b/proposals/4273-approval-disapproval.md @@ -151,6 +151,36 @@ This approach does however have a few drawbacks: - anti-ban policies cannot express disapproval of content within a policy, such as a specific reason or context for the policy. +### Copy propagation for approval + +For the positive approval use case, bots could watch a policy list without +applying any policy from it. Then to approve policies, they can be copied over +to a list where policies applied. +[Meowlnir](https://github.com/maunium/meowlnir) has been considering this +strategy. + +#### Assessment + +Copy propagation of policies breaks the audit chain and removes them from their +original context. For example, copying a ban would remove the from the original +list and the sender. The community that copies the ban likely will not have any +information surrounding the circumstances of the ban beyond the data contained +within the copy of policy. + +If the original sender rescinds or revokes the ban, then the audit chain is +broken, because without additional consideration, the copies will not be +removed. + +This is extremely problematic, especially in the context of social networks such +as Matrix and the Fediverse. Bans are rescinded because of mistakes, +forgiveness, changing circumstances, new information, and age all of the time. +And yet on networks that follow copy propagation, bans are often permanent and +indefinite. Even after explicit retraction. Moderators are incentivised to keep +copies active out of an abundance of caution and to create less work. + +For this reason, we strongly recommend against using copy propgation not just as +a strategy for approval, but in all circumstances. + ## Security considerations See ptoential issues. From f6f6016d21fbe7251fdd4e5a6151bfff0a3e16ce Mon Sep 17 00:00:00 2001 From: gnuxie Date: Thu, 13 Mar 2025 00:17:07 +0000 Subject: [PATCH 6/6] Update anti-ban assessment. --- proposals/4273-approval-disapproval.md | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/proposals/4273-approval-disapproval.md b/proposals/4273-approval-disapproval.md index d77a6457980..9c1d33b48e9 100644 --- a/proposals/4273-approval-disapproval.md +++ b/proposals/4273-approval-disapproval.md @@ -136,20 +136,20 @@ policy, the unban takes precedence and the ban is ignored. This has the benefit of not requiring an existing policy to disapprove of. And their effect remains regardless of duplicate `ban` policies. -This approach does however have a few drawbacks: - -- anti-ban policies are specific to the `ban` recommendation, and are not - generic to policies of all recommendation types. +#### Assessment - - As a consequence, it is also harder to use anti-ban ratings in recommender - systems compared to approve/disapprove ratings. +The anti-ban approach is specific to the `ban` recommendation, whereas +approve/disapprove ratings are generic to any policy type. The +approve/disapprove ratings are also meant to be future proof and ready for +consumption by recommender systems due to their generic nature. -- anti-ban requires careful consideration in policy list subscription profiles, - as naive implementation provides a vector for entities immune to any future - action unless the list is unwatched or a policy revoked. +Anti-ban also requires careful consideration in policy list subscription +profiles, as naive implementation provides a vector for entities to become +immune to any future action unless the targeted list is unwatched or the +offending policy is revoked. -- anti-ban policies cannot express disapproval of content within a policy, such - as a specific reason or context for the policy. +Anti-ban policies also cannot express disapproval of content within a policy, +such as a specific reason or context for the policy. ### Copy propagation for approval