FEP-f15d: Context Relocation and Removal

[julian@activitypub.space]

Threaded applications often have the need to move and remove content between groups/communities for curation purposes (i.e. resolving miscategorization, spam, etc.)

This is an extension of the Resolvable Contexts tree of FEPs.

---

The FEP draft has been submitted for review. In the meantime, it can be viewed here: https://github.com/julianlam/feps/blob/fep-f15d/fep/f15d/fep-f15d.md

[julian@activitypub.space]

The submission of the FEP and timing of this post are intentional as there are now two implementors supporting (part of) this FEP.

• NodeBB as of v4.7.0
• Piefed as of v1.5

As the implementors work through any issues, the FEP and this topic will be updated to reflect those changes.

[julian@activitypub.space]

Tagging relevant parties:

• @rimu@piefed.social of Piefed
• @nutomic@lemmy.ml of Lemmy
• @bentigorlich@gehirneimer.de and @melroy@kbin.melroy.org of Mbin

[julian@activitypub.space]

@bentigorlich@gehirneimer.de in the relevant issue in Mbin's issue tracker raises a wording concern: "resolvable context" is an unfamiliar term to those who have not read through FEP 7888.

I will update the FEP to make this definition more explicit.

https://github.com/MbinOrg/mbin/issues/248#issuecomment-3741019183

[silverpill@mitra.social]

Hm, it appears that none of my objections have been addressed.

Once again, why there are two activities Move and Remove, and not a simple Update or a new activity type?

[julian@activitypub.space]

Hi @silverpill@mitra.social right;

1. Move and Remove are explicit actions concerning membership of a context in an audience.
2. Update is overly broad and receivers would have to infer audience change based on what the updated object contains (e.g. Audience Y is suddenly missing, and Z is new, was this always the case?)
3. It is likely that sending audience as an array will not be correctly interpreted by existing software, so this property is an unreliable indicator of context audience membership at best
   • Existing threadiverse apps check addresses, and audience may not be used at all in some.

There is no conflict with Move(Person), and I have not heard a convincing reason to adopt a new activity type when these two AS activities work quite well to describe what we want to accomplish.