My least favourite sharp edge of Mastodon is the fact that when you view someone else's post you only see replies to it that are known to your server - so there's actually a good chance there will be replies that are completely invisible to you, especially if you run your own instance

I'd love it if tapping a post kicked off a request back to the original server that fetched the current reply count and provided a "view all replies" button if there were replies not yet visible to me

@simon A big part of the problem is that at scale, that would probably make existing performance issues even worse.

"George Takei posts, and the fediverse shuts down".

@ocdtrekkie yeah I guess that's always the catch with this - the home instances of high-follower accounts would have to be able to serve a HUGE spike of GET requests (which could be cached, but still a lot of incoming traffic)

I really, really want a fix for this though! It's a very real problem for me - I've found myself replying to someone with material that's already been covered in other invisible-to-me replies quite a few times at this point, which makes me look rude

@simon @ocdtrekkie (With the risk of repeating someone else's reply!) Isn't it like this though. There is a toot on instance 1, users on instances 2 to 50 are subscribers so they get the toot. User on instance 32 replies. How would instance 45 know about that reply to show its user. The app of user 45 can't ask every instance. Instance 32 would have to tell instance 1, and instance 1 keep track of all replies to tell other instances when they get the original toot.
@CubeThoughts @simon @ocdtrekkie
If the thread-creating-instance could keep an index of replies (not the texts, just the links) then it could supply those on request. It should already have the data.
Issue then becomes who tracks the spin-off threads.