@thisismissem@hachyderm.io @scott @ThisIsMissEm @julian @evan makes sense to me

@thisismissem semantically, yes, it can be a flag or anything else you want. Functionally, for real world implementations? ‍️

I'm trying to think through what letterbook would do, and I suspect it would do the right thing. At least at the point of receiving the message. I would need some logic in reports to connect them back to that context, but i think that's likely to be straight forward

@thisismissem what I really want is context to be

1. A stable identifier that I can index
2. An indicator of whether and how reply control is implemented
3. A collection of related content-like objects, if reply control is implemented

In that order.

I think using a Flag (or its ID) satisfies that

@infinite love ⴳ

nope, context can be anything; it doesn't have to be a collection. it's only a thread *if* it has whatever properties you consider necessary for a thread (e.g. an owner, items, and some signal that you can participate)

The problem is that there is an assumption that things with those traits are a thread, which is not necessarily the case.

If you have a thread and a collection that can both be participated in, then how will you figure out which is the thread and which is the collection? As I stated before, there should be a way to specify which context is a thread instead of just assuming based on some random traits it might have.

@scott i still don’t think “thread” is anything special or different than “group of posts bound together by a topic and audience and owner that you can submit your post to for consideration of being added”. if anyone can come up with a proper semantic definition of “thread” then i’ll consider revising my definition, but asking “which one is the thread” is a bit like asking “which one of these recipients is the audience”, or like saying you only work with Note and not Article.

@scott like, you could define a type Conversation that the creator of the “thread” specifies when creating the “thread”. but this type doesn’t change any of the processing considerations for anyone wanting to participate. it just hints the author’s intention.

the one thing it *might* also do is signal that a certain protocol is in place, for example, something is a “fep-xxxx Conversation” might come with additional restrictions or requirements… but you still need the other props to be present.

@jenniferplusplus @thisismissem i think you’re in luck because it’s at least guaranteed to be 1. that’s the “intended usage” per the spec and per how it got implemented.

2 requires you to be able to dereference that stable id from 1, but it doesn’t require any specific type or repr. it just needs an owner and some properties signaling who can participate and how.

3 requires the dereferenced object in 2 to specifically be a collection.

Flag as context works for grouping but not backfilling.

@infinite love ⴳ The biggest difference is that one is a conversation, with people replying to each other. The other is a list of random posts, most likely curated by a third party, and that may contain multiple threads.

Unlike Mastodon and other non-threaded platforms, on a forum, it is expected that EVERYONE in the conversation can see all of the posts in that conversation. It is a group experience in which everyone has context surrounding the conversation.

Compare that with random curated lists where posts and threads are taken out of context and added to a list. You can have multiple threads, individual posts, even other actions like likes and votes.

So the biggest difference is, not ironically, context.

@scott if it’s “random posts” then it wouldn’t be a context, it would just be a collection. context requires purpose. the person authoring the object declares a context (or contexts) as a way to signal why their object exists. objects don’t exist to be added to random collections.

basically there’s two sides to it. the post author chooses which context(s) they want to declare. and the context owner(s) choose whether to add that post.

the browser can load any context they want to browse.

@scott when it comes to participating in a “thread”, you don’t do this from the object view. you need to navigate to the collection view first. it’s up to any individual actor to decide which (if any) context(s) they want to consider a “thread” or not.

@infinite love ⴳ That is not how every single forum and threaded social media app works. For every single one, there is only ONE thread, always, end of story.

People cannot choose what thread a post belongs to. If you reply to a post on a forum, your post becomes part of the thread, period, end of story. You have no choice. It is automatic. That is how forums work.

You do not have a choice of context, unless you place the post in a list that is not a thread. That is the ONLY time you have a choice of context. And that is only if you created the list yourself.

@scott well, i disagree with that definition of "thread". you can respond outside of a thread. you can have more than one thread. and it should always be your choice when and how these things get decided. "you have no choice, it is automatic" is incredibly user-hostile.

@infinite love ⴳ You would have to change how every forum and threaded conversation system works, because replying to a post within a thread always places it in the thread.

There are logistical reasons for this. It allows moderation at the thread and forum levels. A post can be removed from the forum or the thread by forum moderators, and it disappears from the forum. The person who posted still has the original and can forward that to anyone they want, but it won't appear in the forum any more and won't be distributed by the forum anymore.

It is similar to having a guest in your house. You can ask the person to leave at any time. That is the nature of forums, which are moderated communities. It is a complete different paradigm that the free-for-all that is Mastodon and Twitter.

It is also why you have to join most forums, and they can prevent you from posting in the forum if you are not a member of the forum. It's their territory. Their home. If you want unmoderated distribution, you post on your own timeline instead of someone else's thread or forum.

User-hostile or not, that is how forums and threads work, and have worked for 40 years. The fact that you seem surprised by this explains why you don't seem to understand why a thread is different than a collection.

@scott you can moderate at the thread or forum levels without any post ever being explicitly inReplyTo any other post. inReplyTo is completely optional, and completely separate.

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

@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