FEP-baf5: Administrator Collection

2026-05-22 22:45 UTC

@silverpill@mitra.social said: You say that your FEP supersedes the same-origin assumption described in FEP-fe34, but I think it describes a reciprocal claim, also described in FEP-fe34: https://codeberg.org/fediverse/fep/src/branch/main/fep/fe34/fep-fe34.md#reciprocal-claims. I suggest clarifying which aspect of FEP-fe34 is being superseded. I suppose supercedes is the incorrect term. It extends fe34, in a way. Would that be acceptable? Definitely not meaning to imply that fe34 is insufficient in any way. #3 :heavy_check_mark: okay

Replies (2)

@silverpill@mitra.social 2026-05-22 23:07

Wasn't aware this was a problem? Figured the redirects would be okay. The canonical location of a FEP is on Codeberg, but no, it is not a problem. #2 I suppose supercedes is the incorrect term. It extends fe34, in a way. Would that be acceptable? Definitely not meaning to imply that fe34 is insufficient in any way. "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?)

Open ##2771051
@julian@activitypub.space 2026-05-23 01:01

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.

Open ##2779284