real talk tho, if you want actually existing honest-to-god threads and threading and conversations... there's a property for that!

pleroma and streams are like 80-90% of the way there, the only missing bit is signaling who owns the context via `attributedTo`

@trwnh which FEP is it again?

@erincandescent 7888

@trwnh@mastodon.social I'm only just noticing that the examples provided in 7888 don't include to, cc, etc. Are they omitted for brevity, or would it be a departure from the FEP if one were to add in those properties?

@julian brevity

@julian more specifically, the examples use `audience` instead of to/cc, but you can use any of the three (to/cc/audience)

@trwnh@mastodon.social there's nothing specific in these two Notes that set them apart from any other note that was properly processed. I also don't have logs from that far back (because I was travelling last two days, sadly!)

If it happens again, please let me know and I'll take a closer look.

@trwnh @julian I kind of hate that.

@trwnh you mean, a real `Collection` that contains all the objects in that conversation?

@evan @julian if it's confusing then i can change the examples

@evan that would be the ideal, yes. streams does this (except i think they expose all the activities). pleroma uses a uri that doesnt resolve to anything. mastodon still uses the old ostatus:conversation.

@trwnh 🫤 we'll get there. Is there a FEP?

@evan https://w3id.org/fep/7888

@trwnh interesting, I thought about this and decided that context should not be derefencable because nobody owns it. Anyone can create a new context, and then anyone can append to it. If you want to own the collection, make it a proper replies collection.

@tedu the problem with deferring to a "replies" collection is that declaring a context is completely orthogonal to declaring a reply

my thinking is that IF:
- the context is present
- the context is dereferenceable
- the context is a Collection that has attributedTo

THEN:
- the context collection is managed by that attributedTo actor, via Add/Remove
- you can participate by sending your Create to that actor, with the object having the same context

@tedu side note, you do run into similar issues with establishing a two-way confirmation, e.g. that a reply is in the replies collection, or that an object is in its declared context. but that's a matter of convention and not a technical issue. i suppose you could have reply proofs and/or context proofs, but that's out of scope and is an exercise left to the reader

@tedu my tentative approach would be to have a resolvable "stamp" in the form of an Add activity targeting either the `replies` collection or the `context` collection, although one raised objection was that fedi devs don't want to check for inReplyTo.replies being equivalent to replyProof.target? i can't say i understand the objection myself... something about inefficiencies with current database schemas in Mastodon et al. the alternative proposal was a custom AcceptReply activity, i think.

@tedu to which i say: just make it a multityped activity, ["Add", "AcceptReply"]

finally, the one other issue with the "stamp" idea is that it doesn't necessarily play well with edits. you can't easily approve a specific revision of the reply/comment/etc. all you can do is somehow detect this and revoke your approval by making the "stamp" nonresolvable.

but, again... convention can solve this? just convene to always check the replies/context collection if you care about the authority of owners

@trwnh @evan thanks, it seems like even if there is disagreement over whether 400e or 7888 is the preferred approach, alignment on implementations of `context` is important even between those who choose to implement 7888.