Key
In Nostr, the key is not a login detail hiding behind the app. It is the portable identity layer the app is allowed to use.
Why the key comes first
The first real Nostr lesson is uncomfortable because it removes a familiar safety net. On a normal platform, the account lives inside a company database. You prove access with an email address, a phone number, a password, an OAuth login or a recovery flow controlled by the platform. If something goes wrong, there is usually a reset button, a support form or at least a company that claims to know which account is yours.
Nostr begins from a different place. The stable identity is a public key. Actions are proven by signatures made with the matching private key. A client can make that feel simple, but the underlying model is not a platform account with a reset desk. That difference is the reason Nostr can give a user portability across clients, and it is also the reason careless onboarding can be dangerous.
This is why the key belongs at the front of Basics. It explains why switching apps is possible, why signers matter, why copy-pasting an nsec into a random website is risky, why a NIP-05 name is useful but not the same thing as the key, and why a lost key is not a normal forgotten password problem.
Public and private
A Nostr key pair has two sides. The public key is shareable. It is the identity other people can follow, mention, search for and verify. The private key is the secret that can sign events as that public key. Anyone who has the private key can publish as that identity. Anyone who only has the public key can verify signatures, but cannot sign as you.
This distinction sounds abstract until a client renders a profile. A profile metadata update is an event signed by a key. A note is an event signed by a key. A follow list is an event signed by a key. A relay list is an event signed by a key. The social graph becomes portable because those signed events can be read by different clients instead of being trapped inside one platform database.
The user-facing consequence is simple: the public key can travel in public, but the private key should not be casually handed to products. A good first setup teaches that distinction early. A bad setup blurs it and makes Nostr feel like a place where every app asks for the master secret.
npub and nsec
Most readers meet keys through bech32 strings defined in NIP-19. An npub is the readable form of a public key. An nsec is the readable form of a private key. They look similar enough that a beginner can confuse them, which is why the words around them matter. Public keys can be shared. Private keys should be guarded.
NIP-19 also defines other shareable Nostr pointers such as note, nevent, nprofile and naddr. These formats do not change the underlying identity model. They make protocol objects easier to copy, paste and recognize in apps. The useful habit is to ask what the prefix represents before treating a string as safe.
The clean mental model is this: npub points to who can be followed; nsec controls who can sign. That one sentence prevents many early mistakes.
Signing
Signing is what turns a piece of Nostr data into an authored event. The client creates an event structure, the private key signs it, and the signature lets other software check whether the event really belongs to the public key it claims. NIP-01 defines the event shape: id, public key, created-at time, kind, tags, content and signature.
A signature does not prove that a person is honest, famous, safe or right. It proves authorship at the key level. That is still a major change from a platform database row. A relay can carry an event, but it cannot forge a valid signature for another key. A client can display an event, but it can also reject one with an invalid signature.
The trust model therefore has two layers. Cryptography can verify the event came from the key. Humans, clients and communities still decide whether that key is worth trusting. That is why NIP-05 names, web-of-trust tools, lists, follow graphs and reputation signals matter without replacing the key itself.
Signers
A signer is a tool that holds or controls signing power so every web app does not need the private key directly. In browsers, NIP-07 describes a way for extensions to expose a signing interface to web pages. Remote signing approaches such as NIP-46 let a client request signatures from another device or service that holds the key.
This sounds like a technical detail, but it is central to humane onboarding. A user should be able to try multiple clients without pasting the master secret into each one. The signer pattern gives apps a narrower interface: ask to sign this event, ask for the public key, ask for encryption or decryption when relevant. The user can then reason about permission instead of scattering secrets.
Signers are not magic. They can be poorly built. They can ask confusing questions. They can still be compromised. But they move the ecosystem toward a better default: the client is a window, not the vault.
Names and proof
NIP-05 lets a public key be linked to a DNS-based identifier that looks like an email address, such as a name at a domain. This is useful because raw public keys are hard for humans to recognize. A domain-based name can help readers check whether a key is connected to a website, publication, company or person they already know.
But NIP-05 is not the identity itself. It is a claim anchored in DNS and served by a domain. Domains can expire, move, get compromised or change owners. A NIP-05 name can help with discovery and social verification, while the public key remains the cryptographic identity that signs events.
That distinction matters especially for brands, journalists, developers and high-value accounts. A nice name is useful. The key is still the thing followers actually follow.
Failure modes
The hard part of Nostr keys is not generating one. The hard part is living with one responsibly. If the private key is leaked, another person can sign as that identity. If it is lost without backup, the identity may be stuck. If a user pastes an nsec into many unknown clients, each client becomes a possible compromise point. If a user treats a NIP-05 name as the account itself, they may misunderstand what survives a move.
There are also social failure modes. A key can be controlled by a team, a bot, a company, a pseudonym or a person who changes context over time. Signatures verify the key, not the human story behind it. This is why good clients make identity signals visible without pretending that cryptography replaces judgment.
The safest beginner advice is calm and concrete: understand the difference between npub and nsec, prefer signers when available, back up intentionally, do not paste private keys into random sites, and remember that the app is not the account. That is the foundation the rest of Nostr builds on.
The next practical question is what a key looks like inside products. A polished client may hide most of the raw key material and show a profile name, avatar and NIP-05 identifier. That is good product design, but the reader should still know what sits underneath. The name can change. The avatar can change. The NIP-05 domain can change. The public key is the durable reference that signed the profile event and follow list.
That is why identity recovery is a delicate subject. A platform can reset a password because the platform controls the account database. A Nostr key does not come with universal social recovery. Some products may offer custodial accounts, delegated signing, backup files, seed phrases, hardware devices or social recovery experiments. Those can be useful, but they are product-level solutions layered on top of the key model, not properties of Nostr itself.
For a serious profile, the backup plan deserves more attention than the first post. A private key written in one place can be lost. A private key copied into cloud notes can be leaked. A screenshot can sync to places the user forgot. A password manager can be safer than a clipboard, but it still depends on the user's threat model. Hardware signers, remote signers and dedicated mobile signer apps move the risk boundary again. There is no single answer for everyone, but there should be a conscious answer.
Teams need an even clearer model. If a media brand, venue, project or company uses one Nostr identity, who can sign? Is the key held by one founder, a shared password manager, a signer service, a hardware device, a bot or a multisig-like workflow outside the Nostr base? What happens when a maintainer leaves? Who can rotate links, publish warnings and point followers to a new key if the old one is compromised? Those are governance questions disguised as technical setup.
Key rotation is still awkward because followers follow a public key, not a normal username. A compromised key can publish a warning, but an attacker with the same key can also publish confusing messages. A new key can ask people to follow it, but the social proof has to be rebuilt. NIP-05, websites, GitHub accounts, X profiles, podcasts and known peers can help carry trust across the move. They do not make rotation painless.
This is the honest cost of a portable identity. The user gains the ability to move across clients and relays without asking one platform for permission. In exchange, the key becomes important enough to deserve real operational care. Nostr is not asking every reader to become a security engineer, but it is asking products to stop pretending key custody is just another login field.
When opening any Nostr app, use the key as a test. Does the app show whether it wants a public key, an nsec, a signer connection or a remote signer? Does it explain what will be signed? Does it let the user read without signing when reading is enough? Does it make backup warnings concrete? Does it avoid scary language that teaches nothing and friendly language that hides too much?
A good Nostr key explanation should leave the reader with confidence, not panic. The private key is powerful, but it is understandable. The public key is strange at first, but it is the reason the social identity can outlive one client. Once those two ideas settle, Nostr's promise of portability stops sounding like a slogan and starts sounding like a design constraint.
There is a difference between using a key for a disposable experiment and using one for a life identity. A throwaway test key can be useful when someone is learning clients, zaps or relays. It lets the user click around without risking a public reputation. A serious key is different. It may accumulate follows, contacts, payment history, memberships, published writing, profile reputation and links from other websites. Once that happens, casual key handling becomes expensive.
That difference should shape onboarding. A new reader can start with a fresh key, learn the model, then decide whether to keep it. A builder can support temporary identities for exploration while making the upgrade path clear. A publication, venue or business should not create a permanent public identity in a random browser tab and then discover later that nobody knows where the private key lives. The key decision is boring only until it becomes urgent.
Public-key identity also changes how impersonation is handled. On a platform, a username, blue check, domain, profile picture and follower count may all be controlled inside one account system. On Nostr, a familiar display name is not enough. Many keys can call themselves the same name. The stronger signals are signatures from the key, a stable npub, NIP-05 verification, links from known websites, references from known people and consistent activity over time.
This is why clients should make the public key inspectable without making the interface ugly. A reader should be able to copy the npub, check the NIP-05 name, see when a profile was first noticed, inspect relays and notice whether the app is showing a lookalike. That does not mean every feed card needs raw hex. It means identity details should be one click away when trust matters.
Keys also sit behind Nostr login. A product that says "log in with Nostr" may mean several things: read-only public-key entry, NIP-07 signing, NIP-46 remote signing, a local key inside the app, a custodial account or a temporary key. The phrase is friendly, but the implementation decides the risk. A reader should ask what the site can sign, what it can read, whether the key leaves the signer and how the session can be revoked.
Private messages make the key story more sensitive. Encryption standards can protect message content, but the key still anchors identity and permissions. Old direct-message patterns, modern encrypted payloads, gift-wrapped events and client storage all create different privacy shapes. The key is part of that privacy story because whoever controls it may be able to decrypt, sign or authorize actions depending on the flow.
For payments, the same caution applies. A Nostr key is not a Bitcoin wallet key by default, but zaps, Nostr Wallet Connect, Cashu wallets and app-specific payment flows can connect identity to value. A social key may request wallet actions or publish payment-related events. The user should keep the distinction clear: the Nostr key signs social protocol events; wallet software controls funds or spending permissions. Good apps make that boundary visible.
The mature version of Nostr will probably make key management feel ordinary. Signers will improve. Recovery products will improve. Hardware and mobile boundaries will become friendlier. But the underlying lesson will remain: a portable identity needs a portable trust habit. Know what is public, know what signs, know where the secret lives and do not let a beautiful client turn the root key back into an invisible password field.
A key also gives profile metadata a different meaning. A name, picture, banner, about text, website and lightning address are not fields inside one company's account table. They are data published by the key and interpreted by clients. That is why a profile can look current in one client and stale in another. The client has to find the latest relevant metadata event, decide which relay to trust for it and render it well.
Follow lists work the same way. A user's social graph can be represented by signed events rather than a private platform database. That makes movement between clients possible, but it also means clients have to find and interpret those events. If a follow list does not show up, the cause may be relay discovery, stale cache, client support or an old event. The key makes the graph portable; the product still has to do the work.
Public keys also help archives. If a note, article or profile event is copied from one relay to another, the signature still travels with it. A later client can verify that the event belongs to the key. That is a quiet archival strength. It does not solve context, deletion, moderation or storage, but it gives copied data a way to retain authorship evidence.
At the same time, the key can become a burden when social meaning accumulates. A public key that has been cited by others, listed by communities and used for payments becomes hard to abandon. That gives Nostr identities continuity, but it also makes compromise painful. The more a key matters, the more careful the signer, backup and operational plan should become.
The best reader habit is to separate four questions. Which public key is this? Who or what do I believe controls it? Which app is asking to act for it? Which signer or secret will approve that action? Those questions sound slow at first. After a few days, they become the mental rhythm that makes Nostr less foggy.
When a guide says "own your identity," this is the concrete version. Ownership is not a motivational slogan. It means controlling the signing authority, knowing how the public key is represented, understanding where names and metadata come from and choosing products that do not quietly take more power than the action requires.
That is enough to make the first Nostr week safer: follow the public key, guard the private key, prefer a signer when the client supports it, and slow down whenever an app asks for authority it has not clearly earned.
