Reading a bit more about ActivityPub again, I would like to offer you my summary of the situation:
-
@helge hmm why does it take 2N requests? You should be able to just pull object IDs out of the replies collection and fetch them (and you can skip the fetch if they're inlined and same origin)
Well, except for the bit where Mastodon only provides self replies... -
@helge ideally for this each post would just inline the URL of every post in the replies collection
-
The replies collection only contains direct replies. So if post A has a reply B and B has a reply C. This means that A.replies = [B] and B.replies = [C]. So you will need to fetch A, A.replies, B, B.replies, C, and C.replies in order to ensure that one can gets everything.
Depending on how one reads replies, I'm sure somebody will argue that C should also be in A.replies. It's just not how Mastodon implements stuff at this moment.
-
@helge most implementations inline the replies collection, so it shouldn't be required to go and fetch it explicitly most of the time, except that most implementations also only include self replies in the inline collection
-
@helge If the replies collectionβs items were always inlined (or were always inlined when low enough in number, at least), it would be N fetches for N posts which is not too unreasonable.
The Threadiverse people (Discourse, NodeBB, Lemmy?, MBin?) are also coalescing around the idea of a context collection which contains every post in the entire (logical) thread
-
Erin π½β¨replied to Erin π½β¨ last edited by [email protected]
@helge Akkoma and Pleroma already internally maintain the same idea of a context so I have plans to implement an MR which reifies it at a fetchable URL.
-
@helge like you mentioned, I dealt with this by putting all upthread objects in the inReplyTo property of the current object (from parent, all grandparents, up to the original post). This fails most of the time because most implementations, following in the footsteps of Mastodon (which has a ticket open for the issue), fail to deal with inReplyTos which are not a single IRI.
IMHO it's the simplest way of solving both the fetching issue and the threading issue.
-
@erincandescent I think the inReplyTo property containing all upstream thread IRIs should be enough context, wdyt (see my sibling comment about it)?
-
@helge Yeah, the way this is mapped out today is a Ξ(n) problem. Minimum.
But it definitely doesn't have to be. There's no reason it couldn't be a Ξ(1) problem or, for a complete tree, maybe Ξ(lg n).
I would have to do math to figure out exactly what would be required and there's some nuance in the details (and I am undercaffeinated for advanced algorithm analysis), so this is rough, but based on the structures it feels about right.
-
@erincandescent @helge That would be great. Currently Pleroma doesn't even publish
replies
collection