@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).
@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 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.
@evan@cosocial.ca in that case if @trwnh@mastodon.social were to relax their restrictions on what context can contain to include both conversational contexts and reply trees, would that be sufficient?
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.
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
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
@scott@authorship.studio Yes. Per 1b12, audience is the appropriate property to use to denote a collection of loosely-related objects. context is 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 Collection when resolved and is referred to in objects via context. The "category" is an Actor when resolved, and is referred to in objects via audience.
As for the other conversation, it honestly seems like you and @trwnh@mastodon.social 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.
@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.
@scott@authorship.studio 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 context and 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.
@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.
@julian The sad thing about this is that we have an opportunity to set the standard here, and we are not taking that opportunity.
Yes, we have to assume that not all platforms will add the additional fields, and we have to have a fallback way of processing incoming posts.
I am just flabbergasted that “thread”: “https://remote.example/thread/117”, is too hard to include with posts distributed by the forum. Even if you don’t use it, some of us might find that to be useful information.
But it appears that I am alone in this, so I will just let it be.
@julian The sad thing about this is that we have an opportunity to set the standard here, and we are not taking that opportunity.
Yes, we have to assume that not all platforms will add the additional fields, and we have to have a fallback way of processing incoming posts.
I am just flabbergasted that “thread”: “https://remote.example/thread/117”, is too hard to include with posts distributed by the forum. Even if you don’t use it, some of us might find that to be useful information.
But it appears that I am alone in this, so I will just let it be.
Hi @scott@authorship.studio, thanks for your thoughts. I took the evening to think it over.
I agree that using thr:thread would be the most explicit way of signalling that NodeBB topics are threads, and if 76ea were to be adopted by a majority of implementors, then I would reconsider. Currently I am on the fence about whether or not I should implement it.
I do want to point out that @trwnh@mastodon.social's FEP 7888 doesn't expressly forbid multiple contexts, and I think upthread they even said that such a use case would not be contrary to the FEP:
based on this conversation i probably need to add examples to fep-7888 of how one might process multiple contexts.
~ trwnh
My opinion today is that when NodeBB uses context, it is doing so to signal that "hey, these posts are part of this collection", and exactly nothing more. It is up to the receiving end to decide how to implement it, and I think that this sort of variety is absolutely wonderful.
If, for example, someone were to see my context and say "I'd like to map this context's objects out into a word cloud and do sentiment analysis on it", I think that's a perfectly cromulent use of the data. For me to say "this here is a thread, and you better treat it as a thread" is contrary to the spirit of ActivityPub and fedidevs in general.
It would be like the ForumWG saying to Eugen, @renchap@oisaur.com, et al. that "we've decided that YOU, Mastodon, need to support as:Listen and render inline players, and playlist support, etc.". That's ridiculous, wouldn't you agree?
If, for example, someone were to see my context and say “I’d like to map this context’s objects out into a word cloud and do sentiment analysis on it”, I think that’s a perfectly cromulent use of the data. For me to say “this here is a thread, and you better treat it as a thread” is contrary to the spirit of ActivityPub and fedidevs in general.
Simply declaring a collection to be a thread does not force people to display it as a thread. But it does provide valuable information to people who do want to display it as a thread.
So you are not removing people’s choice by simply stating that on your platform, this is considered a thread.
If, for example, someone were to see my context and say “I’d like to map this context’s objects out into a word cloud and do sentiment analysis on it”, I think that’s a perfectly cromulent use of the data. For me to say “this here is a thread, and you better treat it as a thread” is contrary to the spirit of ActivityPub and fedidevs in general.
Simply declaring a collection to be a thread does not force people to display it as a thread. But it does provide valuable information to people who do want to display it as a thread.
So you are not removing people’s choice by simply stating that on your platform, this is considered a thread.
Something like this:
{
“@context”: “ActivityStreams 2.0 Terms”,
“thr”: “https://purl.archive.org/socialweb/thread#”,
“thread”: {
“@id”: “thr:thread”,
“@type”: “@id”
},
“root”: {
“@id”: “thr:root”,
“@type”: “@id”
}
“traits”: {
“traits”: “inbox, outbox, conversation, amendable”
}
}This would let me know that it is a thread and that people can follow the context. I can then render it as a thread and potentially add a follow or subscribe button for the context.
You could also declare that it does not have an inbox and outbox, which saves me the trouble of checking myself.