Modern P2P and federated protocols in 2026: nostr, ATProto, ActivityPub, Willow, Iroh, Farcaster

The last four years produced more genuinely new protocols for user-owned internet than the previous fifteen. Each has partisans, none has an honest cross-protocol survey, and the trade-offs between them (moderation model, discoverability, portability, monetization surface) are the interesting part; the vendor blog posts pretend the trade-offs do not exist. This page is a working map for a developer or technical PM deciding what to build on, or a smart lay reader who wants to understand what these words actually mean. I have deliberately not included blockchain-first protocols; the design constraints of consensus mechanisms are different enough that they deserve their own list.

The protocols themselves, canonical starting points

Read the reference docs before the takes. Each of these is the specification or nearest-equivalent source of truth.

  • AT Protocol (atproto.com)
    The protocol Bluesky is built on. Federated identity, portable social graph, delegated moderation. Read the specs page and the 'lexicons' explainer before forming an opinion.
    webpage
  • ActivityPub (activitypub.rocks)
    The W3C-standard protocol Mastodon is built on. Older, larger deployed network, more mature moderation-per-instance model. The canonical protocol on which most other 'fediverse' work is layered.
    webpage
  • Nostr Protocol (github.com/nostr-protocol/nostr)
    The minimalist protocol: signed events, relays, no accounts. The design philosophy is intentionally different from ActivityPub's server-federation model. Read the NIPs (Nostr Implementation Possibilities) before the takes.
    webpage
  • Farcaster Protocol Docs
    The sufficient-decentralization design: on-chain identity, off-chain messages. Different trade-off frontier from Bluesky or Mastodon. The 'hubs' architecture is worth reading even if you never build on it.
    webpage
  • Willow Protocol (willowprotocol.org)
    The protocol trying to be to sync what ActivityPub is to messaging. Path-based namespacing, capability-based access, designed for both peer-to-peer and server-mediated deployment. Early but conceptually the most interesting.
    webpage
  • Iroh (Number 0's peer-to-peer stack)
    Not a social protocol; a peer-to-peer networking library. Under the hood of a lot of the modern P2P wave. The team's blog on hole punching, discovery, and content-addressed storage is the practical education.
    webpage

The design debates that actually matter

Where the partisans disagree, and where the trade-offs are real. Read these to understand why the protocols look so different from each other.

  • Gabe Anderegg: How decentralized is Bluesky, really? (a response)
    A level-headed practitioner's walk-through of the decentralization debate the Lemmer-Webber essay ignited, testing each claim against how the network actually behaves. The best neutral summary if you read only one piece on the argument.
    webpage
  • How decentralized is Bluesky, really? (Christine Lemmer-Webber)
    The most-cited critique of ATProto's centralization trade-offs, written by an ActivityPub author. Read it and the Bluesky team's responses; the disagreement is where the interesting design questions live.
    webpage
  • Bluesky's federation posts (docs.bsky.app)
    The ATProto team's own writing on federation and account portability, the design axis they argue matters most and that forced their architectural choices. Read after the Lemmer-Webber essay for the other side of the argument.
    webpage
  • fiatjaf's blog (Nostr creator)
    The Nostr protocol creator's personal site. Idiosyncratic, opinionated, essential for understanding what Nostr is trying to be that ActivityPub explicitly refused to be.
    webpage
  • Bryan Newbold: Reply on Bluesky and Decentralization
    The Bluesky protocol engineer's considered response to the ActivityPub camp's critique, published on WhiteWind (itself an ATProto blog platform). The most substantive single reply in the whole decentralization debate; read it paired with the dustycloud essay.
    webpage

Local-first and P2P as adjacent movements

Where user-owned social overlaps with user-owned data. The Ink and Switch canon plus the practical libraries.

  • Local-first software (Ink and Switch)
    The 2019 essay that named the movement. Read this once and everything else in the P2P and local-first space starts making sense. The seven ideals are not law, but they are the vocabulary the whole community uses.
    webpage
  • Automerge (automerge.org)
    The most-mature CRDT library targeting local-first apps. Written in Rust with JavaScript, Python, and Swift bindings. The team is the same one behind the original local-first essay.
    webpage
  • Loro (loro.dev)
    The newer CRDT library that made real inroads against Automerge in 2024-2025 by being smaller and faster in the JavaScript case. Practical if your target is web apps and you cannot ship a Rust binary.
    webpage
  • Electric SQL
    Postgres-first sync engine. The pragmatic answer for teams who want local-first sync without a CRDT learning curve. The 2025 rewrite around 'shapes' is the version to read the docs for.
    webpage
  • Holepunch and the Pear runtime
    The Bittorrent creators' peer-to-peer application runtime. Not federated protocol, not blockchain, actually peer-to-peer. Where the interesting non-server-mediated work is happening.
    webpage

Building on these protocols, practical entry points

For developers past the specs and ready to build. These are the SDKs and starter projects with actual momentum.

  • Bluesky developer docs (docs.bsky.app)
    The most beginner-friendly entry into ATProto. Getting a bot posting takes 30 minutes; the API surface is small and well-documented.
    webpage
  • Mastodon on GitHub
    The reference ActivityPub server implementation. Non-trivial to run at scale; a great codebase to read for how ActivityPub actually gets implemented.
    webpage
  • Nostr Implementation Possibilities (NIPs)
    The Nostr ecosystem's spec-through-proposal process. Reading a handful of NIPs is the fastest way to grok what building on Nostr actually looks like.
    webpage
  • Farcaster Frames spec
    The interactive-app-in-a-social-post pattern that briefly made Farcaster the interesting one. A useful case study in what an app-embedded protocol layer looks like.
    webpage
  • Iroh source (github.com/n0-computer/iroh)
    The Rust codebase for the peer-to-peer stack under many modern P2P apps. Well-written, useful even if you do not build on it directly.
    webpage

Thinkers, historians, and further reading

The people who have been writing about federated and P2P systems for longer than the current wave. The essential context.

  • Martin Kleppmann: Local-first software (YouTube)
    The canonical hour-long talk from the author of Designing Data-Intensive Applications, laying out the local-first movement's technical foundations. Watch before reading anything else.
    video
  • James Mickens: The Saddest Moment (PDF, USENIX)
    A comedy essay about distributed systems by a Harvard researcher that became a canonical read on why 'just make it a distributed system' does not solve your problem. Hosted by USENIX, where it originally ran. Read after a bad day of P2P debugging.
    document
  • Kyle Mitchell's blog (writing.kemitchell.com)
    Lawyer and open source thinker. The best writing on the governance question that every federated protocol eventually has to solve. Read before you have to write a code-of-conduct for anything.
    webpage
  • Ben Werdmuller's blog (werd.io)
    One of the small number of people who has been thinking and writing about federated social since well before the current wave. His indie-web writing is the historical context most of these protocols do not cite.
    webpage
  • Jeff Bailey: What Is the AT Protocol? A developer's mental model
    The clearest technical mental model of how ATProto separates storage, indexing, and product, and why that differs from ActivityPub's federation of monolithic servers. The single best onboarding read for a developer trying to place these protocols side by side.
    webpage