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

julian

@[email protected] I think I know how that one can be solved.

Using Hubzilla nomenclature:

When you have a post it defines the thread as context
Your post can also define the project as audience as per FEP 1b12
The thread (the context collection) would define the project as the collection owner (attributedTo)

Scott M. Stolz

@julian Would an audience be appropriate for a collection of threads & posts?

Also, the project won't be the owner, since any post on our system can be flagged as being associated with one or more projects. It will be a collection of random threads and posts that happen to be related to the project.

The whole idea is that we can tag threads as being related to a project, no matter what forum or channel they came from.

The collection can then be queried and a list of related threads and posts would be provided.

Also, as a side note, the project management system will be headless. One of the heads will be Hubzilla, but we may create a non-Hubzilla based head later.

Scott M. Stolz

To give you an example:

Here is a thread (conversation with a topic):

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

Here is a collection (a list of posts labelled "Forums and Threaded Discussions Task Force"):

#^https://community.nodebb.org/category/31/forums-and-threaded-discussions-task-force

Notice how they are rendered completely different.

A collection is NOT a thread. And some apps need to know which is the thread so we can render the display properly.

Scott M. Stolz

Reposting here, since the conversation got sidetracked onto Mastodon.

@infinite love ⴳ

Most contexts are multi-faceted in this way. #^https://w3id.org/fep/7888#the-different-types-of-context-and-how-they-are-actually-the-same

Yes they are. But, as I said, there are practical reasons for wanting to retrieve the conversation container (forum thread, social media thread, chat thread, etc.) as opposed to the reply tree.

The biggest practical reason is delegation of moderation. In order to limit spam, trolls, and off-topic discussions, the owner(s) of the conversation container (thread) will moderate content by removing it from the conversation container, moving it to another conversation container, or flagging it in some way.

If @julian spots a spam post on NodeBB, he can delete it. And if I retrieve the conversation container (thread) that NodeBB places the posts in, I will get the moderated version of the thread without the spam. If I parse the reply tree, I get the spam even though Julian deleted it.

It also helps keep conversations together when the forum moderator moves a post to a different thread. If you follow the reply tree, the post would appear in the wrong thread.

If you want threaded discussions to behave like threaded discussions over ActivityPub, you need to provide additional information that allows that to happen.

cc: @Evan Prodromou

julian

@[email protected] Yes. Per 1b12, audience is the appropriate property to use to denote a collection of loosely-related objects. context is ideal for closely-related objects (like ones that share a reply tree, but that doesn't rise to the level of a requirement), like posts in a context (topic/thread).

In your examples, the "thread" is a Collection when resolved and is referred to in objects via context. The "category" is an Actor when resolved, and is referred to in objects via audience.

As for the other conversation, it honestly seems like you and @[email protected] are splitting hairs and really want the same things.

Scott M. Stolz

@julian The sticking point is basically whether I should guess what the thread is, or be told what the thread is.

He wants me to perform a bunch of tests and guess; I want it to be declared.

I am not sure what you are going to do when there are multiple collections associated with a post. Because unless the thread is declared, you won't know which is which.

julian

@[email protected] said in FEP Convergence (400e, 7888, 171b/Conversation Containers, 76ea):

I am not sure what you are going to do when there are multiple collections associated with a post.

My plan is to take the first item in context and treat that as the most narrowly scoped collection containing that object. The assumption is that the contexts are ordered from narrow-to-wide. Whether or not additional contexts would be helpful is irrelevant to me, as I am converting this object into a NodeBB topic only.

You can make arguments that this is not correct. I will not disagree. I will simply say that, like it or not, this is the simplest form of compliance most implementors will opt for.

Scott M. Stolz

@julian If that is how you want to do it, I respect that. But I do find it odd that the FEP actually has a field for thread and nobody plans on using it. But, most platforms either have 1 context or 0 contexts, so it makes sense.

I still haven't decided how I will do things with my fediverse-enabled project management system. At some point, there will probably be multiple contexts. If that is the case, I probably will put the thread as the first context and then also declare what the thread is using FEP 76ea or something similar.

That way, at least with my project, you won't have to guess which one is the thread. And since your platform only has one context, then I won't have to guess either.

Scott M. Stolz

@julian The sad thing about this is that we have an opportunity to set the standard here, and we are not taking that opportunity.

Yes, we have to assume that not all platforms will add the additional fields, and we have to have a fallback way of processing incoming posts.

I am just flabbergasted that "thread": "https://remote.example/thread/117", is too hard to include with posts distributed by the forum. Even if you don't use it, some of us might find that to be useful information.

But it appears that I am alone in this, so I will just let it be.

julian

Hi @[email protected], thanks for your thoughts. I took the evening to think it over.

I agree that using thr:thread would be the most explicit way of signalling that NodeBB topics are threads, and if 76ea were to be adopted by a majority of implementors, then I would reconsider. Currently I am on the fence about whether or not I should implement it.

I do want to point out that @[email protected]'s FEP 7888 doesn't expressly forbid multiple contexts, and I think upthread they even said that such a use case would not be contrary to the FEP:

based on this conversation i probably need to add examples to fep-7888 of how one might process multiple contexts.
~ trwnh

My opinion today is that when NodeBB uses context, it is doing so to signal that "hey, these posts are part of this collection", and exactly nothing more. It is up to the receiving end to decide how to implement it, and I think that this sort of variety is absolutely wonderful.

If, for example, someone were to see my context and say "I'd like to map this context's objects out into a word cloud and do sentiment analysis on it", I think that's a perfectly cromulent use of the data. For me to say "this here is a thread, and you better treat it as a thread" is contrary to the spirit of ActivityPub and fedidevs in general.

It would be like the ForumWG saying to Eugen, @[email protected], et al. that "we've decided that YOU, Mastodon, need to support as:Listen and render inline players, and playlist support, etc.". That's ridiculous, wouldn't you agree?

infinite love ⴳ

@julian @scott quick notes:

- (they/them btw)
- multiple contexts probably will end up like multiple inReplyTo; idk if most impls will support it. but "which one is the thread" as a question makes no sense bc most likely they are all "threads" in some way
- 76ea thr:thread is a reply tree, not a conversation
- reason i say "context likely == thread" is bc it's **more than just a collection**. it is WHY the object exists. what is a thread if not purposeful grouping?

infinite love ⴳ

@julian @scott in other words: for social media / network / "post" purposes, the context is almost always some thread. if it doesn't fit the shape of a thread, then don't treat it as a thread, but in most cases it will. otherwise it wouldn't be a "context", it'd just be some object/collection.

i'm defining "thread" as "when you reify a conversational context, specifically as a collection with an owner and canonical representation, instead of something you have to reconstruct for yourself".

infinite love ⴳ

@julian @scott the problem with saying that a "thread" is different from a "conversational context reified as a collection" is that there is no criteria i am seeing by which a thread is different. the thread is a purposeful grouping (context), it has a canonical representation (collection items), and it is maintained by its owner (attributedTo). what more do you need? an explicit declaration that it is a 171b:ConversationContainer? what does that get you?

infinite love ⴳ

@julian @scott at best, a dedicated type like ConversationContainer can hint that it was produced by some producer following the ConversationContainer spec/fep/whatever, but the problem is that a) anyone can claim that type without following the spec, and b) it's not actually needed for processing the context property, because you already know it is semantically the context -- the origin or purpose of that object. if it's an id, you group by that id, and if it's a collection then you fetch items

infinite love ⴳ

@julian @scott basically if 171b wants to define a ConversationContainer type to signal that a producer is following that fep/spec/whatever then they can do that. i maintain that the use of `target` is still incorrect, invalid, and redundant, but it is what it is. if a similar/different fep defines some other type to signal basically the same thing except in details, then that can also be done. in the end, i would advise that the actual "protocol" doesn't require hardcoded type checking.

infinite love ⴳ

@julian @scott in any case the algorithm for processing the post as a topic owner is:

1) loop over `context` for any ids you own
2) if the post is acceptable to you, add it to the relevant collection

the algorithm for processing the post as a third-party observer is:

1) look at `context` to see if any of them are collections
2) pick a collection and navigate to it, discarding the post. if it's actually in the collection, you'll see it again.

infinite love ⴳ

@julian @scott that's basically what this all boils down to, really -- not a technical change, but a social one.

our softwares should stop trying to reconstruct shadow collections based on what they *think* should be in there, and they should just browse to the actual collections.

in general, more things should work like web browsers instead of blackboxes that gobble up data and mash it together based on their best guess of how they think it's connected.

Scott M. Stolz

@julian

If, for example, someone were to see my context and say "I'd like to map this context's objects out into a word cloud and do sentiment analysis on it", I think that's a perfectly cromulent use of the data. For me to say "this here is a thread, and you better treat it as a thread" is contrary to the spirit of ActivityPub and fedidevs in general.

Simply declaring a collection to be a thread does not force people to display it as a thread. But it does provide valuable information to people who do want to display it as a thread.

So you are not removing people's choice by simply stating that on your platform, this is considered a thread.

Scott M. Stolz

@infinite love ⴳ

our softwares should stop trying to reconstruct shadow collections based on what they *think* should be in there, and they should just browse to the actual collections.

That is my point. If you tell me what the thread is, I can download all of the posts within that thread. I don't even have to parse the reply tree at all.

julian

@[email protected] @[email protected] I'm at a loss as to why you seem to think this is not possible if the property is called context instead of thread.