Simon WillisonDec 22, 2022

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

Show threadocdtrekkieDec 22, 2022

@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".

Show threadSimon Willison

@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

Dec 22, 2022 at 8:53pmWeb
Show threadCubeThoughtsDec 22, 2022
@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.
Show threadCubeThoughtsDec 22, 2022
@simon @ocdtrekkie So compared to how you described it works now, instance 1 now only knows about replies if there are users on instance 1 following those users. With your solution, instance 1 would have to be notified and keep track of every reply on any server and forward that information as needed. And instance 32 would do the same for the reply. Etc. Should work, but is probably quite a performance difference for servers with a lot of off instance replies.
Show threadCubeThoughtsDec 22, 2022
@simon @ocdtrekkie And will you see this reply? Probably, because I'm on a big server?
Show threadYozDec 23, 2022
@CubeThoughts @simon @ocdtrekkie ok, this is even more unexpected than I thought. Instance 32 doesn’t tell instance 1 about the reply?
Does that mean that UserA on instance 1 (who posts) might never see a reply from UserB on instance 32 (to their original post) UNLESS instance 1 happens to fetch that post for a different reason (e.g. UserC on instance 1 follows UserB)?
Show threadSimon WillisonDec 23, 2022
@yoz @CubeThoughts @ocdtrekkie you will always see all replies to something you yourself posted - where you might miss replies is if they are:
- from people you don't follow
- to people you don't follow
- where neither of those people are on the same server as you (or are followed by someone on your server)
Show threadSimon WillisonDec 22, 2022

@CubeThoughts @ocdtrekkie that hypothetical situation actually works OK

When the user on instance 32 replies, instance 1 will then re-broadcast that reply to instances 2-50 since those instances all host users who are following the author on instance 1

Show threadAlisonW ♿🏳️‍🌈♾️Dec 23, 2022
@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.