Who owns your ATProto identity?

Original Article ↗ Hacker News Discussion ↗

Concerns over who truly controls user identities on Bluesky’s ATProto network are prompting scrutiny of its “decentralized” design. Commenters note that while the protocol allows self-hosted personal data servers and recovery keys, almost all users rely on Bluesky’s own infrastructure, meaning the operator can technically impersonate them or cut off portability under pressure from investors, governments, or business needs. Alternatives such as Mastodon, blockchain-based identity, and improved key-management schemes are raised, but many point out that usability, incentives, and centralization pressures remain unresolved across most open social protocols.

Bluesky / ATProto adoption and viability

  • Some posters argue Bluesky has “failed” in its mission to displace big social: growth has stalled or turned negative, DAUs are low relative to signups, and it risks becoming a “zombie company.”
  • Others counter that it is the most successful open social network so far: tens of millions of registered accounts, several million MAUs, significant cultural impact, and mainstream user adoption.
  • Criticism focuses on retention, brand perception (political echo chamber), and doubts about re‑activating churned users via new features (e.g., Communities).
  • Funding and runway (~2–3 years mentioned) raise concerns about eventual monetization and “enshittification,” especially given large VC/PE investment.

Decentralization, identity ownership, and PDS trust

  • Core concern: most users rely on Bluesky‑run PDSes that hold their signing keys, so the host can cryptographically impersonate them across ATProto apps.
  • Critics label this “faux decentralization”: while self‑hosting is possible, ~99.9% allegedly do not, and incentives mean they likely never will.
  • Supporters argue ATProto is still a meaningful improvement over X‑style centralization: multiple PDS choices, migration capability, and self‑hosting for those who care.

Keys, DIDs, and recovery

  • ATProto supports DIDs, rotation keys, and recovery keys; in principle users can:
    • Add their own keys, override a hostile PDS, and even do “adversarial migration.”
    • Use did:web with their own domain or did:plc with higher‑priority keys.
  • Thread consensus: these tools exist but are underused; UX is poor and almost no one sets up recovery/PLC keys. Some suggest Proton‑style onboarding that auto‑creates and surfaces recovery keys.

Blockchain and alternative identity models

  • Some see blockchains as a good fit for self‑sovereign identity and key recovery (e.g., smart contracts, petname systems, Farcaster‑style schemes).
  • Others question incentives for non‑financial chains and highlight fees, inequality, and complexity.
  • Several note that many of these benefits can be achieved with non‑blockchain cryptography (multisig, secret sharing, hierarchical keys).

Fediverse and other protocol comparisons

  • Fediverse proponents emphasize true decentralization and self‑hosting; critics point to friction, fragmentation, and lack of a stable “default instance.”
  • ATProto is seen as trading off stronger centralization in practice for smoother UX and broader reach.

Security vs. usability and “normal users”

  • Many argue that expecting typical users to safely manage private keys is unrealistic; lost devices, no backups, and web‑only use are common.
  • There is recurring tension between robust client‑held keys and the realities of web UX and mass adoption.