When imperfect systems are good: Bluesky's lossy timelines

This is not true. Third party PDSes are fully supported by our app view, and our app view generates timelines for all the users on those PDSes.

What does this have to do with third party app views?

You didn't specify what kind of federated servers you were thinking about

The statement "any federated servers interacting with Bluesky" is ambiguous, because Bluesky's federated model means there's many different types of servers, and one user's view of what a "federated server" could be vastly different from another.

Federated PDS-s (which is probably the closest to what people mean when they say they want to federate on bluesky) would not need to reconstruct timelines if their users use the bsky.app appview.

Thanks, that's a fair point that I was overlooking. When I say a "federated server", I don't just mean a self-hosted PDS, I mean a third party app that potentially has its own lexicon and design decisions. Creating a robust third-party app that can meaningfully interact with the Bluesky network is still a very difficult engineering challenge, which I think this article does a good job demonstrating—that was the tension I was trying to underscore in my comment. Bluesky may be solving those engineering challenges for those clients who are satisfied with Bluesky's frontend and AppView, but every single other app built on top of ATProto will have to resolve those same challenges. This is directly downstream from Bluesky's "global firehose" topology and various design decisions that stem from that.