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
-
@[email protected] that's fair, I don't know how we handle federating flag reports right now (as @oplik0/@[email protected]) handled that aspect.
Having the context contain the individual notes regarding a flag would also work.
-
@julian @oplik0 @opliko I'll have to take a look for: https://github.com/swicg/activitypub-trust-and-safety/issues/14
-
infinite love ā“³replied to Scott M. Stolz last edited by
@scott i still donāt think āthreadā is anything special or different than āgroup of posts bound together by a topic and audience and owner that you can submit your post to for consideration of being addedā. if anyone can come up with a proper semantic definition of āthreadā then iāll consider revising my definition, but asking āwhich one is the threadā is a bit like asking āwhich one of these recipients is the audienceā, or like saying you only work with Note and not Article.
-
infinite love ā“³replied to infinite love ā“³ last edited by
@scott like, you could define a type Conversation that the creator of the āthreadā specifies when creating the āthreadā. but this type doesnāt change any of the processing considerations for anyone wanting to participate. it just hints the authorās intention.
the one thing it *might* also do is signal that a certain protocol is in place, for example, something is a āfep-xxxx Conversationā might come with additional restrictions or requirementsā¦ but you still need the other props to be present.
-
infinite love ā“³replied to Jenniferplusplus last edited by
@jenniferplusplus @thisismissem i think youāre in luck because itās at least guaranteed to be 1. thatās the āintended usageā per the spec and per how it got implemented.
2 requires you to be able to dereference that stable id from 1, but it doesnāt require any specific type or repr. it just needs an owner and some properties signaling who can participate and how.
3 requires the dereferenced object in 2 to specifically be a collection.
Flag as context works for grouping but not backfilling.
-
Scott M. Stolzreplied to infinite love ā“³ last edited by@infinite love ā“³ The biggest difference is that one is a conversation, with people replying to each other. The other is a list of random posts, most likely curated by a third party, and that may contain multiple threads.
Unlike Mastodon and other non-threaded platforms, on a forum, it is expected that EVERYONE in the conversation can see all of the posts in that conversation. It is a group experience in which everyone has context surrounding the conversation.
Compare that with random curated lists where posts and threads are taken out of context and added to a list. You can have multiple threads, individual posts, even other actions like likes and votes.
So the biggest difference is, not ironically, context. -
infinite love ā“³replied to Scott M. Stolz last edited by
@scott if itās ārandom postsā then it wouldnāt be a context, it would just be a collection. context requires purpose. the person authoring the object declares a context (or contexts) as a way to signal why their object exists. objects donāt exist to be added to random collections.
basically thereās two sides to it. the post author chooses which context(s) they want to declare. and the context owner(s) choose whether to add that post.
the browser can load any context they want to browse.
-
infinite love ā“³replied to infinite love ā“³ last edited by
@scott when it comes to participating in a āthreadā, you donāt do this from the object view. you need to navigate to the collection view first. itās up to any individual actor to decide which (if any) context(s) they want to consider a āthreadā or not.
-
Emelia šøš»replied to infinite love ā“³ last edited by
@trwnh @jenniferplusplus yeah, and jn the context of comments on a Flag that are directed at you, I don't believe there'd be a need to backfill?
-
Here is an example:
id: post 1
context: thread-1, project, flag-a
id: post 2
context: thread-1
id: post 3
context: thread-2, project
id: post 4
context: thread-2, flag-b
id: post 5
context: project, thread-3, flag-a
etc.:
How do I know which one is the conversation that is displayed on the forum? -
Here is an example:
id: post 1
context: thread-1, project, flag-a
id: post 2
context: thread-1
id: post 3
context: thread-2, project
id: post 4
context: thread-2, flag-b
id: post 5
context: project, thread-3, flag-a
etc.:
How do I know which one is the conversation that is displayed on the forum?
@infinite love ā“³ Or more specifically, how do I know which is the official moderated version of the conversation according to the forum? -
infinite love ā“³replied to Scott M. Stolz last edited by
@scott whichever one declares the requisite properties (owned by the forum or some mods on it, scoped to an audience, contains "post" objects bound to a context, etc.) -- if there are any missing properties that you consider "required", then you drop it from consideration.
for example, maybe you consider the "thread" as something special that needs to be declared, e.g. as a ConversationContainer, but i think that's needlessly limiting and not backwards-compatible with unaware implementations.
-
infinite love ā“³replied to infinite love ā“³ last edited by
@scott the core functionality is the grouping of posts by their topic or shared context. the "trick" is that if it's a collection, it's actually entirely up to the owner to decide what goes in there! i could create a collection, declare it to be a ConversationContainer, but then start adding unrelated posts. actually, as the owner, i get to decide what's related and what's not! maybe i require context to be set. maybe i require inReplyTo. maybe i have some other criteria. ideally, i signal this.
-
infinite love ā“³replied to infinite love ā“³ last edited by
@scott so the collection has some "participation criteria" which describes the shape of what i deem worthy of potentially Adding. for example, i could say that
- object.content must be present
- object.attributedTo must be present and included in the Collection.audience
- object.context must include Collection.idbut this is advisory at best. i reserve the right to add objects that don't match this shape.
i also can hint how i think the collection should be displayed, but this is only a hint.
-
infinite love ā“³replied to infinite love ā“³ last edited by
@scott the point i'm trying to make here is that, in an open world system, there are limits on what you can enforce or expect. it's always possible that you will encounter something that breaks your expectations, so make as few expectations/assumptions as possible.
the idea of a "thread", when broken down to its core semantic ingredients, is not significantly different than "a group of posts bound by some common key characteristic". structure is created within that grouping.
-
Scott M. Stolzreplied to infinite love ā“³ last edited by@infinite love ā“³ You also have to consider that most systems may get duplicate versions of the same post from different sources.
For example, if I am following someone and following the forum, I will be sent one copy from the person I am following, and one copy from the forum. The forum will have a context attributed to the thread, and the other version will not.
Since the forum sends a copy of all of the posts in the thread directly to followers of the forum, you don't even need to process the reply tree. Just look for the context that indicates the thread and show all posts marked with that context. Any post without that context has been moderated out of that thread.
If you want to utilize the moderators of the remote system, you have to display only what they approved to be in the thread. If you don't care what the moderators on that other system think, you process the reply tree instead, and only use the context to backfill the conversation.
To minimize spammers and trolls, you drop any post that does not belong to that context (the moderated forum thread) and/or does not belong to someone you follow.
You don't have to do that and can let anything in the reply tree through, but if someone is already moderating a thread, that's less work for me. -
infinite love ā“³replied to Scott M. Stolz last edited by
@scott
> The forum will have a context attributed to the thread, and the other version will not.The forum doesn't have permission to modify the author's post. It can only send an Add and/or Announce.
Instead, any consumer wanting the "moderated version" needs to either fetch a collection's items directly, or establish proof that any item was Added to the collection. If you can't prove this, you hide or drop the post as "unverified".
This continues to have nothing to do with reply trees.
-
Scott M. Stolzreplied to infinite love ā“³ last edited by@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. -
infinite love ā“³replied to Scott M. Stolz last edited by
@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.
