@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@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.
@trwnh 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?
@trwnh 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.
@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
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...
@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
@trwnh something @angus and I were discussing was that some implementations include OP in the Page/context (iirc Lemmy does this @nutomic), 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.
@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@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
@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@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.
Add comment