Bluesky announces data federation for self hosters

Original Article ↗ Hacker News Discussion ↗

Bluesky’s move to support self-hosted Personal Data Servers marks a major step toward its goal of an open, federated social network built on the AT Protocol, where users can own their identities and migrate between hosts. Commenters weigh the technical design — PDS, relays, and composable feeds/moderation — against concerns that Bluesky’s current dominance and VC backing could still allow it to recentralize control or “turn off” federation in practice. Comparisons with Mastodon, ActivityPub, and Nostr highlight trade-offs in decentralization, moderation responsibility, and interoperability, as well as unresolved questions about spam control, business models, and long‑term power dynamics.

Architecture, Federation, and Centralization Risk

  • AT Protocol introduces Personal Data Servers (PDS), relays, and “AppViews.” Users can self-host PDSs; relays aggregate data; AppViews provide feeds.
  • Supporters say this “locks things open”: protocol is open source, multiple relays are possible, and accounts are portable across PDSs.
  • Skeptics argue that as long as Bluesky’s main service holds ~99% of users, it can function like a central gatekeeper (e.g., shutting off federation, changing protocol unilaterally), similar to Google Chat’s XMPP exit.
  • Concern is raised about reliance on a central DID directory implementation and whether dominance will effectively “recentralize” the network.

Business Model and Ads

  • Questions about sustainability: current revenue includes a domain-name partnership; posters doubt this can fund a large network.
  • Bluesky messaging has strongly downplayed or rejected enshittifying ad models, but some point to blog language that leaves room for non-dominant advertising.
  • Several note that VC funding creates pressure that might eventually push the company toward proprietary changes or ad-driven decisions.

Moderation and Blocklists

  • Bluesky separates hosting from moderation: moderation services, block/mute lists, and feeds are meant to be “composable” and user- or community-selectable, rather than instance-level only.
  • Some like the flexibility and analogy to subreddit-style or plugin moderation; others fear it offloads hard work to volunteers and large corporations and can still produce opaque “global” power via popular blocklists.
  • Debate over whether externalized moderation really prevents abusive centralized control or just repackages it.

Comparisons to Mastodon, ActivityPub, Nostr, Web3

  • Many contrast AT with ActivityPub: some find AP under-specified and biased toward large instances; others say AP’s multi-protocol flexibility and existing ecosystem are strengths.
  • Arguments recur over whether Bluesky is just “Mastodon with a fancier tech stack and centralized indexer.”
  • Bridges between Bluesky and Mastodon are highly controversial, especially when opt-out; there is disagreement over whether “public is public” justifies cross-network copying.
  • Nostr and Web3-based systems are mentioned; some see them as better for self-sovereignty, others dismiss them due to crypto associations or cost/complexity.

Technical Self-Hosting Details

  • PDS reference implementation is MIT/Apache-2.0, dockerized, and currently scripted for Debian/Ubuntu; advanced users can run it elsewhere.
  • Initial relay-imposed rate limits per PDS are framed as anti-spam measures; critics see them as constraining independent large instances.
  • IPv4-only support and reliance on Discord for early operator coordination draw complaints; IPv6 support is “planned.”

Spam, Abuse, and Bad Actors

  • Posters worry that open federation enables unmoderated or extremist instances; others respond that this is inherent to any open protocol and must be handled via moderation services and defederation-like mechanisms at higher layers.
  • DMs are intentionally deferred; adding private messaging on a public-by-design protocol is seen as complex, especially for spam and privacy.

User Experience, Features, and Network Effects

  • Some think shipping federation before DMs/video is correct for a protocol-focused project; others argue mainstream users prioritize features over protocol design.
  • Comparisons with Twitter/X and Mastodon highlight:
    • Bluesky praised for custom feeds and early community quality.
    • Criticism that without video, DMs, and mass adoption, it feels like a niche “HN crowd” toy.
  • Strong view that long-term success will depend on whether Bluesky can escape being the overwhelmingly dominant node and whether third-party apps/servers flourish.