Does context in AP have to be a collection, or can be be like a Flag activity? Say I wanted to Create(Note) about a Flag I'd received, I'd need:
1) A way to address the remote moderation team (moderation group actor)
2) A way to say "this note is about this Flag activity", using inReplyTo would feel weird here, but maybe context would work?
@scott 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)
for the example of Create Note regarding a Flag, i'd use inReplyTo because you are responding to the report, no?
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)
@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.
@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.
@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.
@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.
"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.
@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.
@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.
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.