That actually does make sense and allows for cross-origin moderation.

The same-origin assumption is necessary for authentication, because it is not possible to not trust the server of origin.

But it is not necessary for authorization. It is desirable, because that makes authorization procedures aligned with authentication procedures. But we can shift the burden of permission checks to the recipient.

We might even have to do this, if we discover that servers accepting arbitrary payloads (C2S, FEP-ae97) can't reliably enforce the isolation of actors.

But for the time being, you can accept same-origin admin deletions.

So to confirm then, you serve the moderator collection but you don't use it to determine whether an actor is able to modify/delete content on that instance, is that right?

Curious to know what those problems are.

Right now, attributedTo.inbox is the last option to send your moderation activities. There are probably more relevant options to try first. The work is to identify those options and make them consistently discoverable. See "Delegated control" here: https://github.com/swicg/activitypub-trust-and-safety/issues/24#issuecomment-4365331657

It may be a good idea to extend this concept to the instance/application actor as well. There's no urgent need to implement and consume, but it would be fairly simple thing to serve on our respective softwares I think.

Is this causing problems for you? I can send just the IDs instead.

On communities the moderators are just an array of strings which are the activitypub actor IDs of the mods. I think NodeBB has an array of actor objects though?

Anyway whatever it is, consistency with how the communities do it would be nice.

Wait, why don't we write a mini FEP to extend this? attributedTo on the instance/application actor?

• https://codeberg.org/fediverse/fep/src/branch/main/fep/2677/fep-2677.md
• extending 1b12

This is easy in FEP 1b12-land because each community has a list of moderators so receiving instances know who to allow.

Getting a list of instance admins requires calling the Lemmy API, unfortunately. So PieFed has a cron job that does that once per day for all instances. Admins rarely change.

(Announce wrapping aside.)

They (and I) don't use moderatedBy but rather the group actor's attributedTo

Just want to make sure you're aware of that existing prior art.

alternatively, the problem would not be there if service actors messaged each other for more explicit syndication...

Open to working on standardizing that though <img class="not-responsive emoji" src="https://activitypub.space/assets/plugins/nodebb-plugin-emoji/emoji/android/1f61b.png?v=8161d5c9b56" title="" />

So whilst you have same-origin, you actually also have same-actor and http-message-signatures indicated authenticated actor.

The moderator is deleting the post, not the author, so the moderator is the Delete's actor.

You could fake this by federating out an update or delete as though it came from the original author, which would be a most compatible way to do things, but it isn't necessarily right.