FEP-5624: Per-object reply control policies

Standards Fediverse Enhancement Proposals
, ,
74

I think this particular one got stalled, but it did spawn some other discussions and approaches:

  • fep/fep/7888/fep-7888.md at main - fediverse/fep - Codeberg.org (discussion) uses the context property to specify a resolvable collection that represents the “thread” or “conversation”. It expects the owner of the collection (currently denoted by attributedTo) to Add objects to that collection. This approach allows for a thread/conversation/topic/etc to be moderated separately from just “direct replies/descendants”.

    • One of the big problems discussed several posts up is that you can “trojan horse” your way into a conversation by replying to someone with less restrictive reply policies, if they reply to one of your posts. Using a context collection solves that.

  • fep/fep/7458/fep-7458.md at main - fediverse/fep - Codeberg.org (discussion) proposes always checking the replies collection instead of implicitly reconstructing one based on all posts you are aware of that contain inReplyTo. Under this proposal, if a replies collection is not specified or doesn’t exist, this maps to the state of “not accepting replies” or “replies closed”. If it does exist and is specified, then you can load the replies to an object on-demand from either your local cache or the canonical origin.

    • Really, the cause of this entire issue of not being able to control what gets shown below your post is entirely social and conventional, not technological. Right now, most implementations simply do not care and do not check any replies collection. If we want to allow any sort of “control” over what gets shown, we NEED to define an “authority” who gets to exercise that control. This is the other big reason that is mentioned upthread for why 5624 got stalled – it is unclear who the “authority” is, whether that is the author of the immediate parent or the author of the “root” of the reply tree.

The astute among you may have figured out an issue with both of these above points: regardless of whether you check a context collection for the thread, or if you check one or several replies collections, you still have to check the collection… there is no “proof” that any given object is contained in a given collection. inReplyTo is not enough to know that it has been added. context is not enough to know that it has been added. Luckily, there is also:

  • fep/fep/0391/fep-0391.md at main - fediverse/fep - Codeberg.org (discussion) is the latest ongoing work being done to develop the concept of a “stamp”, which is an activity that “proves” that some object is included in some special collection. Basically, if you encounter an object with inReplyTo or context, there should be some way to:
    • navigate up to the Create activity that created the object, which should have the result pointing to an Add activity that was caused by the Create
    • alternatively, take an inReplyToProof or contextProof property pointing to an Add activity where the target is inReplyTo.replies or context

I would appreciate any feedback and advise anyone who wants to move forward on the general concept of “reply controls” to participate in any of these discussions, and also call for implementers to change the way that they handle these things. I repeat that it is a matter of convention, not technology, that is causing the issue. Put another way, the issue is not so much of “reply control” as much as it “reply canonicity”. Ditto for any other form of interaction – we have special collections such as likes and shares that share the same logic expressed in this post. In order to be able to decide which interactions get shown, we need our software to first care for and check these collections explicitly instead of relying on implicit reconstruction.

1 Like