FEP Convergence (400e, 7888, 171b/Conversation Containers, 76ea)
-
@[email protected] said in FEP Convergence (400e, 7888, 171b/Conversation Containers, 76ea):
i don't know of any forum software that chooses to present threads in reverse order with the newest posts at the top.
I'll bite. NodeBB lets you choose how to sort the posts. Chrono, reverse, or by vote count. Q&A forums might elect to use the latter two. But that's neither here nor there, it's a frontend UX thing and shouldn't really have any bearing on an AP S2S implementation detail.
-
@julian @mikedev @silverpill i generally agree that seeing newest activities is usually preferable , but you could just as easily traverse as:last/as:prev* and stop when you reach something you've already seen, instead of traversing as:first/as:next* and likewise stopping when you reach something you've already seen. it's never made sense to me to mandate reversed order when it should just be the "recommended default". i think the real issue is that OrderedCollection doesn't imply any real order
-
julian:
that's neither here nor there, it's a frontend UX thing and shouldn't really have any bearing on an AP S2S implementation detail
It has bearing on anyone browsing the linked data, as brought up immediately after:
trwnh: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 anOrderedCollection
to have an explicitorderType
ofForwardChronological
orReverseChronological
. i also have a pre-draft of a FEP dealing with collections that are not just ordered sets, but specifically sorted sets. this would defineSortedCollection
as an extension ofOrderedCollection
, as well as defining asortedBy
property pointing to a vocab term, plus asortType
of eitherAscending
orDescending
. there’s Pre-FEP: Evolving OrderedCollection to be more useful as the thread exploring this.Basically, imagine using https://browser.pub (or any other Web browser, really). The representation you serve in response to any GET request should be usable without requiring additional processing. You should be able to follow links normally like any other browser. This is the foundation of linked data.
-
@julian @silverpill @trwnh @erincandescent @mikedev @[email protected] obviously `context` isn't good enough to identify the thread relationship. Trying to hijack it is contrary to the AS2 spec and common interoperability. One proposal tries to specify it by duck-typing every object; the other by defining a new Collection type. The clearest way to define the relationship is with a property, `thread`, which is specific, clear, and requires no other changes.
-
Evan Prodromoureplied to Evan Prodromou on last edited by
@julian @silverpill @trwnh @erincandescent @mikedev I think most developers understand that the reply tree and the conversation are identical. The use cases a describes -- forking, etc. -- can be implemented with `Announce`, perhaps with `content` in the `Announce` activity. I'll add these next week and push a new draft.
-
@evan @julian @silverpill @trwnh @mikedev "context" isn't good enough to identify any relationship; this is the fundamental problem. It is a property that should never have existed. Today it identifies one relationship: the (loosely defined) thread. I would argue that this is in fact "common interoperability". I would also argue that this fully meets the incredibly vague letter of the ActivityStreams specification.
I have yet to see an alternative use of context that would not be better served by inventing a more specific term. Yes, this applies to use of context for thread too, but we have 7 years of its user to identify the thread as a defacto standard. -
@erincandescent @julian @evan @mikedev @silverpill i don’t think “conversational thread” is a special semantic relationship, and i certainly don’t think it is equal or equivalent to a reply tree! the basis of 7888 is that context should be used for purposeful logical grouping, as it was intended and as it ended up being used in pleroma for years. an unresolvable opaque uri is 7888-compliant. so is a collection with an owner. so is anything else. but IF it is a collection,
-
infinite love ⴳreplied to infinite love ⴳ on last edited by
@erincandescent @julian @evan @mikedev @silverpill …then it makes sense that the collection ought to contain items sharing the same contextual grouping. it’s similar to how hashtags are content-addressed grouping, but less purposeful, and no one owns them. the key is that even if you can’t resolve anything out of whatever is in context, you can still use it for grouping by opaque string matching. so there’s clearly defined graceful fallback.
-
Evan Prodromoureplied to Evan Prodromou on last edited by
@julian @silverpill @trwnh @erincandescent @mikedev I think `context` can be used as a fallback, which provides continuity for most of the legacy implementations.
-
infinite love ⴳreplied to infinite love ⴳ on last edited by [email protected]
@erincandescent @julian @evan @mikedev @silverpill as far as reply trees go, it should be clear that they are not the same as a conversation or context, and inReplyTo exists completely separate and parallel to contextual grouping. the “reply tree” model falls apart the second you reply to multiple things, or reply to something in a different context, or reply and change the context, or set a context but no inReplyTo. i’m not sure why you say Announce has anything to do with it
-
Evan Prodromoureplied to Erin 💽✨ on last edited by [email protected]
@erincandescent @julian @mikedev @silverpill @trwnh there are other uses called out in the AV spec. Someone using those would clash with the use for threads.
I recognize your aversion to change, but "don't change anything" isn't on the menu. We need a way to identify the thread relationship, and a dedicated property is much better than duck-typing objects or making a new collection type.
-
Evan Prodromoureplied to Evan Prodromou on last edited by
@erincandescent @julian @mikedev @silverpill @trwnh we have many orders of magnitude more AS2 objects in our future than in our past. I don't think informal practices of existing software should keep us from implementing better formal systems in the future.
-
infinite love ⴳreplied to Evan Prodromou on last edited by
@evan @erincandescent @julian @mikedev @silverpill what is the “thread relationship” and how does it differ from “contextual grouping”?
-
Evan Prodromoureplied to infinite love ⴳ on last edited by
@trwnh @erincandescent @julian @mikedev @silverpill reply tree
-
@julian
reverse chrono for activities is preferable, and that makes sense if you want to sync up. Just retrieve activities until you reach one you've seen and you're caught up.
I wouldn't necessarily trust that. I have seen too many instances of incomplete threads being saved locally, and having to go to the source website to see the whole thread. These missing posts can be a pain, because unless the website supports OpenWebAuth, you can't reply to a comment that was not saved locally on your server. -
Scott M. Stolzreplied to infinite love ⴳ on last edited by@infinite love ⴳ
Three use cases some to mind concerning collections and context:
1. Threaded conversations.
2. Collections of posts.
3. Categorizing posts (by topic, for example).
I am not sure if this feature still exists, but I remember when Twitter allowed you to place other people's posts into a publicly sharable list. It was a collection of posts curated by someone, but was not a thread.
I don't know of any fediverse app that currently implements such a thing, but I just wanted to point out that collection and context can be used for things other than threads.
Another use case is placing posts in categories, or place entire threads in categories.
So we probably should explicitly state that something is a thread or conversation... as opposed to a list of random posts on a particular topic. -
Evan Prodromoureplied to infinite love ⴳ on last edited by
@trwnh @erincandescent @julian @mikedev @silverpill I have an example of a reply to multiple things in the FEP.
"Comment but don't participate in thread" is a quote boost. It also works for forking to a new thread.
So, that's what `Announce` has to do with it.
Conversation threads are *usually* reply trees, and we should optimize for that easy base case. The advanced tree-pruning and -grafting you describe are possible with a reply tree.
-
infinite love ⴳreplied to Evan Prodromou on last edited by
@evan @erincandescent @julian @mikedev @silverpill
> Conversation threads are *usually* reply trees
this is an anti-pattern. conversations are only represented by reply trees when there isn't an actual conversation. reply trees are a poor substitute for that.
> "Comment but don't participate in thread" is a quote boost.
i'm talking about participating in a thread without responding explicitly to anything. or responding to something, but in a different thread. no one is boosting anything.
-
infinite love ⴳreplied to infinite love ⴳ on last edited by
@evan @erincandescent @julian @mikedev @silverpill boosting, replying, and grouping are three completely separate functions. the Announce could have its own inReplyTo and/or context.
-
Evan Prodromoureplied to infinite love ⴳ on last edited by [email protected]
@trwnh @erincandescent @julian @mikedev @silverpill
Maybe we need to agree that we are talking about different things.
I think that `context` is great for a related collection of objects, including for a project or event, as defined in AV.
For the specific collection of objects that are members of the same reply tree, we can use `thread`.
If it doesn't matter to specify that it's a thread, you can link to the exact same collection with `context`. It is, after all, also a related collection.