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:

1) A way to address the remote moderation team (moderation group actor)

2) A way to say "this note is about this Flag activity", using inReplyTo would feel weird here, but maybe context would work?

@Emelia I thought it could be used for that until I participated in a discussion about threaded conversations.

#^https://community.nodebb.org/topic/18364/fep-convergence-400e-7888-171b-conversation-containers-76ea

If I am understanding them correctly, they are claiming that context should be assumed to be a thread and not used for anything else.

cc: @julian @infinite love ⴳ @Evan Prodromou

@scott hmmm, I guess context is completely undefined right now, so am wondering if it'd make sense to just use it. "these Notes exist in the Context of this Flag activity"

@scott nope, context can be anything; it doesn't have to be a collection. it's only a thread *if* it has whatever properties you consider necessary for a thread (e.g. an owner, items, and some signal that you can participate)

for the example of Create Note regarding a Flag, i'd use inReplyTo because you are responding to the report, no?

cc @ThisIsMissEm @julian @evan

@thisismissem @scott you could do that if you wanted the notes to be grouped around that Flag activity

@trwnh @scott @ThisIsMissEm@mastodon.social @julian @evan

I wanted to avoid inReplyTo since subsequent replies wouldn't share the same parent, i.e., Flag -> Note 1 -> Note 2

Note 2 would be inReplyTo Note 1, but both would be in the context of Flag

@thisismissem@hachyderm.io @scott @ThisIsMissEm @julian @evan makes sense to me

@thisismissem semantically, yes, it can be a flag or anything else you want. Functionally, for real world implementations? ‍️

I'm trying to think through what letterbook would do, and I suspect it would do the right thing. At least at the point of receiving the message. I would need some logic in reports to connect them back to that context, but i think that's likely to be straight forward

@thisismissem what I really want is context to be

1. A stable identifier that I can index
2. An indicator of whether and how reply control is implemented
3. A collection of related content-like objects, if reply control is implemented

In that order.

I think using a Flag (or its ID) satisfies that

@infinite love ⴳ

nope, context can be anything; it doesn't have to be a collection. it's only a thread *if* it has whatever properties you consider necessary for a thread (e.g. an owner, items, and some signal that you can participate)

The problem is that there is an assumption that things with those traits are a thread, which is not necessarily the case.

If you have a thread and a collection that can both be participated in, then how will you figure out which is the thread and which is the collection? As I stated before, there should be a way to specify which context is a thread instead of just assuming based on some random traits it might have.

@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.

@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.

@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.

@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.

@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.

@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.

@infinite love ⴳ That is not how every single forum and threaded social media app works. For every single one, there is only ONE thread, always, end of story.

People cannot choose what thread a post belongs to. If you reply to a post on a forum, your post becomes part of the thread, period, end of story. You have no choice. It is automatic. That is how forums work.

You do not have a choice of context, unless you place the post in a list that is not a thread. That is the ONLY time you have a choice of context. And that is only if you created the list yourself.

@scott well, i disagree with that definition of "thread". you can respond outside of a thread. you can have more than one thread. and it should always be your choice when and how these things get decided. "you have no choice, it is automatic" is incredibly user-hostile.

@infinite love ⴳ You would have to change how every forum and threaded conversation system works, because replying to a post within a thread always places it in the thread.

There are logistical reasons for this. It allows moderation at the thread and forum levels. A post can be removed from the forum or the thread by forum moderators, and it disappears from the forum. The person who posted still has the original and can forward that to anyone they want, but it won't appear in the forum any more and won't be distributed by the forum anymore.

It is similar to having a guest in your house. You can ask the person to leave at any time. That is the nature of forums, which are moderated communities. It is a complete different paradigm that the free-for-all that is Mastodon and Twitter.

It is also why you have to join most forums, and they can prevent you from posting in the forum if you are not a member of the forum. It's their territory. Their home. If you want unmoderated distribution, you post on your own timeline instead of someone else's thread or forum.

User-hostile or not, that is how forums and threads work, and have worked for 40 years. The fact that you seem surprised by this explains why you don't seem to understand why a thread is different than a collection.

@scott you can moderate at the thread or forum levels without any post ever being explicitly inReplyTo any other post. inReplyTo is completely optional, and completely separate.

"this is how it works and has always worked" is regressive. if we were building centralized forums in the vein of the past, maybe it would be okay. but we're building a decentralized social web for the future. we need to broaden our view of what's possible. and we need to recognize the choice that any publisher has.