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 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.

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 @jenniferplusplus@hachyderm.io 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.

@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,

@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.

@julian @silverpill @trwnh @erincandescent @mikedev I think `context` can be used as a fallback, which provides continuity for most of the legacy implementations.

@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

@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 a duck-typing objects or making a new object type.

@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.

@evan @erincandescent @julian @mikedev @silverpill what is the “thread relationship” and how does it differ from “contextual grouping”?

@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.

@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.

@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.

@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.

@evan @erincandescent @julian @mikedev @silverpill boosting, replying, and grouping are three completely separate functions. the Announce could have its own inReplyTo and/or context.

@trwnh @erincandescent @julian @mikedev @silverpill

Maybe we need to agree that these two properties are different.

I agree 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.

@scott yes, this can generally be accomplished by defining vocab terms for each type of collection, representing its purpose or classification -- for example, Context / Conversation / MediaAlbum / CuratedMoment / whatever. these are moreso progressive enhancements, though -- if you follow a link, then the link relation is usually enough information to know where you're going, if not necessarily enough to know what you've arrived at. a category is not always a context; context implies purpose.

@scott for example, a blog post is in one or more categories/tags/taxonomies, but the blog post does not exist purely within any of those groupings. generally if something exists in a context, you are less interested in that thing and more interested in the context in which it exists. the context provides a reason or purpose for that object; you can group all objects that share the same context and end up with some cohesive understanding of something.