Two answers to the same question
Nostr and Bluesky are both trying to escape the same trap: a social network where one company owns your identity, your audience, and your data. They arrive at very different architectures, and the difference is worth understanding on its own terms before deciding which trade-offs you can live with.
The shortest way to put it: Nostr makes your identity a cryptographic key and treats servers as interchangeable dumb pipes. Bluesky makes your identity a portable name backed by a document, and splits the work across a few specialized kinds of servers. Both are more open than the platforms they want to replace. They just draw the lines in different places.
Identity: a key versus a DID
In Nostr, you are your key. Your identity is a secp256k1 keypair. Your public key is your account, full stop. There is no registration, no server that grants you an identity, and nothing to resolve: the key is the account. Sign an event and anyone can verify it came from you. Lose the key and you lose the identity; there is no recovery desk to call.
Bluesky separates the human-readable name from the underlying identity. Your account is a DID: a decentralized identifier, usually a did:plc document that records your signing keys and points at the server currently hosting you. Your handle (like alice.bsky.social) is just a friendly alias that resolves to that DID through DNS or an HTTP endpoint. Because the DID is a layer of indirection, you can change handles, rotate keys, and move hosts without changing who you fundamentally are.
That indirection is the crux of the design difference. Nostr's model is beautifully simple and has no moving parts, but the key is everything and key management is entirely on you. Bluesky's model is more forgiving (you can recover, rename, and migrate), but it leans on a resolution system, and the most common DID method (did:plc) currently depends on an operator-run directory. It is designed to be replaceable, but today it is a coordination point that Nostr simply does not have.
Servers: relays versus PDS + Relay + AppView
This is where the architectures diverge most.
Nostr has exactly one kind of server: the relay. A relay accepts signed events and serves them back on request. That is the whole job. Relays do not resolve identity, do not build feeds, do not know anything about each other. Clients talk to many relays at once. Anyone can run one in an afternoon. The simplicity is the point, and the cost is that a relay makes no promise to keep your data, so availability is best-effort across whatever relays you happen to publish to.
Bluesky splits the work into three roles:
- PDS (Personal Data Server): hosts your repository, a signed Merkle tree of all your posts and likes. This is your data's actual home. You can self-host it or use a provider.
- Relay: a firehose aggregator that crawls PDSes and republishes the combined stream of everyone's activity.
- AppView: indexes that firehose into the feeds, threads, and search that an app actually shows you.
| Layer | Nostr | Bluesky (AT Protocol) |
|---|---|---|
| Identity | Public key (npub) | DID + handle |
| Your data lives on | Whatever relays you post to | Your PDS repository |
| Aggregation | None: clients query relays directly | Relay firehose crawls all PDSes |
| Feed building | Client-side or specialized relays | AppView indexers |
| Run-it-yourself bar | Very low (a relay) | Higher (PDS is easy, Relay/AppView are heavy) |
| Moderation | Client-side + relay policy | Composable labelers |
Portability: what actually moves
Both networks say "your data is portable." They mean genuinely different things.
In Nostr, portability is trivial because there is nothing to move. Your events are signed and self-authenticating; you republish them to any relay and they are just as valid. There is no account to migrate because there was never an account tied to a server in the first place.
In Bluesky, portability is an explicit, engineered feature. Because your repository is a signed data structure and your identity is a DID that points at whatever host you choose, you can migrate your entire account from one PDS to another and keep your followers, your posts, and your handle. This is a real achievement and something centralized platforms never offered. The caveat is that it depends on the DID resolution layer continuing to work and on hosts implementing account migration correctly.
So: Nostr gives you portability by making servers disposable. Bluesky gives you portability by making your identity independent of any one server while keeping the servers meaningful.
Censorship resistance: where the trade-offs bite
Here I want to be fair to both, because neither is magic.
Nostr's censorship resistance is strong at the identity layer and weaker at the availability layer. No one can take your key or forge your posts. But if the relays carrying your content decide to drop it, your reach depends on finding other relays that will carry it. Resistance to being silenced is high; resistance to being forgotten is only as good as your relay coverage.
Bluesky's design is more capable (richer feeds, labeling, migration), but that capability concentrates gravity. Running the full stack (Relay firehose plus AppView) is expensive, so in practice a small number of large indexers see almost everyone's data. The protocol permits alternatives, and that permission matters, but permission is not the same as a thriving plurality of independent AppViews. The identity layer is portable; the discovery layer tends toward centralization by economics rather than by design.
Neither is a villain here. They optimized for different fears. Nostr feared a server that owns you and removed the server's power over your identity. Bluesky feared a bad user experience and built the infrastructure to deliver a good one, accepting some concentration as the price.
Where Gozzip fits
Gozzip starts from the Nostr side of this map: your identity is your key, your events are self-authenticating, and no server owns you. Then it addresses the one place Nostr is weakest, availability, without importing Bluesky's concentration.
Instead of hoping relays keep your data, Gozzip stores it on your social graph. The people you trust hold your events through reciprocal storage pacts, and reads cascade from your own cache, to your contacts' pact storage, to relays only as a last resort. You get Bluesky-style resilience (your data has a real home that survives you going offline), but that home is your friends, not a heavyweight indexer.
And because Gozzip events are still Nostr events, portability stays maximal: public content bridges out to ActivityPub, the AT Protocol, and RSS. If you want the simplicity of keys and the durability of a hosted home, without betting your reach on a firehose someone else pays for, that is exactly the seam Gozzip is built to sit in.
