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