Formally define the Flag activity for sending reports

[trwnh]

from https://github.com/swicg/activitypub-trust-and-safety/issues/13#issuecomment-2372726941

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

• 2

• 3

• 13

[jfinkhaeuser]

So... reading up a bit here, I came at this more from a question of formalizing the #FediBlock tag into a block recommendation system.

I understand the Flag activity to be similar, but I don't think they're the same.

There are two easy examples to consider IMHO:

1. Flagging a user/their content shouldn't automatically result in a block recommendation. It can, if there is sufficient evidence that's the appropriate course of action. But typically one would expect that a block recommendation occurs after several reports/flags.
2. Instance block recommendations in particular are a special case of the same problem, where multiple reasons across multiple actors may result in the recommendation.

It seems that the Flag activity is the more basic component here, and there should be a way to create a block recommendation activity as well that most likely refers to several Flags, if not additional other reasoning.

[ThisIsMissEm]

@jfinkhaeuser for now I'm trying to specifically steer us away from new features (like block recommendations or sharing domain blocks) towards focusing on standardisation and getting much needed general features in.

i think #FediBlock is actually an anti-pattern, something I'm hoping to solve with my FediMod FIRES project: https://fires.fedimod.org

That is, subscribing to Advisories and Recommendations related to specific Object types and other entities from specific organised groups. Right now #FediBlock is very often high noise to signal, as you have random people bringing their personal matters to the hashtag. Generally significantly more information is required before actually creating a Recommendation to block or filter something.

[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": "" }

The last few properties would be extensions, defined in FEPs. The to/cc would require moderation group actor discovery, per #24 https://github.com/swicg/activitypub-trust-and-safety/issues/24, and it'd be delivered to each participant's inbox.

reporter would be the #8 https://github.com/swicg/activitypub-trust-and-safety/issues/8, category/rule_ids would be #2 https://github.com/swicg/activitypub-trust-and-safety/issues/2, evidence would be #3 https://github.com/swicg/activitypub-trust-and-safety/issues/3.

— Reply to this email directly, view it on GitHub https://github.com/swicg/activitypub-trust-and-safety/issues/14#issuecomment-2438725574, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACQ5OX7QH4KEFXDZK4OBVQLZ5KR4TAVCNFSM6AAAAABOZQGTEWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMZYG4ZDKNJXGQ . You are receiving this because you were mentioned.Message ID: @.***>