[danabramov]

How does it work?

In ATProto, there is no need to do this on-demand because the data is already there in the AppView. When you want to serve a page of replies, you read them from the database and serve them. There is no distributed fetching involved, no need to hit someone else's servers, no need to coalesce them or worry about limiting fetches, etc. This is why it works fine for threads without thousands of replies and hundreds of nesting levels. It can also be paginated on the server.

If you don't have this information on your server, how can you gracefully fetch thousands of replies from different servers and present a cohesive picture during a single request? I'm sure this PR does an attempt at that but I'm not sure this is a direct comparison because Mastodon can't avoid doing this on-demand. If we're comparing, it would be good to list the tradeoffs of Mastodon's implementation (and how it scales to deep threads) more explicitly.

[alethic]

There is a detailed explanation available at the link I posted. Second header, "Approach".

[danabramov]

What do you expect the performance characteristics to be compared to querying a database?

[alethic]

I expect them to be unimportant. This has been merged upstream and running on the flagship Mastodon instance for a little while now.

There is also a section related to performance available at the link I posted. Third header, "Likely Concerns", second subheader, "DoS/Amplification".

[danabramov]

What do you mean by unimportant?

I mean from the user's perspective: when I open a thread, I expect to instantly see the entire discussion happening across the entire network, with the paginated data coming back in a single roundtrip. Moreover, I expect every actor participating in the said discussion (wherever their data is stored) to see the same discussion as I do, with the same level of being "filled in", and in real time (each reply should immediately appear for each participant). It should be indistinguishable from UX of a centralized service where things happen instantly and are presented deterministically and universally (setting aside that centralized services abandoned these ideals in favor of personalization).

With ATProto, this is clearly achieved (by reading already indexed information from the database). How can you achieve this expectation in an architecture where there's no single source of truth and you have to query different sources for different pieces on demand in a worker? (To clarify, I did read the linked PR. I'm asking you because it seems obviously unachievable to me, so I'm hoping you'll acknowledge this isn't a 1:1 comparison in terms of user experience.)

To give a concrete example: is this really saying that replies will only be refreshed once in fifteen minutes[1]? The user expectation from centralized services is at most a few seconds.

[1]: https://github.com/mastodon/mastodon/pull/32615/files#diff-6...

[alethic]

I'm not very interested in arguing over the ins and outs of "user expectations" and Mastodon vs. Bluesky, sorry. I would suggest you try it yourself and come to your own conclusion about whether this is a usable system :^)

[danabramov]

I'm arguing that "not really consistent" from the grandparent post still applies, and therefore your "this isn't correct" isn't correct.

For realtime discussions (like this one), I don't think we can call it consistent if it takes multiple minutes for each back-and-forth reply to propagate across instances in the best case (and potentially longer through multiple hops?) because you'll see different things depending on where you're looking and at which point in time.