The reason why attributedTo was chosen is because there is prior art to using that property to represent a collection of moderators. You could make the same argument against 1b12 (that moderators should be the key instead of attributedTo), too.

The argument as to whether a custom property fits better is certainly valid, and worth debating. However, I would want to point out that keeping with prior art has the benefit of making this FEP much easier to adopt by threadiverse implementors.

> @silverpill@mitra.social said:
>
> Extends" is fine, I just think you're describing a reciprocal claim from FEP-fe34, so you could use that term (or maybe FEP-fe34 needs to be updated if "reciprocal claim" is not a good name for this mechanism?)

I don't know if this is truly a reciprocal claim. My understanding from a reading of the relevant section from fe34 suggests a claim of A → B is reciprocal if there is an inverse claim B → A.

fe34 solidifies the concept of same-origin trust (which iirc is only something like a line or two in AP spec?). baf5 builds upon that with an additional opt-in specificity. So baf5 assumes fe34 compatibility, but not the inverse. But we're splitting hairs I think <img class="not-responsive emoji" src="https://activitypub.space/assets/plugins/nodebb-plugin-emoji/emoji/android/1f604.png?v=f187f9278b7" title="" />

> @silverpill@mitra.social said:
>
> 4. The entire problem of non-same-actor updates and deletes can be avoided by using different activities. For example, Update can be replaced with an annotation activity. Delete can be replaced with Remove (from thread).

While true, this is outside the scope of the FEP. Update/Delete were mentioned in the FEP as they are recognizable, but this sort of explicit authorization* is relevant to any activity type. Offer, Undo, Bite, Zooboomafoo, etc.

* I have to be careful when I use the term "authorization" because if I say it three times @thisismissem will show up and start talking about OAuth2/OIDC again.

> @julian said:
>
> * I have to be careful when I use the term "authorization" because if I say it three times @thisismissem will show up and start talking about OAuth2/OIDC again.

Correction: it's just a single mention that makes me appear, people tend to confuse me with a genie but we're quite different.

(Also I saw other replies here but had an MCAS attack hangover today so didn't have energy to reply. I'll try to reply soon)

@silverpill@mitra.social @julian@activitypub.space @technical-discussion@activitypub.space

I agree with Silverpill 'attributedTo' should not be overloaded by this extra meaning

My understanding from a reading of the relevant section from fe34 suggests a claim of A → B is reciprocal if there is an inverse claim B → A.

Yes, and in my understanding these claims are:

- This actor is authorized to delete/update this object.
- This object is hosted on the server where this actor is an administrator.

But I don't insist on importing this concept.

I would want to point out that keeping with prior art has the benefit of making this FEP much easier to adopt by threadiverse implementors.

I consider myself a threadiverse implementer too, and I don't really like the idea of dealing with ambiguous properties

At the very least, could you add inbox and outbox properties to the Application actor example? https://codeberg.org/devnull/feps/src/branch/instance-admins/fep/baf5/fep-baf5.md#instance-actor-and-application-actor

I agree with Silverpill that attributedTo is a little misplaced here, and a more explicit term would probably be better. e.g., administrators or moderatedBy (this is coming from the T&S taskforce and references a Moderation Group actor, not a collection).

I am working a FEP which in some ways is related to your proposal:

FEP-5219: Groups and permissions

It introduces a new collection called affiliations, which is intended as a single source of information on who is allowed to do what (within a specific domain).

The FEP is mainly concerned with FEP-1b12 groups, but the affiliations collection could also be attached to Application actors, and be used in a way you described in FEP-baf5: Administrator Collection

@silverpill@mitra.social no objections at first pass, will need to do a deeper read through.

Most importantly though it won't matter unless you get @nutomic@lemmy.ml and @rimu@piefed.social on board.

That's the plan. I am trying to introduce new features (such as fine-grained permissions) while keeping it as close to existing implementations as possible.

@nutomic @rimu