@Profpatsch @julian i've been doing some trust and safety TF work to explore/develop a bidirectional link between actors and moderators/hosts, yeah. mostly in the context of "where to send moderation related activities" (so you don't Flag a user to themselves if there's a better option), but also could be used for authorizing Update/Delete activities.

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

@thisismissem hmm, I believe Lemmy and Piefed send cross actor Deletes, but they might be Announces by the group actor.

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.

@nutomic@lemmy.ml @rimu@piefed.social @bent0_b0x@norden.social — do y'all send Delete activities with the moderator actor?

(Announce wrapping aside.)

Yes.

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.

> @rimu@piefed.social said:
>
> Getting a list of instance admins requires calling the Lemmy API, unfortunately.

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

That sounds fine to me.

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.

> @rimu@piefed.social said:
>
> I think NodeBB has an array of actor objects though

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

It's fine, I've already adjusted the code at my end. I don't know about Lemmy though.

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.