Reading a bit more about ActivityPub again, I would like to offer you my summary of the situation:
-
Reading a bit more about ActivityPub again, I would like to offer you my summary of the situation:
- ActivityPub is good at sharing updates with your friends, i.e. POST to inbox
- ActivityPub/ActivityStreams is pretty bad at everything else.
For the second statement: Consider fetching a conversation from Mastodon's ActivityPub implementation. Assume that the conversation contains N Notes. With an implementation optimized for Mastodon it takes: 2 * N requests. With a general implementation that doesn't assume Mastodon's quirks. It probably takes 4 * N requests. This doesn't give you Like/Share counts.
If you had a good protocol, it would take 1 request (or something that doesn't scale in N).
Finally: I don't consider the thing hard to fix. There are solutions floating around for people that are looking. The problem is more in making everyone aware of what one needs ...
-
@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