A new form of verification on Bluesky

Original Article ↗ Hacker News Discussion ↗

Compatibility with “future adversary” & decentralization

  • Some argue Bluesky moderators reviewing verifications conflicts with the idea that “the company is a future adversary.”
  • Others reply that the protocol stays open: any account can verify any other; only the client (e.g., bsky.app) decides which verifiers surface as blue checks.
  • Mitigation if Bluesky turns hostile would rely on: alternative clients/AppViews, independent labelers, competing global indexes, and more self-hosted data. Right now, bsky.app is a single point of failure.

What “verification” means

  • Ongoing confusion between:
    • “This is who they say they are” (identity),
    • “This person is important/notable,”
    • and “We endorse/trust what they say.”
  • Critics note Twitter’s path: identity check → elitist caste/status symbol → Musk-era pay-for-check that gutted prior meaning.
  • Some see Bluesky’s “authentic and notable” language and NYT example as recreating status politics; others insist the real goal is stopping impersonation of institutions, journalists, and banks.

Trusted verifiers vs centralization

  • Bluesky and a few “trusted verifiers” (e.g., media orgs) can issue checks; clients choose whose verifications count.
  • Supporters liken this to certificate authorities: centralized trust roots with potential delegation, revocation, and client choice.
  • Skeptics see “trusted verifiers” as top‑down gatekeepers, structurally similar to old Twitter verification or “trusted flaggers” under regulation, and worry about nepotism, politics, or abuse.
  • There is concern about how orgs are chosen, what exactly is being asserted, and how revocation and ex‑employees are handled.

Alternative designs and prior art

  • Some wanted Bluesky to lean harder on:
    • DNS / domain handles (seen as powerful but too technical for “normies”),
    • X.509/EV-style PKI,
    • Keybase‑like cross‑account cryptographic proofs,
    • Web‑of‑trust or Pagerank‑style “vouch”/influence graphs,
    • Richer use of existing labels (including per‑post and time‑scoped verification).
  • Web‑of‑trust systems (PGP, Thawte WoT, Keybase) are cited as conceptually appealing but historically hard to make usable and widely adopted.

Social and UX concerns

  • Some fear re‑introducing a “caste system” and “official teller of truth” dynamics, privileging big media and “important people.”
  • Others stress that many mainstream users expect simple badges and that demand for verification (and resistance to impersonation and bots) is real.
  • Clients already differ: some hide verification badges or even label/mute verified accounts; the protocol allows more user‑chosen trust models over time.