i will not rest until fedi devs start using as:context properly. this is my single-issue. /hj

tedu

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

infinite love ⴳ

@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

infinite love ⴳ

@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

infinite love ⴳ

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

Julian Lam

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

Julian Lam

@trwnh @evan to that end, it's be something the forum/link sharing WG would love to address...

silverpill

@trwnh Conversations in streams now have attributedTo property (example: https://fediversity.site/conversation/7342c8d7-6ac2-4128-8168-6cbd0dc9a37c). Does it make streams a complete FEP-7888 implementation?

infinite love ⴳ

@silverpill i guess it does? it depends on whether comments are sent to context.attributedTo or not.

infinite love ⴳ

@silverpill in any case if i had to describe "compliance levels" then it would be something like:

0: does not use context (mastodon)
1: uses non-dereferenceable context (pleroma)
2.1: context resolves to a collection representing the conversation (streams?)
2.2: context has attributedTo and participating objects are sent to this actor

so all it would take for streams to be 2.2 compliant is for their "conversation containers" to be sent to `context.attributedTo` instead of `target.attributedTo`

infinite love ⴳ

@silverpill reading through the "conversation containers" doc at https://codeberg.org/streams/streams/src/branch/release/doc/develop/en/Containers.mc i have the following comments

- the notion of a "top level post" is kinda redundant with the context, and its definition as "without inReplyTo" can be problematic if your "top-level post" is actually a reply to something. imagine an article inReplyTo something, but with its own context

- "the conversation owner (target->attributedTo)" seems to confirm not 2.2...

infinite love ⴳ

@silverpill cc @mikedev for posterity. also the swicg threaded discussions task force (hi @julian and @angus) is looking at this from a forum perspective and not just a social media perspective. it is quite likely they will arrive at a similar finding in their report

julian

@[email protected] something @[email protected] and I were discussing was that some implementations include OP in the Page/context (iirc Lemmy does this @[email protected]), and subsequent replies are Notes, whereas NodeBB, Discourse, and later Flarum, treat the context as merely a container.

It seems the latter fits better with the vision of 7888 but I'm not sure whether concessions need to be made for those other types.

infinite love ⴳ

@julian @angus @nutomic i'm not sure what exactly you mean, but the exact types don't really matter (and shouldn't matter). for `context` you would just match against the id. after grouping by context, you are free to present in whichever way you want -- you can present in a flat chronological list, or in a nested reply tree sorted by some algorithmic scoring, it's all the same.

Evan Prodromou

@trwnh @julian @angus @nutomic the `inReplyTo` property and `replies` collection give you what you need to build a tree structure.

infinite love ⴳ

@evan @julian @angus @nutomic yeah, i'm just saying that crawling the tree is optional if you already have context. pleroma for example presents things in a flat chronological list, like an imageboard.

example: post 3 is a reply to post 1, it has replies in posts 4 5 and 87. post 6 is in reply to post 2. there's an option to show the tree as indentation. if that option is disabled, you see posts in order 1 2 3 4 5 ... 87. if that option is enabled you see posts in order 1 2 6 3 4 5 87 and so on

infinite love ⴳ

@evan @julian @angus @nutomic similarly, a chat app might not have `inReplyTo` on every single message. in fact, the vast majority of chat messages probably won't have `inReplyTo`. in this case, building a tree would fail spectacularly. all the chat messages are grouped together by the context of being in the same room, not by being in a reply tree. the reply is just metadata, like in discord or indieweb reply-contexts or the old youtube "video replies" feature.

Evan Prodromou

@trwnh @julian @angus @nutomic I think you'd need to reify the room as a `Group`, not leave it in `context`.

infinite love ⴳ

@evan @julian @angus @nutomic i dont see why you would. there can be multiple rooms/channels in a guild/server/group. just like there can be multiple topics in a forum category.

Evan Prodromou

@trwnh @julian @angus @nutomic groups can have subgroups