from my understanding, only 7888 and 171b do this. 76ea instead tries to establish a central view of a reply tree, which is not the same as a conversation. there are several cases where replies and context diverge:
- replying to something in a different conversation (for example, when conversations get forked or posts get moved to a new conversation)
- participating in a conversation without replying
- replying without participating in a conversation
also, there is the consideration that context is used for grouping, even if it’s not resolvable. so it gracefully falls back to basic grouping behavior in the simplest case. thr:thread doesn’t do this.
you can send a Remove in all three FEPs, it might just not be called out explicitly. the use of Add/Remove is a courtesy to anyone else following along, so they don’t have to fetch the collection manually every single time. (although fetching the collection every single time is inefficient, it is the only way to have a guaranteed consistent state, so there are reasons why you may want to browse the collection “at the authoritative origin”, so to speak.)
i am not strictly opposed to this, but neither do i support it. it might end up being useful to define a type that means “this specifically represents a collection whose items share the same context property” (as i think Context is trying to do), but this should not be required.
similarly, we could define a type that means “this specifically represents a collection whose items all have content” (we could call it Conversation or CollectionOfPosts or CollectionOfContentfulObjects or whatever) but this is similarly something that shouldn’t be required.
the reason that i think such types shouldn’t be required is that not only are they not necessary for the basic mechanisms to work, they also might be misleading or incorrect, because ultimately the contents of any collection are solely decided by whoever owns the collection. i could declare that a collection is a Context and then immediately after this i go and Add a bunch of objects that don’t have that context, or any context at all for that matter. this is something that is going to be very relevant in the interim where NodeBB and similar implementations continue to have behavior for traversing reply trees and attaching posts to topics that aren’t explicitly declared as context. (not that i think this behavior is necessarily always correct, either – it’s just something that could be done, and is probably useful to do, insofar as other implementations continue to remain unaware of context and its grouping properties. you could just as equally convert posts with inReplyTo but no context into NodeBB Chat Messages instead of NodeBB Topic Posts… but this is an implementation decision.)
7888 is agnostic as to what the exact contents are, aside from them ideally all sharing the same context – you could have a 7888 collection contain any type in any order. however, with that said: i favor post objects (anything that has content) in forward chronological order, because this is what is most useful to the casual browser. i don’t know of any forum software that chooses to present threads in reverse order with the newest posts at the top. they usually do this for topics, but not for posts.
also: these are “defaults”, and ultimately we should probably move toward explicitly signaling how collections might be ordered or sorted, as well as providing a mechanism for requesting non-default presentations like “show me this thread in reverse chronological order” (?reversed=true or ?sort=newest or whatever) or “show me posts starting at index 69 and containing 7 items” (?startIndex=69&window=7). to that end, i recently submitted fep/fep/1985/fep-1985.md at main - fediverse/fep - Codeberg.org for declaring an OrderedCollection to have an explicit orderType of ForwardChronological or ReverseChronological. i also have a pre-draft of a FEP dealing with collections that are not just ordered sets, but specifically sorted sets. this would define SortedCollection as an extension of OrderedCollection, as well as defining a sortedBy property pointing to a vocab term, plus a sortType of either Ascending or Descending. there’s Pre-FEP: Evolving OrderedCollection to be more useful as the thread exploring this.
regarding the signaling of any given collection or actor following a specific protocol, i think we should define that explicit protocol before defining types. my old draft of FEP-9988 for “Federated Forums” was put on hold for exactly this reason – there are simply too many protocol considerations that need to happen first. Desired UX for forums, and accompanying user stories or Desired UX for forums, and accompanying user stories | NodeBB Community exists as a thread to collect user stories for forum UX that should directly inform the development of such a protocol.