activitystreams icon indicating copy to clipboard operation
activitystreams copied to clipboard

Issuing updates related to Flag Activities?

Open ThisIsMissEm opened this issue 1 year ago • 2 comments

Please Indicate One:

  • [ ] Editorial
  • [x] Question
  • [ ] Feedback
  • [ ] Blocking Issue
  • [ ] Non-Blocking Issue

Please Describe the Issue:

Currently when content is reported on ActivityPub servers, this generates a Flag activity being sent to the other servers, in practice with Mastodon this looks like:

    {
      "@context": "https://www.w3.org/ns/activitystreams",
      "id": "https://social.example/reports/123",
      "type": "Flag",
      "content": "Harassing comment",
      "actor": "https://social.example/@jane_smith",
      "object": [
         "https://other.social/users/123",
         "https://other.social/users/123/status/456",
      ],
    }

However, we currently lack a way to represent the report itself in ActivityStreams, so https://social.example/reports/123 cannot be requested and get back some representation of the report.

This then means that we don't really have a mechanism to allow other.social to notify social.example that they've resolved the report that gets created on their server (since it's a copy), we can't send an Update, because we don't have an Object to update as far as I can tell?

We can't do Accept/Reject for the same reason.

Unless it's possible for us to do something like:

    {
      "@context": "https://www.w3.org/ns/activitystreams",
      "id": "https://social.example/reports/123#2024-07-19T200...",
      "type": "Update",
      "object": {
        "type": "Flag",
        "content": "Harassing comment",
        "actor": "https://social.example/@jane_smith",
        "object": [
           "https://other.social/users/123",
           "https://other.social/users/123/status/456",
        ],
      }
   }

This means that we currently seem to lack a way to allow a server that has received a Flag activity to notify the reporting server that the Flag has been resolved, which leaves people wondering if their reports have actually been recieved or actioned by remote users.

I suspect this needs a FEP.

ThisIsMissEm avatar Jul 19 '24 14:07 ThisIsMissEm

In issue triage today, we considered some options for this process.

  • Recipient updates the Flag activity. This is pretty unusual, since the implied authorization model of AP is that only the actor can update something they create.
  • If activities are performed in reaction to the flagging, like a Delete or Update or Block or ..., those activities have a metadata property referring to the Flag activity, like inReplyTo or context, or a new property.
  • A response activity could be returned, such as an Accept, which has the Flag activity as its object, and the actions that were perfomed as the result. This would need some care, especially if multiple activities are performed over time in response to the same Flag.

An important part of this is content -- giving some notice to reporter why their report was or wasn't acted upon.

Any work in here will need to take into account user safety. We wouldn't want to expose the reporter's identity without their consent.

I think this work is really interesting, but probably isn't directly implied by the Activity Vocabulary definitions. I think a FEP is probably the next best step.

evanp avatar Jul 19 '24 16:07 evanp

I've documented more of the user experience concerns in https://github.com/mastodon/mastodon/issues/31083

ThisIsMissEm avatar Jul 19 '24 19:07 ThisIsMissEm

Closing as I think this can be moved to the ActivityPub Trust & Safety Taskforce within SWICG.

ThisIsMissEm avatar Sep 13 '24 20:09 ThisIsMissEm

This is being handled in swicg/activitypub-trust-and-safety, so unlabelling.

evanp avatar Mar 28 '25 16:03 evanp