Question re: Origin Based Security Model (FEP-fe34)
-
Well, yeah, that's why I linked what T&S is doing here to fix the moderator use case. At present I don't know of anyone sending cross-actor delete/update actions, so we'd be adding capability with the
moderatedBy -
Well, yeah, that's why I linked what T&S is doing here to fix the moderator use case. At present I don't know of anyone sending cross-actor delete/update actions, so we'd be adding capability with the
moderatedBy@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
moderatedBybut rather the group actor'sattributedToJust want to make sure you're aware of that existing prior art.
-
@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
moderatedBybut rather the group actor'sattributedToJust 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
Deleteactivities with the moderator actor?(Announce wrapping aside.)
-
@nutomic@lemmy.ml @rimu@piefed.social @bent0_b0x@norden.social — do y'all send
Deleteactivities 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.
-
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?
attributedToon the instance/application actor? -
> @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?
attributedToon the instance/application actor?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.
-
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 thoughIs this causing problems for you? I can send just the IDs instead.
-
> @rimu@piefed.social said:
>
> I think NodeBB has an array of actor objects thoughIs 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.
-
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.
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.
-
It's fine, I've already adjusted the code at my end. I don't know about Lemmy though.
Looks like this, only IDs: https://github.com/LemmyNet/lemmy/blob/main/crates/apub/apub/assets/lemmy/collections/group_moderators.json
-
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.
-
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.
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.
-
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.
> @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.
-
> @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.
We use the moderator collection. But if that fails we check if the mod is from the same instance as the community or the post/comment being removed. If thats true we also allow the action.
