@infinite love ⴳ

"this is how it works and has always worked" is regressive. if we were building centralized forums in the vein of the past, maybe it would be okay. but we're building a decentralized social web for the future. we need to broaden our view of what's possible. and we need to recognize the choice that any publisher has.

Refusing that threads exist is regressive, not the other way around.

If you want to support new use cases, you allow things to be declared a thread and to be declared collection or other things.

If you do not do this, you are basically telling platforms to ASSUME that it is a thread since there is nothing saying otherwise, and most existing systems only support threads.

Refusing the have a way to declare a thread is regressive and hinders other user cases.

@scott again: if you want to declare something is a "thread" then you need to clearly define what a "thread" is, semantically speaking. you don't fit your semantics to specific implementation decisions. the semantics need to make sense regardless of any implementation.

- if you're responding to something, use "inReplyTo"
- if you want to group objects together around their reason to exist, use "context"
- if you want to mark your object as relevant to specific people, use "audience"

and so on.

@infinite love ⴳ I have defined it over and over. It is the conversation container that forums and Facebook-style platforms place your replies into. You do not choose it. It is automatic. There is a conversation owner who can delete any comment within the conversation container, with or without the consent of the person who posted the comment. It is moderated by both the conversation owner and the site administrators.

I know that there is not much difference on the backend or the database, but there is a HUGE difference on how you display a thread versus a collection.

And I have given you several use cases where it would be confusing the classify a non-thread as a thread, especially when some of the objects in the collection are threads themselves.

Ideally, platforms give us a clue about what the data they're sending actually is.

Otherwise, platforms will assume it is a thread, and that is regressive behavior and supports the status quo.

Also, from a practical programming standpoint, it easier to just grab the one marked as a thread instead of just assuming that maybe the first one is the thread, maybe?

@scott you're still assuming "forums and Facebook-style platforms" work in this one specific way, where additions are automatic instead of intentional, and where the author of the post doesn't have any control over their own post. i'm talking about a system in which the author *does* have control over their post, and the collection owner only has control over what gets added or removed. they don't get to delete the post. they only get to remove it, or to never add it in the first place.

@scott

here's a practical example: what is the difference between these two objects?

```
id: <post-2>
inReplyTo:
- id: <post-1>
context: <thread-1>
```

```
id: <post-2>
inReplyTo:
- id: <post-1>
context: <thread-1>
context: <thread-1>
```

you are arguing that the first object belongs in thread-1 **despite never declaring this for consideration**. this is not guaranteed.

@scott furthermore, you are failing to account for the following possibilities:

```
id: <post-2>
inReplyTo:
- id: <post-1>
context: <thread-1>
context: <thread-2>
```

```
id: <post-2>
context: <thread-1>
```

```
id: <post-2>
context: [<thread-1>, <thread-2>]
```

```
id: <post-3>
inReplyTo:
- id: <post-1>
context: <thread-1>
- id: <post-2>
context: <thread-2>
```

```
id: <post-3>
inReplyTo: [<post-1>, <post-2>]
context: <thread-2>
```

and many, many more

@scott it feels like you're focusing too much on the issue of "what if something is not a thread?" a la

```
id: <post-2>
context: [<thread-1>, <thread-2>, <not-a-thread>]
```

in which case, you simply drop not-a-thread from consideration.

you also seem to be confusing "object is in a collection" with "object exists in context of something". being part of a collection is not enough.

Here is an example:

id: post 1
context: thread-1, project, flag-a

id: post 2
context: thread-1

id: post 3
context: thread-2, project

id: post 4
context: thread-2, flag-b

id: post 5
context: project, thread-3, flag-a

etc.:

How do I know which one is the conversation that is displayed on the forum?

Here is an example:

id: post 1
context: thread-1, project, flag-a

id: post 2
context: thread-1

id: post 3
context: thread-2, project

id: post 4
context: thread-2, flag-b

id: post 5
context: project, thread-3, flag-a

etc.:

How do I know which one is the conversation that is displayed on the forum?

@infinite love ⴳ Or more specifically, how do I know which is the official moderated version of the conversation according to the forum?

@scott whichever one declares the requisite properties (owned by the forum or some mods on it, scoped to an audience, contains "post" objects bound to a context, etc.) -- if there are any missing properties that you consider "required", then you drop it from consideration.

for example, maybe you consider the "thread" as something special that needs to be declared, e.g. as a ConversationContainer, but i think that's needlessly limiting and not backwards-compatible with unaware implementations.

@scott the core functionality is the grouping of posts by their topic or shared context. the "trick" is that if it's a collection, it's actually entirely up to the owner to decide what goes in there! i could create a collection, declare it to be a ConversationContainer, but then start adding unrelated posts. actually, as the owner, i get to decide what's related and what's not! maybe i require context to be set. maybe i require inReplyTo. maybe i have some other criteria. ideally, i signal this.

@scott so the collection has some "participation criteria" which describes the shape of what i deem worthy of potentially Adding. for example, i could say that
- object.content must be present
- object.attributedTo must be present and included in the Collection.audience
- object.context must include Collection.id

but this is advisory at best. i reserve the right to add objects that don't match this shape.

i also can hint how i think the collection should be displayed, but this is only a hint.

@scott the point i'm trying to make here is that, in an open world system, there are limits on what you can enforce or expect. it's always possible that you will encounter something that breaks your expectations, so make as few expectations/assumptions as possible.

the idea of a "thread", when broken down to its core semantic ingredients, is not significantly different than "a group of posts bound by some common key characteristic". structure is created within that grouping.

@infinite love ⴳ You also have to consider that most systems may get duplicate versions of the same post from different sources.

For example, if I am following someone and following the forum, I will be sent one copy from the person I am following, and one copy from the forum. The forum will have a context attributed to the thread, and the other version will not.

Since the forum sends a copy of all of the posts in the thread directly to followers of the forum, you don't even need to process the reply tree. Just look for the context that indicates the thread and show all posts marked with that context. Any post without that context has been moderated out of that thread.

If you want to utilize the moderators of the remote system, you have to display only what they approved to be in the thread. If you don't care what the moderators on that other system think, you process the reply tree instead, and only use the context to backfill the conversation.

To minimize spammers and trolls, you drop any post that does not belong to that context (the moderated forum thread) and/or does not belong to someone you follow.

You don't have to do that and can let anything in the reply tree through, but if someone is already moderating a thread, that's less work for me.

@scott
> The forum will have a context attributed to the thread, and the other version will not.

The forum doesn't have permission to modify the author's post. It can only send an Add and/or Announce.

Instead, any consumer wanting the "moderated version" needs to either fetch a collection's items directly, or establish proof that any item was Added to the collection. If you can't prove this, you hide or drop the post as "unverified".

This continues to have nothing to do with reply trees.

@infinite love ⴳ And this continues to have nothing to do with threads.

You are so wrapped up in reply trees that you refuse to acknowledge that threads are a distinct type of list.

And based on some of your comments, I get the distinct impression that you are actually against the idea of having threads. Or that you have never used usenet, email, forums, Facebook, or any other platform that uses threaded conversations. But I will give you the benefit of the doubt and assume you just are against the idea of threads.

Yes, you can get the whole (or most) of conversation from the reply tree. We know that. That is how most platforms do it today.

I want to know what the thread is (the moderated version of the conversation) for different reasons, which I have stated over and over.

So, I will simply chalk up your refusal to acknowledge threads as being a valid way to organize and moderate conversations as a philosophical stance.

If so, I will respect that. But don't expect other platforms to think like you do.

Because everything you have stated is consistent with Mastodon, not forums nor threaded conversations. And the way you want to implement things ignores some of the main benefits of having moderated forum communities.

@scott It’s *the web*, not Mastodon. I’m not opposed to threads, I’m just saying that they necessarily work differently when you have resources split across multiple authorities. Post owners own their posts on their own domain. Posts can *claim* to have been created in a certain context, but unless you reify that context as a collection with items, you have no authoritative origin to check for what officially got added. The problem is in Mastodon et al *never checking any collections*.

@scott Even with reply trees, Mastodon et al will only ever use inReplyTo. They ignore the “replies” collection. This bypasses the authority of every post author to get to decide which responses they want to acknowledge and which ones they don’t. The other issue is that they don’t recognize a “conversation” or “context” as an actually existing reified object. At best, it’s an opaque string hint that you can search your database for and reduce your search space for a reply tree.

@scott So the way forward is to:
- recognize the concept of a “conversation” or “conversational context”
- start declaring that posts are not standalone and that they exist in some “context”
- reify that “context” as a collection that has canonical items
- give the context collection an “owner” or “moderator” who chooses what goes in and to whom you can send objects for consideration
- stop taking post metadata at face value and actually verify the information you’re trying to present to users

@scott but in all of this, you have some invariants:

- the post owner owns the post
- the collection owner owns the collection
- any collection may contain any post, without it being a context
- context is something that the post author “declares”; the collection owner “fulfills” this declaration by adding the post to the canonical collection representing the conversational context
- a third party browser/consumer/processor cannot assume that an object is contained in a collection it implies.