Nostr (Notes and Other Stuff Transmitted by Relays)

What Is Nostr?

Nostr (an acronym for Notes and Other Stuff Transmitted by Relays) is a decentralized, open protocol for transmitting signed messages across a network of relay servers. Unlike traditional social platforms that control user accounts and content, Nostr gives each user a cryptographic keypair that serves as their portable identity. No company owns the network, no server can ban your account, and no algorithm decides what you see.

The protocol was created in 2020 by a Brazilian developer known by the pseudonym fiatjaf, motivated by growing frustration with centralized platforms banning users and controlling speech. Earlier decentralized alternatives like ActivityPub (Mastodon) and Secure Scuttlebutt solved some problems but introduced others: complex federation rules, server admin gatekeeping, or heavy peer-to-peer requirements. Fiatjaf designed Nostr to be radically simple: just keys, events, and relays.

The protocol gained significant traction in 2023 after Jack Dorsey (Twitter co-founder) donated Bitcoin to Nostr developers and publicly endorsed the project. By 2025, Dorsey had contributed over $10 million to Nostr development collectives, and the ecosystem had grown to include dozens of clients, thousands of relays, and millions of users.

How It Works

Nostr's architecture has three components: keys, events, and relays. The protocol intentionally avoids consensus mechanisms, gossip layers, or peer-to-peer relay communication. This simplicity is a feature, not a limitation.

Keys and Identity

Every Nostr user generates a keypair using the secp256k1 elliptic curve, the same curve used by Bitcoin. Schnorr signatures (as defined in BIP-340) authenticate every message. Your public key is your identity: a 32-byte hex string, often encoded in a human-readable format prefixed with npub. Your private key (prefixed nsec) signs events and must be kept secret.

Because Nostr uses the same cryptographic primitives as Bitcoin, a user who already manages Bitcoin keys can reason about Nostr key security in familiar terms. The identity is not tied to any server or domain: if a relay goes offline, the user simply publishes to another relay without losing their identity.

Events

The only data structure in Nostr is the event. Every piece of content (a short post, a profile update, a reaction, a direct message) is an event signed by the author's private key. An event contains these fields:

{
  "id": "32-byte hex hash of the serialized event",
  "pubkey": "32-byte hex public key of the author",
  "created_at": 1719000000,
  "kind": 1,
  "tags": [["e", "referenced-event-id"], ["p", "mentioned-pubkey"]],
  "content": "Hello, Nostr!",
  "sig": "64-byte hex Schnorr signature"
}

The kind field determines what the event represents. Key event kinds include:

Because every event is signed with a digital signature, anyone can verify its authenticity without trusting the relay that served it. This is a fundamental difference from centralized platforms: the relay cannot forge or alter content.

Relays

Relays are simple WebSocket servers that accept, store, and forward events. Clients communicate with relays using three message types defined in NIP-01:

• ["EVENT", event]: publish a signed event
• ["REQ", subscription_id, filters]: subscribe to events matching specific criteria
• ["CLOSE", subscription_id]: end a subscription

Relays do not communicate with each other. There is no gossip protocol, no consensus mechanism, and no blockchain. Each relay operates independently, storing whatever events it chooses to accept. Users typically publish to multiple relays for redundancy, and clients aggregate events from multiple relays to build a feed.

Anyone can run a relay: the software is open source, the protocol is simple, and the hardware requirements are modest. Some relays are free and public, while others charge fees or restrict access to curate content quality. If a relay censors a user, that user simply publishes to other relays without losing their identity or followers.

Key NIPs (Nostr Implementation Possibilities)

The Nostr protocol evolves through NIPs: community-authored specifications that define new event kinds, relay behaviors, and client features. NIPs function similarly to Bitcoin Improvement Proposals (BIPs). Several NIPs are especially important for understanding the ecosystem:

NIP-05: DNS-Based Verification

NIP-05 maps a Nostr public key to a human-readable internet identifier like alice@example.com. The domain owner hosts a .well-known/nostr.json file that maps names to public keys. This provides a form of identity verification: if you trust the domain, you can trust the mapping. It does not replace the keypair but adds a layer of discoverability.

NIP-57: Lightning Zaps

NIP-57 defines how Lightning payments integrate with Nostr events. A "zap" is a Lightning micropayment attached to a specific note or user profile. The process works as follows:

1. A client creates a kind 9734 zap request containing the recipient, the note being zapped, and the amount
2. The client sends this request to the recipient's LNURL server, which returns a Lightning invoice
3. The sender pays the invoice via the Lightning Network
4. The LNURL server publishes a kind 9735 zap receipt to Nostr relays, creating a publicly verifiable record of the payment

Zaps turn passive social interactions (likes, retweets) into economic signals. A post with 50,000 sats in zaps carries more weight than one with 50 likes because real money was committed. This creates a censorship-resistant alternative to ad-driven engagement metrics.

NIP-47: Nostr Wallet Connect (NWC)

NIP-47 defines a protocol for Nostr clients to interact with a user's remote Lightning wallet. Instead of each client implementing its own wallet, NWC allows any Nostr app to send and receive Lightning payments through a wallet the user has already configured.

Communication happens via end-to-end encrypted Nostr events between the client and the wallet service. The relay forwards encrypted messages but cannot read the payment details. Importantly, the user's main Nostr identity key is not used for NWC messages, preventing payment activity from being linked to their public social identity.

NWC supports operations including paying invoices, creating invoices, checking balances, and listing transactions. Wallets like Alby and Zeus implement NWC, allowing users to zap from any Nostr client without switching apps.

Why the Bitcoin Community Adopted Nostr

Nostr's rapid adoption within the Bitcoin community is not coincidental. The two protocols share foundational principles and technical building blocks:

• Cryptographic identity: both use secp256k1 keypairs and Schnorr signatures, so Bitcoin users already understand the security model
• Censorship resistance: just as Bitcoin transactions cannot be blocked by a single entity, Nostr posts cannot be suppressed by a single relay
• Self-sovereignty: users control their own keys and data, with no platform that can revoke access or delete accounts
• Native Lightning integration: zaps create a direct economic layer on top of social interactions, powered by the same Lightning channels that handle Bitcoin payments
• Open protocol ethos: both Bitcoin and Nostr are open-source protocols that anyone can build on, not products controlled by a company

For a deeper analysis of how Nostr intersects with Bitcoin identity and payment systems, see the Nostr, Bitcoin Identity, and Payments research article.

Use Cases

Social Media

The most visible Nostr application is decentralized social media. Major clients include:

• Damus: the iOS client that brought Nostr to mainstream attention after its App Store approval in early 2023, featuring Lightning zaps and multi-language note translation
• Primal: a cross-platform client with a built-in non-custodial Lightning wallet, custom feed algorithms, and caching servers for fast performance
• Amethyst: an Android client supporting NWC integration, multimedia posts, and community features
• Notedeck: a multi-column desktop and mobile client with local-network multicasting

Unlike traditional social media, users can switch between these clients freely while retaining their identity, followers, and content. The peer-to-peer nature of the protocol means no single client controls the network.

Long-Form Content

Kind 30023 events support long-form articles with full formatting, creating a decentralized blogging platform. Writers own their content cryptographically and can publish to any relay, avoiding the deplatforming risks of centralized publishing tools.

Marketplace Listings

Nostr events can represent product listings, with Lightning payments handling transactions directly between buyer and seller. This enables peer-to-peer commerce without marketplace fees or account requirements.

Identity and Authentication

Because Nostr provides a portable, cryptographic identity layer, it can serve as a login system for other applications. A user's Nostr keypair becomes a universal credential, reducing dependence on OAuth providers and centralized identity services. This aligns with decentralized identity principles already emerging in the Bitcoin ecosystem.

Nostr and Bitcoin Layer 2 Ecosystems

Nostr's integration with Lightning creates natural connections to Bitcoin Layer 2 infrastructure. Users who hold Lightning addresses can receive zaps from any Nostr client. Wallet infrastructure like NWC bridges Nostr social activity with Lightning payment rails, and protocols like Spark extend Bitcoin's reach with fast, low-cost transactions that complement the kind of micropayment flows Nostr enables.

As Layer 2 solutions mature, the combination of Nostr for identity and social coordination with Lightning and other off-chain protocols for payments creates a stack where users control both their communications and their money without relying on centralized intermediaries.

Risks and Considerations

Key Management

Nostr identities depend entirely on private key security. If a user loses their private key, they lose their identity permanently: there is no password reset, no account recovery, and no support team. If the key is compromised, an attacker can impersonate the user indefinitely. This mirrors the key management challenges in Bitcoin self-custody, and users should apply the same precautions (hardware storage, backups, passphrases).

Relay Reliability and Data Persistence

Because relays are independently operated, there is no guarantee that content will persist. A relay operator can shut down, purge old data, or refuse to store certain events. Users mitigate this by publishing to multiple relays, but there is no protocol-level guarantee of data availability. Important content can still disappear if every relay storing it goes offline.

Spam and Content Moderation

Nostr's permissionless nature means anyone can publish events to public relays. Without centralized moderation, spam and unwanted content are ongoing challenges. Solutions in development include paid relays (economic cost deters spam), relay-level filtering, web-of-trust scoring, and client-side muting. None of these fully solve the problem, and the tradeoff between openness and content quality remains an active area of experimentation.

Privacy Limitations

Nostr public keys are pseudonymous, not anonymous. All events signed by a key are publicly linkable, creating a complete activity history. Relays can log IP addresses. If a public key is ever linked to a real identity (for example, through NIP-05 verification or on-chain payment correlation), the entire history becomes attributable. Users seeking stronger privacy must manage separate keys and use network-level protections like Tor.

Protocol Fragmentation

As NIPs proliferate, not all clients and relays implement the same feature set. An event kind supported by one client may be invisible in another. This fragmentation can create inconsistent user experiences across the ecosystem, though the core protocol (NIP-01) remains simple enough that basic interoperability is maintained.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.