Bluesky Trademarks ATProto

Original Article ↗ Hacker News Discussion ↗

Bluesky’s acquisition of the “AT Protocol” trademark, ostensibly to block another company from restricting community use, has renewed scrutiny of how decentralized the AT Protocol ecosystem really is. Commenters debate whether Bluesky’s control over key components like the PLC identity directory, major relays, and the dominant client app leaves the network effectively centralized despite the protocol’s design for independent hosting and apps. Others point to alternative implementations, ongoing IETF standardization work, and third‑party infrastructure as evidence that the ecosystem can evolve beyond a single corporate steward, provided governance and migration tools improve.

Trademark origin and purpose

  • Another company (Atsign, Inc.) had filed for “ATPROTOCOL” and was reportedly threatening legal action over others’ use.
  • Bluesky acquired the mark to prevent that entity from restricting the community’s use and now licenses it to other projects.
  • Some see this as a pragmatic defensive move; others worry about long‑term control, even if there are hints it may later be transferred to a neutral organization.

Governance, PLC, and independence

  • ATProto is being standardized via an IETF working group; some were initially unsure if IETF or WGs can own trademarks.
  • Bluesky is a public benefit corporation, but commenters note that doesn’t guarantee user‑first decisions.
  • The PLC identity directory is still viewed as a central point of control; transfer to a separate governance org is seen as overdue.
  • There is concern that U.S. sanctions or similar pressures could lead to identity‑level deplatforming.

“Instances”, topology, and centralization

  • A major thread debates whether it’s accurate to say Bluesky runs the “only viable instance.”
  • Pro‑ATProto side: there are no “instances” in the Mastodon sense; hosting (PDS), indexing/relays, and apps are decoupled; anyone can run each piece, and multiple independent stacks already exist.
  • Critics: in practice, most data and traffic still flow through Bluesky’s infrastructure, so effective centralization remains high.

Self‑hosting, DIDs, and migration

  • Users can self‑host PDSs and use did:web to avoid PLC, but DIDs are immutable: you can’t migrate from did:plc to did:web without losing your graph.
  • This is seen as a major limitation for those who started on Bluesky’s default setup.
  • GUI tools for PDS migration have improved, but DID migration remains unsolved.

Wsocial and rate limiting

  • The troubled launch of Wsocial is cited as evidence of central control: their traffic hit relay rate limits and they effectively couldn’t participate without coordination.
  • Others counter that rate limiting and operator coordination are normal in federated systems (comparing to Mastodon and email) and that other relays and indexes exist.

Comparisons with ActivityPub and Nostr

  • Some argue ActivityPub/Nostr are more straightforwardly decentralized and easier/cheaper to deploy.
  • ATProto supporters respond that ATProto targets a different problem set (high‑scale, shared data layer, app portability), closer to “typed RSS,” and that multiple non‑Bluesky apps and services already run on the stack.

Legacy “AT protocol” confusion

  • A side thread notes the old modem “AT command set,” sometimes informally called an “AT protocol,” but most agree this doesn’t practically affect the trademark.