Home | Notifications | New Note | Local | Federated | Search | Logout

Note Detail

Reply to @julian@activitypub.space
julian@julian@activitypub.space (2026-05-23 10:01:50)
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.
---Reply---
silverpill@silverpill@mitra.social (2026-05-23 16:21:02)
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