

Bluesky is one, single platform. It stores the complete data for any given user post in its databases and provides that through its data stream and APIs. This means every different client someone writes has access to all the same data as every other client, because they’re all going through Bluesky. This also means if Bluesky doesn’t support some feature, no clients can either.
The architecture of the Fediverse is different. Forgetting ActivityPub for a moment, Mastodon is one platform and Pixelfed is another. This means each one has its own data model, internal storage architecture, and streams/APIs. Because they were built for different purposes, they support different features. I don’t use either, but I expect there are image-related features in Pixelfed that are just not possible in a Mastodon client, not because someone hasn’t written a client capable of it, but because Mastodon doesn’t have the internal data storage nor API to support it in any client.
Where ActivityPub comes in is a unified stream language. When a post pops up on a platform, that platform has the complete data and translates as much as it can into an ActivityPub message to send to other platforms. Some platforms haven’t figured out yet how to pack all of their relevant data into an ActivityPub message, so some data may be lost in the sending. And different platforms may not support storing all the data in a given ActivityPub message they receive, especially if it’s from a feature they don’t provide, so some data may be lost in the receiving.
Ultimately this means even with ActivityPub linking things together, the data flow isn’t perfect/complete. So different data is available to any even theoretical Mastodon client compared to a Pixelfed client because the backend platforms are different. Their APIs expose different data in different, often incompatible ways, so even if someone wrote an image-focused client for Mastodon, it wouldn’t be possible to do everything an image-focused client for Pixelfed could do, because the backend platforms focus on different things.


Determinism means performing the same way every time it is run with the same inputs. It doesn’t mean it follows your mental model of how it should run. The article you cite talks about aggressive compiler optimizing causing unexpected crashes. Unexpected, not unpredictable. The author found the root cause and addressed it. Nothing there was nondeterministic. It was just not what the developer expected, or personally thought was an appropriate implementation, but it performed the same way every time. I think you keyed on the word “randomly” and missed “seemed to,” which completely changes the meaning of the sentence.
LLMs often act truly nondeterministically. You can create a fresh session and feed it exactly the same prompt and it will produce a different output. This unpredictability is poison for producing a quality product that is maintainable with dynamic LLM code generation in the pipeline.