@infinite love ⴳ True. With incoming posts, you will need to decide how to handle missing information, and decide if it goes into a certain context or thread.

After processing incoming activities and posts, the collection is amended, as appropriate. And internally, you may mark these as part of the context or thread in your own database to make it easier to query.

But one thing is unique about forums: It redistributes the posts to its members. So all outgoing posts sent by the forum could have the appropriate context(s) attached to it.

Since the collection has already been constructed and amended after processing new activities, that collection now becomes the de facto representation of what is in the context or thread according to the collection owner.

So, you have a choice. You can process each post individually and build your own shadow collection, or you could query the existing collection.

Or put another way, do you want to organize the conversation yourself, or do you want to delegate that to the forum or owner of the conversation container.

Option 1 gives you more control over the presentation and organizing of the incoming posts. Option 2 adds an additional layer of moderation that can potentially weed out spam, trolls, and off-topic posts.

There is more than one way to process the same information.

cc: @Evan Prodromou @silverpill @Mike Macgirvin ️ @julian

@scott @mikedev @silverpill @julian

> one thing is unique about forums: It redistributes the posts to its members

this is done via Add or Announce, not by redistributing objects directly, and not by modifying them to inject a `context` property (which is unauthorized)

> you have a choice. You can process each post individually and build your own shadow collection, or you could query the existing collection.

the socially correct thing to do is the latter.

@infinite love ⴳ There are some interesting things you can do with context & thread information.

Display a Collection of Threads

You could display it blog, list, or grid style, with it only showing the top level post, and showing how many comments there are. To see the comments, it will either expand or take you to a new page when you click or tap on it.

You would need to know which collection is the thread to do something like this.

Drop or Collapse Moderated Posts / Comments

If you are following the forum, when the forum redistributes the posts, it tells you the context, and sends activities related to posts within their context (collection). And, ideally, you can backfill the conversation by querying the collection associated with that context.

You can take advantage of the forum's moderation by suppressing or collapsing posts that do not appear in the forum's collection. For example, some platforms will collapse a comment if it has too many downvotes. We could display a comment a similar way if it is not part of the moderated version of the thread (the collection). Users can still read it since it is part of the reply tree, but it is collapsed since it was moderated out of the thread. You can also be more aggressive and drop replies that are not part of the moderated thread.

You can also make exceptions. For example, if a user is following both the forum and an individual user, their posts would appear in your rendering of the thread uncollapsed, even if their post was removed from the collection by the forum.

And this is just two presentations I am thinking of off the the top of my head. There are more ways to display collections.

So, yes, you would still need to process incoming posts, but if information about the thread is provided, additional ways of displaying the information become possible.

cc: @Evan Prodromou @silverpill @Mike Macgirvin ️ @julian

@infinite love ⴳ

the socially correct thing to do is the latter.

Is it though? This is the philosophical differences I was referring to earlier.

If someone brought illegal contraband into my home, I have every right to remove both the person and the contraband.

It is similar with forums and conversation containers. If someone posts spam or illegal content, the container owner has every right to remove said content.

As someone who follows a forum, I expect the forum to moderate the content and remove spam and illegal content.

It also becomes a reputation issue. If the forum redistributes spam and illegal content, it can get blocked or shut down.

And nothing about this is forcing you to display the conversation the way the forum does. If you want to process the reply tree, then process the reply tree and create your own shadow collection. That is the freedom of the fediverse. You get to process incoming posts however you want.

But I also have the right to process incoming posts according to my preferences and/or the preferences of the users. You shouldn't infringe on my right to display the moderated version of the thread, just as I shouldn't infringe on your right to display the unmoderated version of the thread.

All of the examples that I gave can be made user configurable. So the end users can decide whether they want the moderated version of the thread or the unmoderated version. So it isn't just about my preferences. It is also about our users preferences.

@scott i'm saying that *because* the conversation owner has the right to remove messages, it is "correct" to *only* check what the conversation contains according to the conversation owner

in other words, we're in agreement that the moderated version should be shown. i don't know why you think or claim i believe the unmoderated version should (ever) be shown...

@infinite love ⴳ

this is done via Add or Announce, not by redistributing objects directly, and not by modifying them to inject a `context` property (which is unauthorized)

So this is why your forum posts show up as repeats (boosts) in Hubzilla. That is different than how Hubzilla forums work.

Even if you use that set up, the add or announce activity alerts you to the post being part of the collection or context. So even if the method of informing forum members of the post is different, that information can still be used to figure out the context.

@infinite love ⴳ I apologize. Then I misunderstood what you meant by parsing the reply tree to figure out what is in the thread.

Bottom line, I want information about what the thread is, preferably is an unambiguous way, so I can create unique presentations of the data. And I am trying to be forward thinking, because there are many situations where a post can be part of multiple contexts.

@scott i've been bringing up reply trees as an example of what we are trying to avoid, sorry for the confusion

i think our only real point of potential disagreement is in whether a "thread" and a "conversational context reified as a collection with a canonical representation and an owner (etc)" are meaningfully different?

@infinite love ⴳ I agree that is the sticking point. The concept of threads is important and meaningfully different for me because it affects how things would be displayed on my end.

I want to do all sorts of fancy stuff, and the more information you give me, the more fancy I can be.

And if you have only one context, then there really isn't much difference, unless the collection is a collection of objects that are part of other collections. Then you have multiple layers to deal with.

I know how I will handle it internally, I just don't know how I will handle federation.

If the top level post is part of a project, when displaying threads related to the project, display the top level post, and display whether it had comments or not. If you want to see the whole thread, you click on it and see all of the comments.

I don't even have to add the whole thread to the collection, only the top level post. (Although I could reference any post in the thread, and it would scroll to that post instead of taking you to the top.)

Plus, for the project management system, I have to figure out how to sync records (such as tasks) on different servers. I know that Zot protocol can handle syncing, but I am not sure how that works over ActivityPub yet.

But, at least for my system, I would need to distinguish between a thread and a project. You don't need to do that and only have one context, so my concerns aren't necessarily your concerns.

@infinite love ⴳ If you want to keep things neutral, then perhaps another way to distinguish the difference is a collection of posts versus a collection of collections.

@scott@authorship.studio ah, but we do, and like I said earlier, NodeBB achieves this by following the audience property aspect of FEP 1b12, which is in use by several other implementations already.

A NodeBB post is part of the topic/thread context, and it is also part of a category, just like your "projects". Different name, same thing (more or less).

cc @trwnh@mastodon.social

@julian @scott i am slightly dissatisfied with how `audience` ended up being used because i don't think a Group actor is necessarily the best way to model a forum category, but i think it could make sense to say that the `context` of a "post" is a "thread", and then extend that by saying that the `context` of a "thread" is a "category". you have similar concerns between posts and threads as you do between threads and categories, just "one level up".

@julian @scott the reason i say this is because membership in a Group is not yet defined (so it looks like only one actor is in the audience instead of the implication of several actors). also, the audience of a thread may differ from the audience of a category in some systems. you might *generally* expect that for any "post", `audience` == `context.audience` == `context.context.audience`... but this cannot be a guarantee.

@julian @scott one other thing i want to allude to briefly but not get into right now: forum category hierarchy.

@trwnh@mastodon.social @scott@authorship.studio

@trwnh@mastodon.social said in FEP Convergence (400e, 7888, 171b/Conversation Containers, 76ea):

i am slightly dissatisfied with how audience ended up being used

I am as well, although I was willing to implement it for the sake of compatibility until a better solution arrived.

While I alluded earlier that a NodeBB post could have multiple contexts (the topic and the category), it is better described by levels. Posts in Topics, Topics in Categories.

I suppose then a context would have a context. Makes sense to me.

@julian

While I alluded earlier that a NodeBB post could have multiple contexts (the topic and the category), it is better described by levels. Posts in Topics, Topics in Categories.

This is similar to how a project management system would have multiple levels, like project, task list, task, subtask, etc. And you could associate a thread or a post to any one of those. So it is similar to hierarchical categories in that way.

@julian

I am as well, although I was willing to implement it for the sake of compatibility until a better solution arrived.

Other than telling people that their post was boosted by the forum, do other platforms actually use the categories that we assign to posts?

If not, what is holding us back from creating something new for categories?

@infinite love ⴳ

i am slightly dissatisfied with how `audience` ended up being used because i don't think a Group actor is necessarily the best way to model a forum category,

I agree. I would expect audience to be the audience and not a collection of posts or a group actor.

@scott@authorship.studio said in FEP Convergence (400e, 7888, 171b/Conversation Containers, 76ea):

If not, what is holding us back from creating something new for categories?

Nothing. Being able to traverse remote contexts would be absolutely wonderful, and is in line with my goals for the ForumWG.

However that comes after we hammer down a solid recommendation for conversational contexts. Let's hold off for now, we'll get there.

@julian But if we decide to use contexts for categories, it would be relevant, since we would need to anticipate that usage pattern.

Even if we don't decide how we will present categories now, we probably should anticipate that people will use context in ways other than to represent a conversation container.

@scott@authorship.studio whether we decide to use as:context or not to represent second-order collections is still to be determined, but we can hold off on that until we figure out first-order collections. I'm not saying we hold off on it for years, just months.

FEP 7888 doesn't disallow other uses of context. It just gives direction for implementors who wish to use it to represent a first-order collection of objects. The key here is whether that context is resolvable to a collection, and (maybe) whether that collection contains items of interest (as:Note-like objects or otherwise).

The ForumWG with input from other interested parties (@erincandescent@akko.erincandescent.net, @trwnh@mastodon.social, among others) have provided an oral history that suggests that as:context is effectively unused, and what usages are found in the wild already conform to FEP 7888.

Do I think as:audience is the solution to second-order collections? No. It's just the way it is now, but not the way it will be forever.