We need to protect the protocol that runs Bluesky

Original Article ↗ Hacker News Discussion ↗

Shared blocklists & echo chambers

  • Some see shared blocklists as supercharging echo chambers: whole groups can mass‑exclude dissent without scrutiny; mislabeling (e.g., “Nazi” or “pedophile” lists) is reported and hard to detect from the main app.
  • Others frame them as necessary safety tools to avoid gore, hate, spam, or harassment, and note precedents (Usenet killfiles, spam lists, adblock lists).
  • Several argue that subscribing to trusted list‑maintainers is rational given scale and “firehose of falsehood” tactics; manual per‑account blocking doesn’t scale on large networks.
  • Counterpoint: outsourcing blocks to opaque lists risks false positives, invisible ostracism, and people disappearing from each other’s view without ever interacting.

Bluesky’s block model (“nuclear block”)

  • Major debate around Bluesky’s design where if A blocks B, B’s replies in A’s thread vanish from the thread view for everyone.
  • Critics say this lets the first blocker suppress rebuttals platform‑wide within that thread, breaks conversations for third parties, and encourages escalation and “block culture.”
  • Defenders argue users should control who can reply to their posts; blocking is like ejecting someone from your house, not censorship, and blocked users can still post on their own feed.
  • Technical dispute: some claim this reply‑hiding is enforced by server‑side thread APIs (hard to override); others say alternative app views can show blocked content. Exact limits are contested/unclear.

Decentralization and competing protocols

  • Many question why the article centers ATProto/Bluesky and barely mentions ActivityPub/Mastodon, which already federate widely and are W3C‑standardized.
  • Critics view Bluesky as “Twitter 2.0 with a protocol veneer,” with real control still concentrated (ID registry, primary relays, default PDS, branding). Some call its decentralization “appearance” only.
  • Others argue ATProto improves on ActivityPub: easier account migration, data portability, pluggable moderation/feeds, and less user‑visible server choice.
  • Mastodon is praised for diversity and actual federation, but criticized for: confusing server choice, defederation politics, drama between instances, weak discovery, slow development, and instance‑level power over users.
  • Nostr is mentioned as more censorship‑resistant (relays instead of accounts; keys as identity) but smaller and dominated by Bitcoin culture, with scaling challenges.

Discovery, UX, and adoption

  • Many say Mastodon’s discovery is “work”: no global full‑text search by design, hashtag reliance, and federated complexity; this is seen as a core reason it didn’t capture the Twitter exodus.
  • Bluesky is described as feeling like old Twitter: simple signup, central app, strong discovery via algorithms and custom feeds, and heavier non‑tech adoption.
  • Some users complain Bluesky’s default experience is heavily US‑political and left‑leaning; word‑mutes and filters reportedly don’t fully solve this.

Governance, moderation, and “protecting” ATProto

  • One camp says the protocol is already “protected” via permissive MIT/Apache and CC‑BY licensing; anyone can fork or reimplement without permission.
  • Others stress that as long as most users stay on Bluesky’s default app and servers, the company can still enshittify, de‑federate, or change behavior without losing its user base.
  • Proposed safeguard: shift identity registries and protocol governance to independent foundations, and encourage more third‑party PDSs and app views so Bluesky the app is no longer a choke point.