There's a lot of things that I am adjusting to as far as interacting with Mastodon content goes, but "Unless you were following someone before they posted, it is likely that the replies to their post are an incomplete view and you have to click through to their instance to see the real replies, which you otherwise DO NOT KNOW ARE THERE" is ... not great.
@msokolov@gregprice I am not an expert (so perhaps @evan will hop in and correct me), but my understanding of ActivityPub so far is there is effectively no "fetch" mechanism at the post level at all.
ActivityPub (Server to Server) is a "push" protocol, with the only "fetch" operation being "a list of things directly posted by an Actor" (ie, account); there's no per-post fetch endpoint at all.
Comparing to email: I can email you, you can fetch my _sent_ box, but threads are not available.
@crschmidt@gregprice I haven't looked at this protocol, but would it make sense to have "fetch this post and *references* to its replies" so I can recurse? Maybe the replies are held elsewhere?
@gregprice Yeah. ActivityPub Replies are sent upstream to the original poster, who then has a responsibility to federate them back out, but they only federate at that time; it's a little more complicated (e.g. if the replier is on your instance or followed by someone on your instance you'll probably _also_ see it), but some will just never make it to you, and ActivityPub (afaik) doesn't have a mechanism to say "Give me this post and all its replies".
@crschmidt OH! That certainly helps explain some behavior I'd seen - thanks for describing it.
I've encountered that lack of replies, but then had the feeling that I don't *usually* see it, and hadn't identified the pattern. That pattern about whether I've been following the OP makes sense - and yes, seems quite frustrating.
@evan@msokolov@gregprice So, an ActivityPub implementation which receives a Note which has an activitystream:replies object should have all the information it needs to fetch replies; Mastodon's implementation in particular chooses not to include reply _data_, using URLs instead, which makes filling that data in downstream costly (ie, requires fetch of each Note object), but that's an implementation detail that could be changed and still fit within ActivityPub/ActivityStreams.