FEP Convergence (400e, 7888, 171b/Conversation Containers, 76ea)

Evan Prodromou

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

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

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

Evan Prodromou

@trwnh @erincandescent @julian @mikedev @silverpill reply tree

Scott M. Stolz

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

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

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

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

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

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

infinite love ⴳ

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

infinite love ⴳ

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

infinite love ⴳ

@evan @erincandescent @julian @mikedev @silverpill Sure, it's possible to declare both a `context` being whatever grouping, and a `thread` being specifically a reply tree. (Perhaps `thread` should be renamed to `replyTree`, and `root` should be renamed to `replyTreeRoot`?)

I'm specifically against conflating the two concepts, though. I also would prefer to not give `inReplyTo` any undue deference beyond simply being metadata. For as many systems that rely on it, there are systems that don't.

infinite love ⴳ

@evan @erincandescent @julian @mikedev @silverpill For example, replying to a message is something that the user *explicitly chooses* to do when in the context of image boards or chat rooms. If you've ever used Discord, then you can see how in that system, it wouldn't make any sense to say that every message in a channel necessarily must be inReplyTo some other message in the channel (or anything at all). The room is a bound context.

Evan Prodromou

@trwnh @erincandescent @julian @mikedev @silverpill sounds great.

I'm going to stick with `thread` and `root`.

They're already namespaced, and these are clear terms for these concepts.

Thanks for the help with additional use cases on forking and grafting. I'm going to add some explicit user stories to the FEP and show how each one can be handled.

Evan Prodromou

@trwnh @erincandescent @julian @mikedev @silverpill yes, I absolutely agree that a chat room is topologically different from a forum thread, a Reddit post, or a social network.

Evan Prodromou

@trwnh @erincandescent @julian @mikedev @silverpill I would represent a chat room as a `Group`.

infinite love ⴳ

@evan @erincandescent @julian @mikedev @silverpill One thing to note: If the AS2 context extension policy ever gets adopted and these terms likewise get adopted into the w3.org/ns/activitystreams context document via that process (or any other process), then this creates an issue for any other case where someone wants to use the plain-JSON keys `thread` and `root`.

infinite love ⴳ

@evan @erincandescent @julian @mikedev @silverpill

1) I disagree; chat rooms, forum threads, comments sections, etc. are all just different presentations of the same generic data structure (objects in collections). I could pull the AS2 data for this entire chain of replies and render it as a chat room, or as a messenger, or however I wanted to -- flat chronological list or otherwise.

2) I would use `Group` to represent an actual group of agents. For a group of posts, I would use Collection.

Jenniferplusplus

@trwnh @evan @erincandescent @julian @mikedev @silverpill
This conversation is hard to follow, since Evan blocked me for some reason. It makes this a notably bad venue to have these technical discussions with him.

But for what it's worth, I agree with all of your analysis and conclusions on this topic.