FEP Convergence (400e, 7888, 171b/Conversation Containers, 76ea)
-
@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.
-
@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 ⴳ @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.
-
@julian
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.
That's a good fallback behavior, but there still should be a way to explicitly declare which is the thread for platforms that support it. -
@julian @scott to start with, i don’t think it’s necessarily correct to say that the post was created in context of the project; you might want to say that the post was created in context of a discussion topic, which itself exists in context of the project. but it’s up to the post author how they want to declare this.
the other thing is, consider the case where there are two contexts, and they’re *both* threads. by which i mean, all the necessary properties are there. //
-
@julian @scott Anyone wanting to respond to that post has the following options:
1) inReplyTo post, context = 1
2) inReplyTo post, context = 2
3) inReplyTo post, context = 1,2
4) inReplyTo post, context = something else (or nothing)and then they deliver to the owner(s) of whichever context(s) they selected.
Or maybe they don’t want to respond. Maybe they want to participate without specifically responding to anything else in either thread. So they drop inReplyTo. //
-
@julian @scott anyway, situations with multiple contexts are probably going to be edge cases.
honestly, the most likely outcome will be that implementers will just incorrectly assume a max of 1 context, just like they already incorrectly assume a max of 1 inReplyTo. in this case, the restriction becomes part of the implicit protocol, alongside numerous other stated or unstated restrictions.
-
@infinite love ⴳ @julian @Evan Prodromou So, basically, we are saying that:
Context = Conversation = Thread
because everyone assumes that is the case.
And anything not a thread should probably be something else, like a collection?
Because, at least in every forum implementation I have ever seen, there is only one thread. And like everyone else, we will only support ONE thread.
Therefore it is unnecessary to support multiple threads because nobody plans on supporting it and it goes against 40 years of usage.
But, posts and threads can be associated with other things, like projects, that are NOT a thread, but rather a collection of related posts.
The question is: how do you associate non-threads (like projects) with a threaded conversation? -
@[email protected] I think I know how that one can be solved.
Using Hubzilla nomenclature:
- When you have a post it defines the thread as
context - Your post can also define the project as
audienceas per FEP 1b12 - The thread (the context collection) would define the project as the collection owner (
attributedTo)
- When you have a post it defines the thread as
-
@julian Would an audience be appropriate for a collection of threads & posts?
Also, the project won't be the owner, since any post on our system can be flagged as being associated with one or more projects. It will be a collection of random threads and posts that happen to be related to the project.
The whole idea is that we can tag threads as being related to a project, no matter what forum or channel they came from.
The collection can then be queried and a list of related threads and posts would be provided.
Also, as a side note, the project management system will be headless. One of the heads will be Hubzilla, but we may create a non-Hubzilla based head later. -
To give you an example:
Here is a thread (conversation with a topic):
#^https://community.nodebb.org/topic/18364/fep-convergence-400e-7888-171b-conversation-containers-76ea
Here is a collection (a list of posts labelled "Forums and Threaded Discussions Task Force"):
#^https://community.nodebb.org/category/31/forums-and-threaded-discussions-task-force
Notice how they are rendered completely different.
A collection is NOT a thread. And some apps need to know which is the thread so we can render the display properly. -
Reposting here, since the conversation got sidetracked onto Mastodon.
@infinite love ⴳMost contexts are multi-faceted in this way. #^https://w3id.org/fep/7888#the-different-types-of-context-and-how-they-are-actually-the-same
Yes they are. But, as I said, there are practical reasons for wanting to retrieve the conversation container (forum thread, social media thread, chat thread, etc.) as opposed to the reply tree.
The biggest practical reason is delegation of moderation. In order to limit spam, trolls, and off-topic discussions, the owner(s) of the conversation container (thread) will moderate content by removing it from the conversation container, moving it to another conversation container, or flagging it in some way.
If @julian spots a spam post on NodeBB, he can delete it. And if I retrieve the conversation container (thread) that NodeBB places the posts in, I will get the moderated version of the thread without the spam. If I parse the reply tree, I get the spam even though Julian deleted it.
It also helps keep conversations together when the forum moderator moves a post to a different thread. If you follow the reply tree, the post would appear in the wrong thread.
If you want threaded discussions to behave like threaded discussions over ActivityPub, you need to provide additional information that allows that to happen.
cc: @Evan Prodromou -
@[email protected] Yes. Per 1b12,
audienceis the appropriate property to use to denote a collection of loosely-related objects.contextis ideal for closely-related objects (like ones that share a reply tree, but that doesn't rise to the level of a requirement), like posts in a context (topic/thread).In your examples, the "thread" is a
Collectionwhen resolved and is referred to in objects viacontext. The "category" is an Actor when resolved, and is referred to in objects viaaudience.As for the other conversation, it honestly seems like you and @[email protected] are splitting hairs and really want the same things.
-
@julian The sticking point is basically whether I should guess what the thread is, or be told what the thread is.
He wants me to perform a bunch of tests and guess; I want it to be declared.
I am not sure what you are going to do when there are multiple collections associated with a post. Because unless the thread is declared, you won't know which is which. -
@[email protected] said in FEP Convergence (400e, 7888, 171b/Conversation Containers, 76ea):
I am not sure what you are going to do when there are multiple collections associated with a post.
My plan is to take the first item in
contextand treat that as the most narrowly scoped collection containing that object. The assumption is that the contexts are ordered from narrow-to-wide. Whether or not additional contexts would be helpful is irrelevant to me, as I am converting this object into a NodeBB topic only.You can make arguments that this is not correct. I will not disagree. I will simply say that, like it or not, this is the simplest form of compliance most implementors will opt for.
-
@julian If that is how you want to do it, I respect that. But I do find it odd that the FEP actually has a field for thread and nobody plans on using it. But, most platforms either have 1 context or 0 contexts, so it makes sense.
I still haven't decided how I will do things with my fediverse-enabled project management system. At some point, there will probably be multiple contexts. If that is the case, I probably will put the thread as the first context and then also declare what the thread is using FEP 76ea or something similar.
That way, at least with my project, you won't have to guess which one is the thread. And since your platform only has one context, then I won't have to guess either.
