How do account reports federate? (Is there sample data?)

Software Mastodon
1

Mastodon does have the ability to file a report about an account and posts. These reports can also be transferred to the account’s own server.

I saw on ActivityPub - Mastodon documentation that Flag is used for these reports. The activity itself is described here: Activity Vocabulary

Question is only, how this is exactly implemented. Is there any sample data?

Thanks!

2

actor Flag object, with optional content

image
image925×94 38.5 KB

so exactly as shown in the example

for Mastodon’s purposes, the report is filed against an account, and optionally some posts

1 Like
3

Thanks! Do you know how it looks like when there are multiple posts? It seems as if they all are added to the object.

4

Yes, if multiple posts are reported then they will all still be in the object array.

1 Like
5

Do you know if the category is transmitted as well? See here: reports API methods - Mastodon documentation

And do you know which inbox this is sent to?

6

Ah, no, category isn’t transmitted, only optional reason.

Per Mastodon source code it looks like this is sent to the reported account’s inbox: mastodon/report_service.rb at c4a429ed47e85a6bbf0d470a41cc2f64cf120c19 · mastodon/mastodon · GitHub – perhaps it shouldn’t be, but Mastodon doesn’t really make a distinction between private inboxes and shared inbox AFAIK.

7

yeah now that instances actors are much more common I think it would be useful to revisit where and how reports are sent, we’re definitely open to feedback in this area.

report “categories” only really make sense on the local server though, I don’t think it makes sense for us to federate them. they’re tied very specifically to a set of local moderation categories defined by the instance admin.

8

the way i see it, sending to an instance actor only makes sense if the actor is managed by an instance. i’m not entirely sure if the sharedInbox is always equivalent to being on a hosted service, but it seems like a safe bet to send to sharedInbox if one is available.

the other thought i just had while looking at the payload was that maybe there should be a distinction between reported accounts and reported posts? cramming everything in object seems a bit awkward because the statuses are not really what is being reported primarily. it might make sense to migrate toward using attachment for reported statuses?

if this gets done, it would probably be like so:

  1. start including statuses in attachment + support parsing attachment if available
  2. at some future point, drop statuses from object so that object refers only to the reported account(s)

possible counterarguments: maybe the statuses are indeed being reported in the same semantic way as the account. maybe there is a use-case for reporting a status but not an account?

9

Having a separate area for reported accounts and reported posts sounds good.

10

A category like “spam” is widely agreed upon, so transmitting this could make sense.

Concerning the inboxes: Does Mastodon care to which inbox this is sent? Otherwise I guess I try the system actor, if I find one. And as a fallback I will try the shared inbox.

11

Concept: use generator on an actor to point to the instance actor, since each actor is really managed by the instance.