Support for moderation activities

[ThisIsMissEm]

Hi! Looking quickly through the code, you don't appear to be handling converting between Flag activities (which are used for reporting an account and/or statuses) nor for BlueSky's / AT Proto's com.atproto.moderation.createReport

adding support for these would make this project a much better citizen on both platforms, as you'd be federating content moderation. Without this, bridges and similar software using this would be deemed "unmoderated" which is generally a reason for a specific domain to end up on a blocklist.

[snarfed]

Good feature request, thanks for filing!

https://www.w3.org/TR/activitystreams-vocabulary/#dfn-flag

Related: https://docs.joinmastodon.org/spec/activitypub/#suspended
https://docs.joinmastodon.org/spec/activitypub/#Flag

[ThisIsMissEm]

Related:

• https://atproto.blue/en/latest/atproto/atproto.xrpc_client.models.com.atproto.moderation.defs.html
• https://atproto.blue/en/latest/atproto/atproto.xrpc_client.models.com.atproto.moderation.create_report.html

[snarfed]

Looked at this a bit. ATProto currently defines the createReport XRPC method, but no read methods, and no standalone moderation object types other than the com.atproto.moderation.defs#reasonType enum. So afaict the new feature here would be to take an AS2 Flag as input and create a Bluesky report for it.

granary currently only reads from Bluesky, it doesn't make any write calls. Same with the https://granary.io/ REST API and UI. So this somewhat depends on implementing Bluesky writes at all, ie snarfed/bridgy#1580 , which is upcoming.

[snarfed]

The plot thickens. If I understand right, this means that ATProto reports are outside federation entirely, ie they're not records that are stored in PDSes and synched to relays and AppViews. So even if I implement this translation, it's not clear how I would use it in eg Bridgy Fed.

Guess I need to dig into their labeler architecture more.

[snarfed]

Confirmed with the Bluesky team, ATProto reports are 1) out of band, not records stored in repos, so that they can be private, among other reasons, and 2) sent to mod services (née labelers), not to PDSes (ie instances). So I guess the main question would be, if I get an AP Flag of an ATProto user or post, how do I decide which mod service to send it to? I guess I could just send it to any big ones that accept reports publicly. Will see.

[ThisIsMissEm]

Huh, okay, and I guess to receive flags you'd have to be a mod service too, right?

[snarfed]

Maybe? They've done a lot of work on this internally, and anyone can run their own mod service, will but there isn't nearly as much actual precedent yet, so it kind of remains to be seen.

Importantly though, I don't think the point is necessarily to keep reports hidden from users or instance/PDS admins. They are considered sensitive and private, but not necessarily secret. You could probably make a mod service that just receives them. I think the point is that moderation work can be decoupled from PDS admins, so that orgs like FIRES, IFTAS, etc can build tools for it, and handle reports, and then admins can choose whether/which of those mod services to use.

[snarfed]

OK! I have this working for fediverse => Bluesky. When Bridgy Fed gets a Flag activity, it translates it into the corresponding com.atproto.moderation.createReport to the Bluesky team's official mod service. I've tested against https://bsky.app/profile/atproto-spoilers.bsky.social (https://labeler.dholms.xyz), and it's working ok.

As for the other direction (Bluesky createReport => AP Flag), I have some of the plumbing in place, but I'll need to subscribe to the official mod service's label firehose and detect labels against bridged users. Doable, but nontrivial. Tracking in snarfed/bridgy-fed#971.

Thanks @ThisIsMissEm for your input and support here!