Why isn't Bluesky a peer-to-peer network?

P2P vs Federated vs Centralized Architecture

• Several commenters note Bluesky’s model looks less like pure P2P and more like the web or GitHub: user “personal data servers” plus larger infrastructure for aggregation.
• Critics argue Bluesky’s relays/“big graph servers” create unavoidable central points of control; defenders say relays are pluggable “busses” and PDSes can connect to many relays or directly, so authority is not fixed.
• Some suggest true P2P with authenticated posts and eventual deletion is possible but practically hard to enforce.

Discovery, Search, and Scale

• One side argues large indexing/search services are not strictly needed; social graphs, tags, and “friends-of-friends” views can give human-scale discovery.
• Others insist global search (by hashtag/topic, across millions of users) is essential for many real-world use cases and inevitably requires heavy storage and centralized indexing.
• Fediverse-style full replication is criticized as environmentally and technically expensive at global scale.

ActivityPub / Mastodon / Nostr Comparisons

• ActivityPub is seen as workable but flawed in practice: poor account migration, multiple identities per app type, lack of widely used client-to-server mode, and no easy “bring your own domain” on major implementations.
• Mastodon’s ecosystem: many nodes but a few large ones dominate because of costs, convenience, and social gravity. Small/self-hosted instances can feel isolated because they only see data they’ve explicitly fetched.
• Nostr is praised for a simple core spec but criticized for private-key-based identity, which many see as unusable for mainstream users and culturally tied to “crypto” communities.

Identity: Domains vs Public Keys

• Bluesky’s DNS-based identity (handles as hostnames, often own-domain) is widely liked; there’s discussion of simple HTTP or CNAME redirects from personal domains to profiles.
• Some worry domains are scarce, expire, and centralize control in registries and registrars; they advocate public-key identities as durable, storage-location-independent anchors.
• Others counter that keys are unreadable, hard to type, and meaningless to normal users; no single scheme fully satisfies memorability, decentralization, and security.

Moderation, Power, and Goals

• Competing narratives: Bluesky as a response to high-profile bans vs Bluesky as aiming to make providers “replaceable” and reduce platform capture, not to eliminate moderation.
• There is tension between wanting systems resistant to censorship and acknowledging that any ad-funded or centralized infrastructure tends to accumulate moderation power.

Product Positioning and User Experience

• Some see Bluesky as “slower Twitter” with unclear differentiation and weak search; others value exactly that slower, less algorithmic feel and lower toxicity.
• A key criticism is that developers focus on protocol minutiae while neglecting market positioning and long-term business models.
• Discovery of quality content remains a pain point: without a strong social graph or algorithms, new users struggle to find worthwhile feeds.

Technical Obstacles to True P2P

• Beyond NAT/firewalls, commenters highlight phones’ battery and bandwidth limits: always-on peer links require frequent keepalives, which are costly.
• Existing NAT-traversal frameworks (ICE/WebRTC, overlay networks) help but add complexity; there is no universally available “P2P equivalent of TCP/IP.”
• Some argue much of Bluesky’s architectural complexity is driven by working around these real-world deployment constraints.