Formally define the Flag activity for sending reports

[trwnh]

from #13 (comment)

one thing that would be helpful here (and in other issues) is to start a little lower actually, and formally define the Flag activity as a mechanism to send reports, as well as defining which properties it can have and the general shape and structure (how to interpret)

we don't actually have a formal definition for Flag activities at the moment, it's one of those de facto things that mastodon did and everyone else followed. so i think a way forward is this

• do an implementation survey for existing usage of the Flag activity to represent reports
• identify shortcomings and gaps with existing usage
• come up with a formal definition of Flag that addresses the existing format as well as its shortcomings

related to

• Improve Flag activities to include the categorisation of the report #2
• Improve Flag activities to differentiate the object being reported vs the evidence for that report #3
• Recommendation: encourage activitypub software to implement polymorphic moderation reports #13

[ThisIsMissEm]

Should we create a ticket for "define how to dereference a Flag activity" e.g., I send you a Flag activity, you can GET that activity back by @id

The big question there is "what the heck should the access controls be?"

[trwnh]

seems to be the same as dereferencing any other object or activity -- if it's Public, then anyone should be able to fetch it, and otherwise you can generally assume that the members of to/cc/audience have permission to (re)fetch it (since it was delivered to them already). there's not really any consideration for access control in as2/ap separately from the addressing properties.

[ThisIsMissEm]

@trwnh I'm not sure historically if Flag activities have actually had to/cc/audience, because there wasn't a way to address the Moderators of an instance nor an Instance, because ActivityPub didn't define those things (I know there's a FEP proposing this)

[trwnh]

in the absence of addressing properties (i.e. if you just receive an activity in an inbox and it has no further information) then you can generally assume or treat it equivalent to being in bto/bcc

[ThisIsMissEm]

Okay, so here's my current thinking:

{
  "type": "Flag",
  "id": "https://example.social/flag/:uuid",
  "to": "https://target.example/@moderators",
  "cc" [
    "https://involved.server.example/@mods"
  ],
  "actor": "https://example.social/mods",
  "content": "This user was mean to me",
  "object": "https://target.example/@badactor",
  "evidence": [
    "https://target.example/@badactor/s/123",
    "https://target.example/@badactor/s/124"
  ],
  "category": "rule_violation"
  "rules_violated": [ ..., ... ]
  "reporter": "<stable yet masked identifier for reporter>"
}

The last few properties would be extensions, defined in FEPs. The to/cc would require moderation group actor discovery, per #24, and it'd be delivered to each participant's inbox.

reporter would be the #8, category/rule_ids would be #2, evidence would be #3.

[trwnh]

instead of “evidence” you could use “attachment” instead of “reporter” you could use a proxy actor for “actor” “category” and “rules_violated” seem fine although you could *maybe* use “tag”.

…

On Fri, Oct 25, 2024 at 15:21 Emelia Smith ***@***.***> wrote: Okay, so here's my current thinking: { "type": "Flag", "id": "https://example.social/flag/:uuid", "to": ***@***.***", "cc" [ ***@***.***" ], "actor": "https://example.social/mods", "content": "This user was mean to me", "object": ***@***.***", "evidence": [ ***@***.***/s/123", ***@***.***/s/124" ], "category": "rule_violation" "rules_violated": [ ..., ... ] "reporter": "<stable yet masked identifier for reporter>" } The last few properties would be extensions, defined in FEPs. The to/cc would require moderation group actor discovery, per #24 <#24>, and it'd be delivered to each participant's inbox. reporter would be the #8 <#8>, category/rule_ids would be #2 <#2>, evidence would be #3 <#3>. — Reply to this email directly, view it on GitHub <#14 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACQ5OX7QH4KEFXDZK4OBVQLZ5KR4TAVCNFSM6AAAAABOZQGTEWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMZYG4ZDKNJXGQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>