There are no instances in ATProto

Original Article ↗ Hacker News Discussion ↗

Debate over the AT Protocol, which underpins the social network Bluesky, centers on whether its architecture is meaningfully decentralized or just "decentral-washing." Supporters highlight its separation of roles—personal data servers (PDS), app views, and relays—plus portable identities and shared data models as an advance over Mastodon’s instance-centric ActivityPub model. Critics counter that Bluesky PBC still operates the dominant app, hosting, and key directories, making moderation power and funding risks highly concentrated despite the protocol’s technical openness.

Network architecture & “no instances”

  • ATProto splits roles into Personal Data Servers (PDS), AppViews, and optional Relays; hosting and applications are decoupled.
  • Relays are described as a performance optimization, not a fundamental piece: they rebroadcast events from many PDSes to many AppViews.
  • Some commenters argue this is semantic: PDSes, AppViews, and Relays still act like “instances” in practice, just grouped differently.
  • RSS/Google Reader analogies help some readers; others find them misleading because ATProto apps are server-side aggregators with strong control over what users see.

Comparison with ActivityPub / Mastodon

  • ActivityPub/Mastodon instances bundle identity, hosting, UI, and moderation, which:
    • Makes decentralization tangible (thousands of servers, users spread out).
    • But ties you to an instance and makes migration and scaling harder.
  • ATProto aims for:
    • Stable identity via DIDs and easier migration between hosts and apps.
    • A shared, typed data model so many apps can reuse and remix the same content.
  • Critics counter that, today, ATProto’s ecosystem is effectively dominated by one provider (Bluesky) in a way Mastodon is not.

Moderation, censorship, and governance

  • ATProto moderation happens at multiple layers: hosting, AppViews, relays, plus standardized “labeler” services that apps can choose to use.
  • Example given: a user banned on the main Bluesky app remains visible via another AppView that rejects Bluesky’s moderation decisions.
  • Skeptics note:
    • If most users stay on the main Bluesky AppView, being banned there is still functionally silencing.
    • There is only one PLC directory today; governance is moving to a Swiss entity and into IETF, but centralization risk remains.
    • Some see ATProto as “decentr‑washing” until there are many independent, widely used AppViews.

Costs, self‑hosting, and scalability

  • PDSes are cheap and can run on small VPSs or even Raspberry Pi–class hardware.
  • Relays that mirror the whole network now reportedly run at ~$20–30/month; AppViews are only “expensive” if you try to replicate the global Bluesky index.
  • Supporters say this is affordable for hobbyist developers and enables a market of shared infra; critics argue that:
    • $30/month and ops effort are non‑trivial in many regions.
    • In practice, only a handful of relays and AppViews exist, keeping power concentrated.

User experience, culture, and adoption

  • Pro‑ATProto voices emphasize:
    • Better UX path for non‑technical users than “pick an instance” Fedi onboarding.
    • Ability to reuse one identity across very different apps (microblogging, blogs, code hosting, etc.).
  • Pro‑ActivityPub voices emphasize:
    • Proven, working decentralization with many independent servers and funding models.
    • Cultural resilience: if a big Mastodon server dies, the network mostly keeps going.
  • Open questions raised:
    • Whether ATProto will remain dominated by Bluesky or evolve into a genuinely multi‑provider ecosystem.
    • Whether technical portability will translate into real cultural and economic independence from the founding company.