When imperfect systems are good: Bluesky's lossy timelines

Status of AppView and Open Source

• Multiple commenters clarify that much of Bluesky’s stack is open source: client, protocol libraries, and a Postgres-based AppView implementation.
• The high-performance Scylla-based AppView dataplane and some “extra” supporting services (e.g. discovery feed generator) remain closed, described as deployment-specific and expensive to run.
• There is confusion over the term “AppView”: some use it loosely to include client/UI; others insist it specifically refers to backend components as per the ATProto glossary.

Decentralization and Power of Bluesky

• Critics argue Bluesky is de facto centralized: meaningful participation requires being on the main relay/AppView; replicating it is said to cost large sums annually.
• Defenders note that third-party PDSs are supported and timelines are generated for users on those, and that identities can be moved between hosts via custom domains.
• Skeptics counter that if the dominant provider blocks you, you effectively lose access to most of the network, similar in effect to large Mastodon instances defederating small ones.

Monetization, Profit, and VC Concerns

• Many express worry that as a VC-funded for‑profit company, Bluesky is on an eventual “enshittification” path similar to Twitter/Reddit.
• Others distinguish between needing sustainable revenue vs. endless growth, and suggest foundations, donations, cosmetics, or analytics tools as possible models.
• Some highlight that Bluesky’s very low headcount and efficient hardware use could keep costs manageable, but doubt investors will accept modest, non‑hypergrowth outcomes.

Lossy Timelines Design & Alternatives

• The article’s “lossy timelines” solution—dropping some timeline updates for accounts that follow very large numbers of users—is generally seen as a pragmatic trade-off to tame hot shards and tail latency.
• Some worry this penalizes users who follow many low-activity accounts or leads to missing posts even when only a few followees are active; suggestions include basing lossiness on actual feed activity instead of raw follow count.
• Alternatives discussed: hybrid fan-out/fan-in (treat celebrities differently), shard-per-follower subsets, shuffle sharding, dynamic batching, and queue-based or more parallel fanout pipelines.

Comparisons and Broader Reflections

• Several compare Bluesky’s approach to Mastodon/ActivityPub and Nostr: Bluesky is viewed as more polished and better-engineered, but less inherently decentralized.
• Others tie the “imperfect systems” theme to control theory, search engine ranking, and prior large-scale systems, arguing that best-effort, probabilistic behavior is often acceptable—and sometimes necessary—for social feeds.