Does context in AP have to be a collection, or can be be like a Flag activity? Say I wanted to Create(Note) about a Flag I'd received, I'd need
-
@infinite love ⴳ And this continues to have nothing to do with threads.
You are so wrapped up in reply trees that you refuse to acknowledge that threads are a distinct type of list.
And based on some of your comments, I get the distinct impression that you are actually against the idea of having threads. Or that you have never used usenet, email, forums, Facebook, or any other platform that uses threaded conversations. But I will give you the benefit of the doubt and assume you just are against the idea of threads.
Yes, you can get the whole (or most) of conversation from the reply tree. We know that. That is how most platforms do it today.
I want to know what the thread is (the moderated version of the conversation) for different reasons, which I have stated over and over.
So, I will simply chalk up your refusal to acknowledge threads as being a valid way to organize and moderate conversations as a philosophical stance.
If so, I will respect that. But don't expect other platforms to think like you do.
Because everything you have stated is consistent with Mastodon, not forums nor threaded conversations. And the way you want to implement things ignores some of the main benefits of having moderated forum communities. -
@scott It’s *the web*, not Mastodon. I’m not opposed to threads, I’m just saying that they necessarily work differently when you have resources split across multiple authorities. Post owners own their posts on their own domain. Posts can *claim* to have been created in a certain context, but unless you reify that context as a collection with items, you have no authoritative origin to check for what officially got added. The problem is in Mastodon et al *never checking any collections*.
-
infinite love ⴳreplied to infinite love ⴳ last edited by [email protected]
@scott Even with reply trees, Mastodon et al will only ever use inReplyTo. They ignore the “replies” collection. This bypasses the authority of every post author to get to decide which responses they want to acknowledge and which ones they don’t. The other issue is that they don’t recognize a “conversation” or “context” as an actually existing reified object. At best, it’s an opaque string hint that you can search your database for and reduce your search space for a reply tree.
-
@scott So the way forward is to:
- recognize the concept of a “conversation” or “conversational context”
- start declaring that posts are not standalone and that they exist in some “context”
- reify that “context” as a collection that has canonical items
- give the context collection an “owner” or “moderator” who chooses what goes in and to whom you can send objects for consideration
- stop taking post metadata at face value and actually verify the information you’re trying to present to users -
@scott but in all of this, you have some invariants:
- the post owner owns the post
- the collection owner owns the collection
- any collection may contain any post, without it being a context
- context is something that the post author “declares”; the collection owner “fulfills” this declaration by adding the post to the canonical collection representing the conversational context
- a third party browser/consumer/processor cannot assume that an object is contained in a collection it implies. -
@scott For example, “inReplyTo” does not imply membership in any “inReplyTo.replies.items” if present. “context” does not imply membership in any “context.items” if present.
If the post exists in one or more contexts, then for most intents and purposes you can ignore the post and navigate away from the post and to any one of those contexts; if it is an OrderedCollection, you can render its items in a flat list by whatever canonical ordering is provided for you.
-
@scott But the way you render that OrderedCollection as a flat list is actually not as important as you’d think. In that sense, there is no significant difference between rendering it in the UI of social media, or of forums, or of messengers or chat rooms, or of something else entirely. At the end of the day, it’s a flat list of posts in a given order. The collection owner can hint to what they *intend* it to be, by declaring a type like ConversationContainer or TwitterMoment or whatever else.
-
@scott In this case, ConversationContainer might define that the collection owner is expecting you to send posts to them to be added; TwitterMoment might define that the collection owner is just curating some posts they found interesting, and that they will not be considering any posts you send them.
In the absence of a “send” or “don’t send” signal, we generally assume “send” if the context resolves to a collection with an owner and that collection does indeed contain the post (“verified”)
-
infinite love ⴳreplied to infinite love ⴳ last edited by [email protected]
@scott but here’s the thing: by definition, it is generally invalid to declare a TwitterMoment as your “context”, because in reality you are not creating your post only to be considered as part of that TwitterMoment. So in most practical cases, you can generally assume that any context collection is in fact sufficiently considered a “conversational context”. 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
-
@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 What you've described sounds like what I've described, and might even be mostly the same thing. Basically, if an object declares a context, and if that context is a collection, you can just navigate to that collection and start browsing its items, *ignoring the object you started with*. If it's really in the collection, the collection will tell you.
Then, if it has whatever other properties you consider necessary to be a "conversation container", you can render the collection as one.
-
@scott The way "post moving" gets handled is probably with a Move activity, which is both delivered to the author(s) of moved posts, as well as quite possibly added to the conversation collection in some systems. For example, Discourse will show users in the middle of a thread that "moderator moved 6 posts to other topic". This means that even if the post author never understood the Move, anyone "following their nose" has a way to get to the "new" conversational context.
-
@scott In any case, I recognize I've got a lot of examples I need to add to the FEP. The Move stuff probably goes in a new FEP though. Step 0 is getting implementers to recognize the concept of a conversational context at all.
There's also the *possibility* of it being useful to define a dedicated type like ConversationContainer, Conversation, etc. to hint the intention of the collection. This is also something I want to follow up on in a separate FEP.
