[feature] Limit interactions (likes, replies, boosts) on a status with per-status settable "interaction policy"

[tsmethurst]

We didn't have an issue for this yet, so I'm just creating one here to track this.

Currently working on a branch to introduce the concept of an interaction policy into GoToSocial. Users ought to be able to set a default interaction policy per visibility level of a status, and also when creating a new status they should be able to specify an interaction policy for just that status.

Interaction policy will let users decide who can reply / like / boost a status without needing approval, who can do with while requiring approval, and who can't do it at all. For example, you could set "canReply" without approval to followers, and set "canReply" with approval to everyone else, etc.

On a federation level, this will be sent out as an interactionPolicy property on a Note with this form:

{
  "@context": [
    "https://gotosocial.org/ns",
    "https://www.w3.org/ns/activitystreams"
  ],
  "content": "hey @f0x and @dumpsterqueer",
  "contentMap": {
    "en": "hey @f0x and @dumpsterqueer",
    "fr": "bonjour @f0x et @dumpsterqueer"
  },
  "interactionPolicy": {
    "canAnnounce": {
      "always": [
        "https://gts.superseriousbusiness.org/users/dumpsterqueer",
        "https://gts.superseriousbusiness.org/users/f0x"
      ],
      "approvalRequired": [
        "https://www.w3.org/ns/activitystreams#Public"
      ]
    },
    "canLike": {
      "always": [
        "https://www.w3.org/ns/activitystreams#Public"
      ],
      "approvalRequired": []
    },
    "canReply": {
      "always": [
        "https://www.w3.org/ns/activitystreams#Public"
      ],
      "approvalRequired": []
    }
  },
  "tag": [
    {
      "href": "https://gts.superseriousbusiness.org/users/dumpsterqueer",
      "name": "@[email protected]",
      "type": "Mention"
    },
    {
      "href": "https://gts.superseriousbusiness.org/users/f0x",
      "name": "@[email protected]",
      "type": "Mention"
    }
  ],
  "type": "Note"
}

Users will be able to "approve" or "reject" an interaction explicitly via a section in the settings panel, and will be able to approve replies implicitly by liking, boosting, or replying to the reply. At that point GtS will sound out an "Accept" message with the URI of the interaction as the Object of the Accept. The owner of the interacting status can then send it out to everyone with the URI of the Accept in the approvedBy field of the Activity or Object.

In design this is quite similar to what's written in this FEP, though with some changes:

1. Just use Accept for doing approval/acceptance, not the specialized activity described in the fep.
2. Extend the canReply field to the whole interaction policy which allows for more granular permissions.

This is also sort of similar to what Pixelfed does with capabilities / comment controls, as described here -- https://docs.pixelfed.org/spec/ActivityPub.html#capabilities-comment-controls -- and indeed those capabilities can be translated into the interactionPolicy described above, so we should aim to support that too.

[tsmethurst]

Related to: mastodon/mastodon#8565

[tsmethurst]

WIP branch: https://github.com/superseriousbusiness/gotosocial/tree/interaction_policy

[tsmethurst]

Related to: superseriousbusiness/activity#23

[tsmethurst]

In-progress documentation for this feature, with extensive examples and stuff: https://github.com/superseriousbusiness/gotosocial/blob/interaction_policy/docs/federation/posts.md#interaction-policy

[tsmethurst]

Some API model examples: https://gts.superseriousbusiness.org/@dumpsterqueer/statuses/01J1Q4V2KDFQRN50MK80W0N3Y8

[tsmethurst]

Work in progress view of the section in the settings panel for setting default policies:

[tsmethurst]

Remaining bits of work before this issue can be considered closed:

- [x] Expose API to allow users to view pending interactions.
- [x] Expose API to allow users to accept pending interactions.
- [x] Expose API to allow users to reject pending interactions.
- [x] Federate Rejects in and out, and handle side effects of a reject.
- [x] Make sure replies to unpermitted replies aren't processed at all.

Further work (to do separately, but noting it down here before I forget):

• Handle FEP-5624 style reply controls and incorporate them into interaction policies. The former is a subset of the latter so this should be easy.
• Handle ApproveReply and RejectReply from abovementioned FEP.
• Handle Pixelfed's capabilities comment controls and incorporate them into interaction policies. Again, the former is a subset of what interaction policies permits, so this should be OK. Pixelfed has confirmed that they'll be using the GtS style interaction policies, so we don't need to do this part.