I was right about ATProto key management

P2P vs Federated vs Centralized Models

• One camp argues social protocols should be fully peer‑to‑peer (email/BitTorrent/PGP‑like), with websites as optional “views” over a swarm, not control points. This, they claim, would have prevented the key‑management failure in the article.
• Others counter that large‑scale, Twitter‑like systems need “beefy servers” and microservices; P2P alone struggles with hundreds of millions of posts/day, NAT, lack of inbound connections, and users unwilling to run always‑online nodes.
• Several propose hybrids: P2P plus federation, or ATProto‑style granular servers (PDS) and relays, where infrastructure can decentralize even if most people opt into hosted services.

ATProto, DIDs, and Key Management

• Many see the did:web flow as under‑documented and fragile; the “burn” mechanism that permanently blocks reused domains is viewed as a design mistake for inherently transient DNS identities.
• did:plc is described as centralized and controlled by Bluesky; critics see this as a single point of failure contradicting decentralization claims.
• Others argue did:plc is more pragmatic for most users and that did:web is currently an edge case with very few deployments, but agree its UX and tooling need major work.

Mastodon / ActivityPub Comparisons

• Critiques of Mastodon/ActivityPub include: federation wars and political moderation, incomplete migrations (posts/media lost), partial network views, no global search, security issues, and admins wielding disproportionate power.
• Defenders respond that these are side‑effects of genuine decentralization: no central authority to coordinate migrations or enforce compatibility, and local instances must filter to avoid spam/DoS.
• Some argue Mastodon has effectively become “a federated set of centralized services” and that lock‑in now shifts from platform to instance or protocol.

Spam, Micropayments, and Moderation

• A recurring concern: in a pure P2P system “the swarm is mostly spam,” and decentralized spam filtering either burdens every user or re‑centralizes moderation.
• Micropayment‑based filtering is debated: proponents see it as a way to price attention; critics note that spammers are often the only actors willing to pay, micropayments are unsolved at scale, and you risk building an inbox of paid spam.

Decentralization in Practice and User Priorities

• Several commenters argue most users don’t actually care about decentralization and are content with Bluesky as “Twitter but with better leadership,” making centralization sticky.
• Others warn that dominance of Bluesky‑run PDS, AppView, and did:plc means the company could later close APIs or defederate third parties, as happened with other “open” platforms in the past.

Complexity, Self‑Hosting, and UX

• ATProto is seen by some as over‑engineered and complexity‑heavy, effectively gating participation to well‑resourced operators; nostr, email, RSS, and simple pull‑based models are cited as friendlier alternatives.
• Others note that while complex, ATProto provides a strong basis for many multi‑user apps if you accept Twitter‑scale requirements, and that PDS/relay setup is relatively smooth compared to key management.
• There’s broad agreement that key handling and account recovery UX are neglected, and that “true ownership” requires making self‑hosting and identity management far simpler.

Size of Networks and Alternatives

• Some argue we don’t need global social graphs at all; Discord‑style or forum‑like small communities better match human social dynamics and avoid many moderation and scaling pathologies.
• Others push back that Discord itself is centralized and toxic in its own ways, suggesting old‑school forums/IRC as better small‑community analogues.

Meta: Article Presentation

• A noticeable side thread criticizes the blog’s “man‑page” aesthetic and low‑contrast colors as actively discouraging reading; others counter that style is the author’s prerogative and such complaints are off‑topic.