Lemmy doesnt even federate admin status in any way, instead we trust that actions which are coming from the same instance as the community or post are valid. So essentially origin-based security model.

Looks like this, only IDs: https://github.com/LemmyNet/lemmy/blob/main/crates/apub/apub/assets/lemmy/collections/group_moderators.json

Right, that's the "Group Moderation" section of FEP 1b12, right?

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.

@julian @thisismissem @technical-discussion Note that a community's attributedTo doesn't work for anything outside of communities, but a moderator can be declared for any object.

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

Yes exactly that FEP. Federating admin status would make sense for informational purposes, but rejecting mod actions based on that could cause problems as I mentioned in my previous comment.

Sorry @julian and @nutomic@lemmy.ml if this has almost nothing to do with this, but I'd like to point out that Lemmy (perhaps Piefed as well, but I'm not sure) has a very interesting feature: a community moderator can also be a user of an instance other than the one where that community is physically located.
This isn't possible with NodeBB because the API call isn't considered valid.
This means that the Lemmy development staff has managed to develop a way to somehow federate content moderation.

> @nutomic@lemmy.ml said:
>
> but rejecting mod actions based on that could cause problems as I mentioned in my previous comment.

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.

@julian @rimu Do you want specifically FEP-2677? Please consider using FEP-d556 instead, it is very similar to FEP-2677 but doesn't require NodeInfo. Also, it is FINAL.

@silverpill@mitra.social was not aware of d556. I'll make the swap, thanks.

@julian I've done a review on FEP-fe34 and here's a more nuanced answer.

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.