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

infinite love ⴳ

@scott Those are all just lists, though. If you needed more hinting as to what type of collection you're viewing, then you can declare types like Thread or SearchResults or MediaAlbum or whatever. But hardcoding a check for a specific type is fragile.

The only practical consideration is in knowing whether you can submit an object for inclusion (this is the missing bit, we need a property like "can participate"), and where to send it for consideration (attributedTo).

Scott M. Stolz

@infinite love ⴳ Yes, on the backend they are both lists.

But the UI is VERY different for conversations versus lists.

Since the UI is different for conversations and list, I need to know whether it is a thread or a list of random posts so that I can display it correctly.

Evan Prodromou

@trwnh @erincandescent @julian @mikedev @silverpill You haven't been thinking about this problem nearly as long as I have. Who do you think created `ostatus:conversation`?

Anyway, I think we agree on more than we disagree on. We both think `context` should be for general groupings.

We both think the thread identifier should be a dereferenceable collection, and that the original post creator should emit `Add` activities to show that it's been updated.

Evan Prodromou

@trwnh @erincandescent @julian @mikedev @silverpill I think the reply tree is essential and should have its own property so it's easy to find and use, rather than having to guess if what's in the `context` collection is a reply tree. You don't; that's too bad.

infinite love ⴳ

@evan @erincandescent @julian @mikedev @silverpill It’s not about how long one thinks about it, moreso that this idea of “generic data with specific presentations” didn’t come out of nowhere overnight. We shouldn’t overfit our data model to any specific presentation. It would be a great shame to continue privileging inReplyTo above other metadata; it represents a form of context collapse, because responding to something shouldn’t be a stand-in for an actual conversation.

infinite love ⴳ

@evan @erincandescent @julian @mikedev @silverpill Basically, I’ve seen and directly experienced so many cases where a conversation is not and should not be the same as a reply tree, and where conflating the two has created problems on conceptual, technical, and social layers. They exist separately, and have different semantic properties. Consider that someone making a post inReplyTo something else may not actually be participating in the same conversation, or any at all!

Scott M. Stolz

@infinite love ⴳ @Evan Prodromou This is exactly why platforms that have threads should declare that it is a thread. The reply tree does not always indicate whether it is a thread.

If the reply belongs in a conversation container, the container should be mentioned via ActivityPub. That way the receiving platform can display it properly.

(Thread = Conversation = Conversation Container & its Posts)

julian

@[email protected] @[email protected] I have the feeling we're getting too into the woods about defining what exactly a thread or context ought to contain and specifying that those definitions need to persist across all implementations.

I don't think they have to.

NodeBB considers a conversational context as a "topic"/"thread". ForumWG decided to refer to these as "contexts" for ease of discussion, but other software need not follow that paradigm.

If one implementor decided to utilise context to contain only one specific line of objects (a "sacred ~~timeline~~ thread", if you will), I'd argue that's a perfectly valid use of context, and also fits into the definition of both of your FEPs. When they pull a NodeBB context they'll get what NodeBB thinks is a context (the entire reply tree), and that's okay too.

Basically, my argument is that yeah, as Evan said:

Anyway, I think we agree on more than we disagree on.

When we step back and think about what we want to achieve:

Ability to reliably backfill a conversational context
Declare a context owner that acts as a canonical source for context additions/removals (reply limiting and such)

Then what we're left with are three FEPs (7888, 171b, 763a) that all fit the bill but only differ in minor technical aspects.

julian

If we're going to talk about favouring FEPs over minor technical aspects, need I remind you of the following from @[email protected]:

I continue to feel that this general idea is in keeping with the as-written intent of the context property. Adding a new property is likely to make adoption slower and more complicated. Adding a new object type is also likely to make adoption slower and more complicated, but less so than the property.

The more complicated you make something, the fewer implementors you're going to get. I haven't thought about these concepts nearly as long as you two have, but especially when you're talking about volunteer developers who have to work with other volunteer developers, any stumbling blocks could become insurmountable.

Simply put: there's a reason when someone wants to use OAuth2 SSO on NodeBB it's a free plugin, and when they want to hook into their corporate SAML SSO I charge a rather hefty sum.

@[email protected] @[email protected]

Scott M. Stolz

@julian How I view it is:

1. What information is being transmitted now?
2. What information do we want to have?

We will always have to deal with implementations that vary, and we sometimes will have to assume things because they did not send all of the information we need.

But, we can still say "we would prefer the information be sent in this format." especially if that format includes additional information that tells us how to render it properly.

So there is a difference between the minimum amount of information we need and what information we want to have.

Or put another way, we can provide a way in the spec to declare that something is a thread, but still be able to process the data without it (by making assumptions since we are missing some of the data).

Evan Prodromou

@julian I think including the thread in the `context` property is fine; I think saying that the only thing that should go in `context` is the thread is not OK.

If you're concerned about simplicity, having a clear property to use only for the thread is the way to go.

julian

@[email protected] in that case if @[email protected] were to relax their restrictions on what context can contain to include both conversational contexts and reply trees, would that be sufficient?

infinite love ⴳ

@julian @evan That restriction doesn’t exist; technically the collection contains whatever the owner adds to it. Putting `context` on your object is no guarantee your object will end up in there. Neither will `inReplyTo`.

`context` should be used for grouping, but specifically for a *purposeful* grouping. At its base, it’s like a fancy hashtag, but instead of being a simple reference, it imparts meaning and understanding when you consider the object “in context of” it.

infinite love ⴳ

@julian @evan The problem is in social expectations. If I send you an object from a generic AP server that declares “inReplyTo” but a different “context”, it would violate my expectation for that object to end up in a different topic than the one i asked to be included in. But sending it from Mastodon, the calculus changes: Mastodon currently doesn’t support the concept of a reified thread as separate from the reply tree, so NodeBB including that post would be a fallback.

infinite love ⴳ

@julian @evan So the ideal would be signaling on the actor (or jumping ahead in theoretical developments, on the client attached to the actor) that a certain protocol is being followed. That way you don’t have to make guesses and uncertain assumptions.

And then I would ideally be able to send you an object for consideration to include in some collection. It seems reasonable to say that me declaring one of your contexts should be the primary consideration for inclusion.

infinite love ⴳ

@julian @evan But as Evan points out:

> saying that the only thing that should go in `context` is the thread is not OK.

It is possible that any given context may be a Person, or an Event, or a Place, or whatever. (This probably makes more sense in a GTD tasks app than in a forum software.)

It’s also possible it may be an opaque URI.

Nevertheless, if you can’t extract any useful information from it, you drop it from consideration. No owner means no one to address.

infinite love ⴳ

@julian @evan What 7888 tries to do is describe a potential generic framework for how to process objects declaring a `context`, all the way up from the base case (missing) to the simplest case (an opaque URI) and building upwards from there. This is similar to how you might process objects declaring a `tag` array to detect rich entities within the textual content of the post (mentions, hashtags, links, potentially quotes, emojis, whatever the future brings)

infinite love ⴳ

@julian @evan The “missing bit” is a signal for participation; in other words, a property and/or type that means “if i send an object matching a certain shape to the owner, they might add it to this collection.” Right now this is implicit; it would be better if it were explicit.

Scott M. Stolz

@infinite love ⴳ @Evan Prodromou @julian I am working on a fediverse-enabled project management system. And this discussion is very relevant to it, since we are talking about what are contexts and whether they are the same as threads.

Scenario:

Project is an actor.
Forum attached to the project is also an actor.
You can follow both, but one provides updates about the project and the other is a discussion group.

Posts related to the project will have the context set to that project. But that project is not a conversation. The thread is a conversation. And there will be multiple threads related to the context.

If we declare that the post has two contexts, how would you know which one is the thread?

This is why I think there needs to be a clear property that defines a thread.

julian

@[email protected] said in FEP Convergence (400e, 7888, 171b/Conversation Containers, 76ea):

Posts related to the project will have the context set to that project. But that project is not a conversation. The thread is a conversation. And there will be multiple threads related to the context.

If we declare that the post has two contexts, how would you know which one is the thread?

If in your system a single post can be both a response to the project and a response to a thread, and you wish to provide two contexts, then put the more specific context first (the thread), followed by successively less specific contexts (the project).

Implementors that don't support your structure will simply use the first context in the list by assuming it's the most specific.