We need to protect the protocol that runs Bluesky

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.