What is Nostr?
Nostr is not one app, one company or one social network. It is a small open protocol where a public key is the identity, a private key signs actions, clients are replaceable windows and relays carry signed events.
Where the confusion starts
Nostr becomes confusing when people describe it with the wrong noun. If you call it a social network, a beginner looks for the one official app. If you call it a blockchain thing, they look for tokens, miners and a ledger. If you call it a Twitter alternative, they expect one timeline with one moderation policy and one company behind it. None of those frames gets the center of the idea right.
The simplest useful frame is this: Nostr is a public-key protocol for publishing and reading signed events through independent relays. Your identity is not an account inside a platform database. Your identity is a key pair. Your client is not the network. It is the app you use today. A relay is not a master server. It is one server that can accept, store and serve events. Other relays can do the same thing with different policies.
That sounds dry until you feel the consequence. If you can keep the same public identity while moving between clients, the app loses some of the power platforms usually have. If relays are replaceable, one server can refuse you without ending your whole presence. If events are signed, clients can check authorship instead of simply trusting a database row. Nostr is small because it tries to make those pieces portable.
The short definition
Nostr stands for Notes and Other Stuff Transmitted by Relays. The name is awkward, but it is unusually literal. A person creates an event. The event is signed with their private key. The client sends that event to one or more relays. Other clients ask relays for events matching certain filters. The protocol describes the messages that pass between clients and relays; it does not prescribe one app, one interface or one business model.
The original protocol repository says the idea is intentionally simple: people publish notes to multiple relays, followers connect to relays and fetch those notes, and public-key cryptography lets clients verify that the notes were really signed by the public key they follow. That is the core. Everything else in the ecosystem grows out of it: profiles, follow lists, replies, media, zaps, wallets, long-form writing, groups, marketplaces, search, moderation labels and many strange experiments.
This is why a good Nostr explanation begins with the separation between identity, application and storage. On a conventional platform, those usually arrive as one bundle. You open an account with the platform, post inside the platform, store the data on the platform, accept the platform client and live inside the platform graph. Nostr breaks that bundle apart. The break is powerful, but it also makes the first hour less familiar.
The four moving parts
The first moving part is the public key. This is the stable identifier people can follow, mention, verify and search for. It can be shown as a long hexadecimal string, but most users meet it as an npub, a friendlier format defined by NIP-19. An npub is not a username in the usual sense. It is a representation of a public key.
The second moving part is the private key. This is the signing secret. It proves that an event came from the holder of that key. It is closer to a root credential than a normal password, because there is no central help desk that can reset it. If a private key is lost, the identity can become unusable. If it is leaked, another person can sign as that identity. That single fact shapes almost every serious beginner warning.
The third moving part is the client. A client can be a mobile app, a web app, a desktop app, a command-line tool, a bot, a signer interface or a specialized product. Clients decide what the network feels like. They decide which relays to query, which events to render, what to hide, what to highlight, how to handle keys, how to show conversations and how to make discovery tolerable.
The fourth moving part is the relay. A relay speaks WebSocket with clients. It can receive events, answer subscriptions and apply its own storage and policy choices. Some relays are general public infrastructure. Some are paid. Some are community-specific. Some store a lot. Some store very little. Some are used for inboxes, groups, wallets or special workflows. The relay is important, but it is not the owner of your identity.
What an event really is
In Nostr, the basic data object is an event. A short text note is an event. A profile update is an event. A follow list is an event. A deletion request is an event. A reaction, repost, long-form article, file metadata record, wallet request or relay list can also be an event. The event has a kind number, a public key, a timestamp, tags, content, an id and a signature.
NIP-01 matters because it defines the basic event structure and the client-relay messages. It names the patterns a client uses to publish an event, request events and close a subscription. The client sends an EVENT message to publish. It sends a REQ message with filters to ask for events. It sends CLOSE when a subscription is no longer needed. Relay responses include events, end-of-stored-events notices, acknowledgements and notices.
For a reader, the important idea is not the JSON. It is the shift in trust. A relay can refuse, delay, omit or forget events. A client can render events poorly. But a properly signed event carries evidence of authorship with it. That does not solve every social problem. It does not prove that the human behind a key is good, honest or famous. It does mean the client can reject events that pretend to be from a public key without a valid signature.
What relays do and do not do
Relays are often described as servers, which is true but incomplete. They are not one giant database. They do not automatically synchronize with every other relay. They do not all store the same history. They do not all accept the same events. A relay can have policy, pricing, rate limits, spam controls, community rules, retention limits and operational failures.
That sounds weaker than a single platform database until you see the trade. A centralized platform can give you one search box, one moderation policy and one reliable mental model. It can also remove you, hide you, de-rank you or trap your graph. Nostr relays are messier. They require discovery, redundancy and client judgment. The upside is that no single relay is supposed to be the entire network.
The practical beginner lesson is simple: relay choice affects what you see, where your posts land and how easily others can find your events. In the first hour, you do not need to become a relay operator. You do need to know that the client is reading and writing through relays, and that a missing reply or profile is often a relay/discovery issue rather than proof that Nostr is broken.
What clients change
Clients carry the user experience. This is why Nostr can feel amazing in one app and baffling in another. The underlying protocol may be the same, but the product decisions are not. A client can prioritize public timelines, private messages, long-form writing, live streaming, photos, marketplaces, wallets, developer tools, group chats or relay administration.
A client also makes security decisions. Does it ask you to paste an nsec? Does it support a NIP-07 browser signer? Does it work with NIP-46 remote signing? Does it explain relay settings? Does it help you back up keys? Does it make zaps and wallet permissions visible? The beginner experience depends as much on these choices as on the protocol itself.
This is why the right first question is not which Nostr app is the official one. There is no official one. The better question is what you are trying to do: read public notes, publish, follow builders, write long posts, join communities, test wallets, use Nostr Login, run a relay or build software. Different clients make different paths easier.
Where NIPs fit
NIPs are Nostr Implementation Possibilities. The name matters because it is not a product checklist. The NIPs repository says the documents describe what may be implemented by Nostr-compatible relay and client software, and it warns that nothing forces every app to implement every NIP. A good app implements the parts relevant to its purpose.
For a beginner, only a few NIPs need to be visible early. NIP-01 is the foundation. NIP-05 gives human-readable DNS-based identifiers. NIP-07 lets browser extensions expose a signing interface to web apps. NIP-19 gives friendly bech32 formats such as npub and nsec. NIP-42 covers relay authentication. NIP-65 helps clients learn relay lists. NIP-57 covers Lightning zaps. NIP-47 covers Nostr Wallet Connect. NIP-17 and NIP-44 matter for modern private messaging.
The point is not to memorize numbers. The point is to know that Nostr grows by shared conventions. When a convention proves useful, clients and relays can adopt it. When it becomes stale or unsafe, the ecosystem can move away from it. This is less tidy than a platform API, but it is also why unrelated apps can understand each other.
What Nostr is not
Nostr is not a blockchain. Events are not mined into a global ledger. There is no native token required to publish a signed event. Bitcoin and Lightning are culturally and technically important in many Nostr products, especially zaps and wallet flows, but the protocol itself is not a coin.
Nostr is not ActivityPub with different branding. ActivityPub is a W3C federation protocol built around actors, inboxes, outboxes and server-to-server delivery. Mastodon-style accounts usually live under a server domain. Nostr begins from public keys and relays. Both aim at open social communication, but they put identity, storage and federation in different places.
Nostr is not Bluesky either. Bluesky uses the AT Protocol, with Personal Data Servers, relays, AppViews, DIDs and lexicons. That architecture makes different tradeoffs around hosting, indexing, user data repositories and application views. Nostr is smaller and rougher. It leans harder on portable keys, signed events and replaceable relays.
The honest version
The honest version is that Nostr is early, powerful and uneven. It is excellent at moving identity out of a single app database. It is good at letting clients compete over the same signed social data. It is promising for payments, publishing, login, portable profiles, event-driven apps and censorship-resistant communication. It is also still rough around discovery, spam, search, private data, media storage, onboarding and key recovery.
That does not make the idea weak. It makes the idea concrete. Nostr is not a magic experience layer. It is a protocol that gives builders a different set of primitives: keys, events, relays, clients and shared NIPs. The better the products become, the more ordinary those primitives can feel to readers.
So the answer to What is Nostr? is not a slogan. It is a mental model. If you remember one thing, remember this: your key is the identity, your client is the window, relays carry events and signatures let other clients verify who authored what. Once that clicks, the rest of the Nostr map becomes easier to read.
Why the definition has to stay small
A useful Nostr definition has to stay small because the ecosystem is already large. If the definition tries to include zaps, wallets, long-form notes, livestreams, private groups, marketplaces, badges, file storage, data vending machines and every client feature, a beginner loses the thread. Those things matter, but they are built on top of the smaller model.
The smaller model is what gives the rest of the map coherence. A zap is still an event pattern and a payment flow. A profile is still signed metadata. A relay list is still an event that helps clients find other events. A long-form article is still data signed by a key and found through relays. The surface changes, but the nouns keep repeating.
That repetition is the gift. Once a reader knows key, client, relay, event and NIP, every new product can be examined with the same questions. Which key signs? Which client renders? Which relays carry it? Which NIP describes it? What does the app hide from the user? What happens if one piece disappears?
The account is not the app
The strongest beginner habit is to stop saying "my account on this Nostr app" and start saying "my Nostr key used through this app." That language sounds pedantic until the first client switch. The public identity can remain while the interface changes. A profile can render in one app, a follow list in another and a wallet connection somewhere else.
This is also why bad onboarding can damage the whole perception of Nostr. If the first app makes the key feel like a password field, the user imports web2 instincts into a system where those instincts are risky. If the first app explains signers, relays and public keys without melodrama, the user gains a mental model they can carry to every other tool.
A mature Nostr ecosystem will not require every ordinary person to speak protocol. It will require products that respect the protocol enough to make the important boundaries visible: identity versus interface, signing versus storing, publishing versus discovering, payment permission versus social permission.
Why signed events change trust
Signed events do not make people truthful. They do not prove that a human is who they claim to be. They do not prevent a compromised key from posting nonsense. What they change is authorship verification. A client can check whether an event was signed by the key it claims to come from. That is a lower-level guarantee than social trust, and it is still valuable.
On a platform, the database and application usually mediate authorship. You trust the platform's account system. In Nostr, the signed event carries cryptographic evidence that can move between relays and clients. A relay can serve an event, but it cannot forge a valid signature for another key. A client can render an event, but it can also reject an invalid one.
That distinction becomes important for archives, mirrors, clients, backups and hostile infrastructure. A relay may be untrusted as a publisher of truth, but the event signature gives clients a way to verify the author field. This is the reason Nostr can tolerate dumb relays more easily than a system where storage and identity are fused.
Why the network still needs people
The protocol can verify signatures, but people still verify meaning. A public key becomes socially useful when others recognize it, follow it, cite it, zap it, mention it, add it to lists or connect it to a domain. A relay can carry events, but it does not decide which voices matter to a reader. A client can rank and filter, but it still depends on human signals.
This is why a Basics section has to connect protocol facts to the People, Apps, Relays, Wallets and NIPs shelves. Nostr is not only a technical format. It is an ecosystem of builders, operators, writers, funders, artists, educators and users making choices around a small set of primitives.
The clean definition gives the reader a map. The rest of the site gives that map life: who built what, which apps are usable, which relays matter, which standards shape product behavior, which privacy decisions are still sharp and which claims deserve skepticism.
How to read any Nostr product
Once the reader has the small model, every Nostr product can be read with the same practical questions. What identity does it use? Where does signing happen? Which event kinds does it create? Which relays does it publish to or read from? Which NIPs does it rely on? Which parts are local product behavior rather than protocol behavior?
That reading habit prevents two common mistakes. The first mistake is treating every Nostr app as if it were the protocol itself. The second is treating the protocol as if it guaranteed a finished product experience. A client can be beautiful and still make poor relay choices. A relay can be reliable and still have a narrow policy. A NIP can be precise and still need careful product design.
The same habit also makes the rest of this wiki easier to use. Apps are not only apps; they are opinions about signing, discovery, media, moderation and wallets. Relays are not only servers; they are policy, uptime, filtering and storage choices. Wallets are not only payment buttons; they are permission systems connected to social identity. NIPs are not only documents; they are agreements that become real when products implement them well.
What the protocol does not do
Nostr does not choose a client for the user. It does not guarantee that every relay stores every event forever. It does not provide account recovery by default. It does not decide which posts are important. It does not make private messages safe in every old client. It does not protect someone who pastes a valuable private key into the wrong place.
Those limits are not side notes. They are part of the architecture. The protocol keeps the base small so clients, signers, relays, wallets and communities can compete. That gives the ecosystem room to grow, but it also means readers need to know where responsibility moves. Some responsibility moves to products. Some moves to operators. Some moves to users.
A good Nostr product reduces that burden without pretending it disappeared. It gives safe defaults, explains dangerous actions at the right moment and makes recovery, backup, relay choice, signer choice and wallet permissions legible. The protocol is the base. The humane part comes from the people building on it.
The best one-sentence memory
If a beginner needs one sentence, use this one: Nostr is a way for users to sign social data with their own keys and move that data through many relays and clients instead of living inside one platform account.
That sentence is not complete, but it is strong enough to carry the first week. It tells the reader that keys matter. It tells them data is signed. It tells them relays and clients are different. It tells them the point is not merely a new feed. It also warns them that the user has more power and therefore more responsibility.
Everything else can be layered on top: NIP-05 names, NIP-07 signers, NIP-19 links, NIP-44 encryption, NIP-57 zaps, NIP-65 relay lists, NIP-89 app handlers, Nostr Wallet Connect, Blossom storage, moderated groups, long-form articles and relay discovery. The sentence remains the anchor when the map becomes crowded.
