ATProto and the ownership of identity

ATProto architecture and decentralization

• ATProto has PDSes (personal data servers), relays, and AppViews; some see it as a “shared heap” that’s not very decentralized or self-hosting‑friendly.
• Core components are mostly open source; some features (DMs, mutes) are closed and not stored in user PDSes.
• Third parties can implement subsets (e.g., feeds, moderation, recommendation) without full protocol coverage.
• There’s an independent lexicon community standardizing reusable schemas (e.g., calendar, locations, events).

Identity, DIDs, and ownership

• ATProto identities are DIDs; domains are handles. Most resolution goes through a single plc.directory controlled by Bluesky.
• did:web exists and is more independent, but rarely used; some confusion over where DID documents live vs .well-known/atproto-did.
• Plans are mentioned to move did:plc to a neutral, DNS‑like body, but this is not yet realized.
• Opaque, non‑expiring DIDs reduce squatting and accidental takeover but introduce central directory risk.
• Some argue this is not “true” ownership until Bluesky’s control is reduced; others see cooperative “plc2” migration as a fallback, albeit messy.

Domains as identity handles

• Many like domain-based handles and portability across apps; tools exist to manage domain handles.
• Others note non‑technical users dislike domains and prefer simple names + checkmarks from a central authority.
• Concerns: phishing lookalikes (e.g., minor spelling changes), multiple plausible domains per person, trademark conflicts, expirations, and registrar/registry power.
• Debate over whether domains are “owned” vs leased; EU law treating domains as property is cited, but revocation and seizure remain real.
• Some find paying for a domain/identity dystopian; others compare it to paying for phone numbers or ID cards.

Verification, trust, and proof‑of‑humanity

• Strong separation between identity verification and moderation is seen as crucial; when conflated, systems lose value.
• Proposals include domain‑based attestation layers, monetary collateral, charitable donations, or BIMI‑style logo certificates, but risks of corruption and over‑centralized authorities are raised.
• A “humans‑only” social network using passport NFC data is proposed; critics highlight privacy risks, reliance on a central broker, government and key‑loss issues, and ease of abuse (e.g., bribed IDs).
• Alternatives like fees, biometrics, device attestation, or Worldcoin‑style iris scans are discussed but viewed as imperfect or privacy‑hostile.

ATProto vs Fediverse and Nostr

• Some want the Fediverse to adopt DIDs to gain portable identities without migrating instances.
• Others argue Fediverse already allows identity migration (followers move, content doesn’t) and that choosing instances is still better than a single global platform.
• ATProto is criticized as overly complex with many abstractions; Nostr is praised for minimalism and easier end‑to‑end understanding, though its immutable key‑based identity and JSON hashing are also criticized.
• Disagreement exists on whether permanent keys are a feature or a “boneheaded” design that deters users concerned about key loss.

Bluesky app behavior and moderation

• The “nuclear block” (blocking someone hides their replies and thread context for everyone) is highly contentious.
• Critics say it lets one user corrupt entire conversations and breaks context; workarounds via third‑party tools are clumsy.
• Supporters see it as empowering users to moderate their own threads and effectively neutralize trolls and harassment.
• Broader point: microblog posts are likened to personal newspapers; you shouldn’t be forced to host replies you don’t want, but replies can still live elsewhere via quotes/embeds.