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

@julian @scott @trwnh depending upon how strictly you interpret the SHOULDs of 7888 we can approximate that 1% of posts today are using context per 7888, assuming post count is proportional to user count

@erincandescent @scott @julian i wonder if it makes sense to define something akin to conformance profiles or compliance levels? i held off on doing this because there aren't any MUSTs in there, but you could loosely say the following:

a "level 0" producer doesn't use context
a "level 1" producer uses an opaque id
level 2: it resolves to an object
level 2.1: it resolves to a collection
level 2.2: it resolves to a collection with an owner
level 3: sending objects to the owner may add them

@erincandescent @scott @julian mastodon etc are "level 0", pleroma/akkoma are "level 1", nodebb and discourse are somewhere around 2-3

@trwnh @scott @julian 1.5. the ID isn't dereferencable but could be (Pleroma & Akkoma are here)

@infinite love ⴳ @julian @Erin

Do we need to indicate whether you can follow a context, or would that be specified elsewhere?