-
Notifications
You must be signed in to change notification settings - Fork 57
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for moderation activities #596
Comments
Good feature request, thanks for filing! https://www.w3.org/TR/activitystreams-vocabulary/#dfn-flag Related: https://docs.joinmastodon.org/spec/activitypub/#suspended |
Looked at this a bit. ATProto currently defines the 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. |
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. |
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 |
Huh, okay, and I guess to receive flags you'd have to be a mod service too, right? |
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. |
OK! I have this working for fediverse => Bluesky. When Bridgy Fed gets a As for the other direction (Bluesky Thanks @ThisIsMissEm for your input and support here! |
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'scom.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.
The text was updated successfully, but these errors were encountered: