FEP Convergence (400e, 7888, 171b/Conversation Containers, 76ea)
-
@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.
-
@[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?
-
@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 ⴳreplied to infinite love ⴳ last edited by
@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 ⴳreplied to infinite love ⴳ last edited by
@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 ⴳreplied to infinite love ⴳ last edited by [email protected]
@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 ⴳreplied to infinite love ⴳ last edited by
@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 ⴳreplied to infinite love ⴳ last edited by
-
Scott M. Stolzreplied to infinite love ⴳ last edited by@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. -
@[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.