Nostr vs. AT Protocol (Bluesky): a complete guide

Nostr vs. AT Protocol (Bluesky): a complete guide

Social Media Platforms

Sep 16, 2025

TL;DR: Nostr is the bare-metal, “do-one-thing-well” protocol: signed messages sent to relays. AT Protocol (the tech under Bluesky) is a fuller social stack: portable accounts, typed data, indexing “firehoses,” moderation labelers, and pluggable services. Nostr is simpler and harder to kill; AT Proto is heavier but ships more product surface and governance knobs.

Why they exist

Social apps keep reinventing the same primitives (identity, posting, following, moderation). These protocols split those primitives from any one app so users and developers aren’t locked in. Nostr pursues minimum viable social - almost nothing but signed notes and relays. AT Proto aims for a complete social substrate - identity portability, typed data, network indexing, and composable moderation.

The goal is to create digital identities with data that can't be locked into one app (like TikTok or Facebook), granting all of us much more agency across apps and across the internet overall.

Mini-glossary

  • Relay (Nostr): server that accepts and serves signed events. You can use many at once.

  • NIP: “Nostr Implementation Possibility” (community specs, optional or mandatory).

  • PDS (AT Proto): Personal Data Server that hosts a user’s repo (posts, follows, etc.).

  • Relay (AT Proto): network indexer that builds the firehose stream for others to consume.

  • App View: a service (like Bluesky) that reads the firehose and serves timelines/search.

  • Lexicon: schema language that defines record types (posts, lists, etc.).

  • DID/Handle: stable machine ID / human-readable domain-based name in AT Proto.


How Nostr works (technical breakdown)

  • Keys, not usernames. You generate a cryptographic keypair; your public key is “you.” You map that key to name@domain so humans can recognize you.

  • Events, not posts. Everything is an event (JSON), signed with your private key. You send events to one or more relays via WebSocket; readers subscribe to relays to receive them. Relays can accept, reject, or charge for traffic.

  • Features via NIPs. The community adds features as “NIPs” (Nostr Implementation Possibilities): e.g., identity (NIP-05), encrypted payload conventions, “zaps” (Bitcoin Lightning tips) in NIP-57. Clients/relays adopt what they want.

What it's like: very simple plumbing. You can build a working client (app) in an afternoon. It’s resilient (many relays) and permissionless, but there’s minimal structure and little built-in help for spam, discovery, or safety. (Those are left to clients/relays and community lists.)


How AT Protocol works (technical breakdown)

  • Portable accounts. Your account has two parts: a human-readable handle (like @yourname.com) and a stable DID (machine ID). Handles are proven with DNS or a /.well-known/ file; the DID anchors cryptographic keys and your data repository.

  • Personal Data Server (PDS). Your posts, likes, follows, etc. live in a repo on your PDS. You can migrate to a different PDS without losing your identity (DID).

  • Relays & firehose. Independent Relays crawl PDS updates and publish a firehose stream others can consume to index the network. This powers search, ranking, and analytics services.

  • App Views & feeds. An App View (e.g., Bluesky) reads the firehose and serves timelines. Feed generators let anyone ship custom rankings (like “Top News”) without owning your account or data.

  • Typed data & APIs. Content is typed using Lexicons (schemas) and accessed via APIs. That makes interop reliable (a post looks like a post everywhere) and allows many content types beyond tweets-style notes.

  • Stackable moderation. The protocol supports labelers (third parties that attach labels like “NSFW” or “spam”), network-level takedowns from APIs, and user controls (mutes/blocks). Clients choose which labelers to trust.

What it's like: more like an operating system for social apps. It’s heavier to run but gives product teams moderation levers, typed data, and global indexing that users expect from modern networks.


Identity and portability

  • Nostr: Your pubkey is your identity. If a relay dies, your key and content that lives on other relays persists; you can point clients at different relays instantly. Human verification via NIP-05 (name@domain) is optional and DNS-based.

  • AT Proto: Your identity is your DID. You can move your account between PDSs while keeping the DID. Your handle (domain) is the friendly label; DNS proves you control it. If you change DIDs (e.g., across DID methods), followers don’t automatically come along.


Moderation & safety

  • Nostr: No central policy; relays and clients decide. Communities rely on block/mute lists, curated relays, and social norms. Great for speech resilience; harder for spam/abuse-sensitive audiences without careful relay curation. (Security researchers have also noted practical implementation pitfalls to watch.)

  • AT Proto: Composable moderation: labelers attach machine- or human-generated labels; networks can filter based on labels; users retain final control. Bluesky’s docs describe network takedowns, labels, and user tools layered together.


Payments & ecosystem extras

  • Nostr: Native-adjacent Bitcoin via zaps (NIP-57). Clients can show and relay Lightning tips; wallets post receipt events. This is cultural glue in some Nostr communities.

  • AT Proto: No built-in payments; apps can integrate whatever they like at higher layers. The protocol focuses on identity, data, interop, and moderation.


Centralization risks

  • Nostr: Anyone can run relays, but attention tends to pool on a handful of popular ones; discovery and anti-spam can make those relays influential. Still, the core is minimized: if one relay disappears, you point your client at others.

  • AT Proto: Power concentrates in Relays (which control the firehose) and the biggest App Views. Critics note the risk that a small set of infra operators shape the network; Bluesky publishes architecture and moderation approaches to make that influence auditable and swappable.


What each is best for

Choose Nostr if you want:

  • Maximum simplicity and resilience; lowest barrier to shipping a client/bot.

  • Bitcoin-adjacent culture (tips, “zaps”) and permissionless experiments.

  • You’re comfortable assembling curation/moderation yourself.

If you're building a censorship-resistant microblog or lightweight social website: start with Nostr.

Choose AT Protocol if you want:

  • Structured data, portable accounts, and a rich moderation/labeling layer.

  • To build feeds, search, analytics from a global firehose rather than crawling.

  • A smoother path to mass-market UX (via Bluesky) with typed records and interop guarantees.

If you’re building enterprise-grade feeds, moderation dashboards, or analytics for a big audience: start with AT Proto.


Side-by-side

Here's a quick breakdown:

Area

Nostr

AT Protocol (atproto)

Core idea

Post signed “events” to any number of relays; others read them

Users have portable accounts hosted on Personal Data Servers (PDS). Data is indexed by Relays into a firehose, then served by App Views (e.g., Bluesky)

Identity

Your public key is your identity; optional DNS mapping via NIP-05

Dual ID: human handle (a domain) + stable DID (decentralized identifier)

Data model

One generic “event” with kinds/tags; features added via community specs (NIPs)

Typed records defined by Lexicons (schemas), queried over XRPC APIs

Federation

You pick relays; each relay sets its own rules

Anyone can run PDS, Relays, App Views, feed generators, and labelers

Moderation

Primarily client/relay lists, blocks, and local policies

Stackable moderation: labels by third-party labelers + network takedowns + user controls

Portability

Keep your key, move between relays easily

Migrate your account between PDSs; followers are tied to the DID (not just handle)

Dev ergonomics

Easiest way to build a simple client or bot

Richer building blocks (schemas, feeds, labels) but more moving parts

Payments

Lightning “zaps” (optional)

No native payments in the protocol


Recap

Nostr is the Unix pipe of social: minimal, flexible, and hard to shut down. Great for builders who want raw, permissionless rails.

AT Protocol is the social OS: identity portability, typed data, moderation labelers, and indexers. Great for shipping polished, governed social apps.

Nostr vs. AT Protocol (Bluesky): a complete guide

TL;DR: Nostr is the bare-metal, “do-one-thing-well” protocol: signed messages sent to relays. AT Protocol (the tech under Bluesky) is a fuller social stack: portable accounts, typed data, indexing “firehoses,” moderation labelers, and pluggable services. Nostr is simpler and harder to kill; AT Proto is heavier but ships more product surface and governance knobs.

Recent articles:

Analyzing the TikTok Acquisition

Nostr vs. AT Protocol (Bluesky): a complete guide

The Flaws of Sentiment Analysis

Siftree Explained

How Siftree Works

Nostr Protocol

How Nostr Works (Simplified)

Why they exist

Social apps keep reinventing the same primitives (identity, posting, following, moderation). These protocols split those primitives from any one app so users and developers aren’t locked in. Nostr pursues minimum viable social - almost nothing but signed notes and relays. AT Proto aims for a complete social substrate - identity portability, typed data, network indexing, and composable moderation.

The goal is to create digital identities with data that can't be locked into one app (like TikTok or Facebook), granting all of us much more agency across apps and across the internet overall.

Mini-glossary

  • Relay (Nostr): server that accepts and serves signed events. You can use many at once.

  • NIP: “Nostr Implementation Possibility” (community specs, optional or mandatory).

  • PDS (AT Proto): Personal Data Server that hosts a user’s repo (posts, follows, etc.).

  • Relay (AT Proto): network indexer that builds the firehose stream for others to consume.

  • App View: a service (like Bluesky) that reads the firehose and serves timelines/search.

  • Lexicon: schema language that defines record types (posts, lists, etc.).

  • DID/Handle: stable machine ID / human-readable domain-based name in AT Proto.


How Nostr works (technical breakdown)

  • Keys, not usernames. You generate a cryptographic keypair; your public key is “you.” You map that key to name@domain so humans can recognize you.

  • Events, not posts. Everything is an event (JSON), signed with your private key. You send events to one or more relays via WebSocket; readers subscribe to relays to receive them. Relays can accept, reject, or charge for traffic.

  • Features via NIPs. The community adds features as “NIPs” (Nostr Implementation Possibilities): e.g., identity (NIP-05), encrypted payload conventions, “zaps” (Bitcoin Lightning tips) in NIP-57. Clients/relays adopt what they want.

What it's like: very simple plumbing. You can build a working client (app) in an afternoon. It’s resilient (many relays) and permissionless, but there’s minimal structure and little built-in help for spam, discovery, or safety. (Those are left to clients/relays and community lists.)


How AT Protocol works (technical breakdown)

  • Portable accounts. Your account has two parts: a human-readable handle (like @yourname.com) and a stable DID (machine ID). Handles are proven with DNS or a /.well-known/ file; the DID anchors cryptographic keys and your data repository.

  • Personal Data Server (PDS). Your posts, likes, follows, etc. live in a repo on your PDS. You can migrate to a different PDS without losing your identity (DID).

  • Relays & firehose. Independent Relays crawl PDS updates and publish a firehose stream others can consume to index the network. This powers search, ranking, and analytics services.

  • App Views & feeds. An App View (e.g., Bluesky) reads the firehose and serves timelines. Feed generators let anyone ship custom rankings (like “Top News”) without owning your account or data.

  • Typed data & APIs. Content is typed using Lexicons (schemas) and accessed via APIs. That makes interop reliable (a post looks like a post everywhere) and allows many content types beyond tweets-style notes.

  • Stackable moderation. The protocol supports labelers (third parties that attach labels like “NSFW” or “spam”), network-level takedowns from APIs, and user controls (mutes/blocks). Clients choose which labelers to trust.

What it's like: more like an operating system for social apps. It’s heavier to run but gives product teams moderation levers, typed data, and global indexing that users expect from modern networks.


Identity and portability

  • Nostr: Your pubkey is your identity. If a relay dies, your key and content that lives on other relays persists; you can point clients at different relays instantly. Human verification via NIP-05 (name@domain) is optional and DNS-based.

  • AT Proto: Your identity is your DID. You can move your account between PDSs while keeping the DID. Your handle (domain) is the friendly label; DNS proves you control it. If you change DIDs (e.g., across DID methods), followers don’t automatically come along.


Moderation & safety

  • Nostr: No central policy; relays and clients decide. Communities rely on block/mute lists, curated relays, and social norms. Great for speech resilience; harder for spam/abuse-sensitive audiences without careful relay curation. (Security researchers have also noted practical implementation pitfalls to watch.)

  • AT Proto: Composable moderation: labelers attach machine- or human-generated labels; networks can filter based on labels; users retain final control. Bluesky’s docs describe network takedowns, labels, and user tools layered together.


Payments & ecosystem extras

  • Nostr: Native-adjacent Bitcoin via zaps (NIP-57). Clients can show and relay Lightning tips; wallets post receipt events. This is cultural glue in some Nostr communities.

  • AT Proto: No built-in payments; apps can integrate whatever they like at higher layers. The protocol focuses on identity, data, interop, and moderation.


Centralization risks

  • Nostr: Anyone can run relays, but attention tends to pool on a handful of popular ones; discovery and anti-spam can make those relays influential. Still, the core is minimized: if one relay disappears, you point your client at others.

  • AT Proto: Power concentrates in Relays (which control the firehose) and the biggest App Views. Critics note the risk that a small set of infra operators shape the network; Bluesky publishes architecture and moderation approaches to make that influence auditable and swappable.


What each is best for

Choose Nostr if you want:

  • Maximum simplicity and resilience; lowest barrier to shipping a client/bot.

  • Bitcoin-adjacent culture (tips, “zaps”) and permissionless experiments.

  • You’re comfortable assembling curation/moderation yourself.

If you're building a censorship-resistant microblog or lightweight social website: start with Nostr.

Choose AT Protocol if you want:

  • Structured data, portable accounts, and a rich moderation/labeling layer.

  • To build feeds, search, analytics from a global firehose rather than crawling.

  • A smoother path to mass-market UX (via Bluesky) with typed records and interop guarantees.

If you’re building enterprise-grade feeds, moderation dashboards, or analytics for a big audience: start with AT Proto.


Side-by-side

Here's a quick breakdown:

Area

Nostr

AT Protocol (atproto)

Core idea

Post signed “events” to any number of relays; others read them

Users have portable accounts hosted on Personal Data Servers (PDS). Data is indexed by Relays into a firehose, then served by App Views (e.g., Bluesky)

Identity

Your public key is your identity; optional DNS mapping via NIP-05

Dual ID: human handle (a domain) + stable DID (decentralized identifier)

Data model

One generic “event” with kinds/tags; features added via community specs (NIPs)

Typed records defined by Lexicons (schemas), queried over XRPC APIs

Federation

You pick relays; each relay sets its own rules

Anyone can run PDS, Relays, App Views, feed generators, and labelers

Moderation

Primarily client/relay lists, blocks, and local policies

Stackable moderation: labels by third-party labelers + network takedowns + user controls

Portability

Keep your key, move between relays easily

Migrate your account between PDSs; followers are tied to the DID (not just handle)

Dev ergonomics

Easiest way to build a simple client or bot

Richer building blocks (schemas, feeds, labels) but more moving parts

Payments

Lightning “zaps” (optional)

No native payments in the protocol


Recap

Nostr is the Unix pipe of social: minimal, flexible, and hard to shut down. Great for builders who want raw, permissionless rails.

AT Protocol is the social OS: identity portability, typed data, moderation labelers, and indexers. Great for shipping polished, governed social apps.