FEP Convergence (400e, 7888, 171b/Conversation Containers, 76ea)

Scott M. Stolz

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.

infinite love ⴳ

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

Scott M. Stolz

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

Scott M. Stolz

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

infinite love ⴳ

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

Scott M. Stolz

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

Scott M. Stolz

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

julian

@[email protected] 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 @[email protected]

infinite love ⴳ

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

infinite love ⴳ

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

infinite love ⴳ

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

julian

@[email protected] @[email protected]

@[email protected] 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.

Scott M. Stolz

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

Scott M. Stolz

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

julian

@[email protected] 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.

Scott M. Stolz

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

julian

@[email protected] 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 (@[email protected], @[email protected], 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.

Erin 💽✨ 🔜 38C3

@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

infinite love ⴳ

@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

infinite love ⴳ

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