1. I find the use of attributedTo here confusing, because normally this property is used to indicate who owns an object or a collection, and its value is an actor. I am aware that attributedTo is used in a similar way in FEP-1b12, but it would be better to introduce a new property (administrators) instead of continuing to abuse attributedTo.
2. 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.
3. In the section "Security and Authorization" you say "authenticity" but what actually is being verified is a permission.
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).
5. FEP links lead to w3id.org site, not directly to FEPs.
Replies:
9
1. I find the use of attributedTo here confusing, because normally this property is used to indicate who owns an object or a collection, and its value is an actor. I am aware that attributedTo is used in a similar way in FEP-1b12, but it would be better to introduce a new property (administrators) instead of continuing to abuse attributedTo.
2. 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.
3. In the section "Security and Authorization" you say "authenticity" but what actually is being verified is a permission.
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).
5. FEP links lead to w3id.org site, not directly to FEPs.
1. I find the use of attributedTo here confusing, because normally this property is used to indicate who owns an object or a collection, and its value is an actor. I am aware that attributedTo is used in a similar way in FEP-1b12, but it would be better to introduce a new property (administrators) instead of continuing to abuse attributedTo.
2. 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.
3. In the section "Security and Authorization" you say "authenticity" but what actually is being verified is a permission.
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).
5. FEP links lead to w3id.org site, not directly to FEPs.
@silverpill@mitra.social @julian@activitypub.space @technical-discussion@activitypub.space
I agree with Silverpill 'attributedTo' should not be overloaded by this extra meaning
I agree with Silverpill 'attributedTo' should not be overloaded by this extra meaning
⁂ Article
FEP-baf5: Administrator Collection
@silverpill@mitra.social said:
- 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.
⁂ Article
FEP-baf5: Administrator Collection
@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.
#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.
#3 :heavy_check_mark: okay
FEP-baf5: Administrator Collection
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.
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?)
⁂ Article
FEP-baf5: Administrator Collection
@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 
FEP-baf5: Administrator Collection
@silverpill@mitra.social said:
- FEP links lead to w3id.org site, not directly to FEPs.
Wasn't aware this was a problem? Figured the redirects would be okay.
