Keys, Names and Signers: The Identity Layer That Makes Nostr Different
A deep guide to public keys, NIP-05 names, npub and nsec formats, browser signers, Android signers, remote signing, delegated signing and signed HTTP auth.
Why this part of the NIP map matters
Nostr identity is easy to oversell and easy to misunderstand. You do not own a platform account in the old sense. You control a keypair. The public key is the name the network can recognize. The private key is the power to sign as that identity. Everything else is product design around that fact: readable names, profile metadata, signer prompts, remote signing sessions, encrypted backups, app permissions and social proof.
That key-based identity is the reason people get excited about Nostr. It is also the reason the first week can be risky. A private key is not a password you can ask a company to reset. A browser prompt is not safe just because it is not asking for the key directly. A readable name is not the identity itself. A remote signer improves one trust boundary while creating another. A signed HTTP request can be elegant and still dangerous if replay windows or URLs are handled poorly.
The useful identity path is therefore practical: how your key becomes visible, how apps ask for authority, how you can move between clients, and where the old platform habit of logging in still tries to sneak back in.
The important question is personal: who can sign as you? If you can answer that cleanly for every client, signer, wallet, website and service, you understand more about Nostr than many people who can quote NIP numbers from memory.
The mental model
The public key is the durable identity, but public keys are not humane. NIP-05, NIP-19 and profile metadata are all attempts to make a cryptographic identity usable without hiding what it really is.
The private key is authority. Anything that handles it directly can become the owner of your identity in practice, even if the protocol says you are in control. That is why signer standards matter.
A signer is not a magic shield. It is a room where you can inspect a request before your key signs. If the room is confusing, rushed or silent, the safety layer becomes theatre.
Remote signing changes the trust model again. It can keep keys away from websites and devices, but it also asks you to understand sessions, permissions, relays and revocation.
Identity standards become real when you can switch clients without losing recognition, while still knowing exactly which software can sign for you.
Read this topic with one hand on the protocol and one hand on the product. The protocol tells you the shared format. The product tells you what a person actually sees, approves, loses, recovers or can take elsewhere. Both are necessary. One without the other creates either abstract standards talk or a pretty interface with no durable proof underneath.
Use the source links as proof, not as decoration. A useful NIP explanation gives you the mental model first, then sends you to the official markdown when exact fields, status notes, examples or implementation details matter.
The identity question is not where you log in
The platform habit says identity starts with an account form. Nostr starts earlier. It asks who can produce a valid signature for a public key. That sounds abstract until you use more than one client. In a normal platform, your account is a row in the company's database. In Nostr, the durable part is the public key. A client can help you use it, a signer can protect it, a NIP-05 name can make it recognizable, and a profile event can make it human, but none of those pieces should be confused with the key itself.
That distinction changes the safety routine. A website that asks for your private key is not asking for a password. It is asking for the ability to become you everywhere that key is recognized. A browser extension, native signer, Android signer or remote signer improves the situation only when it keeps the secret away from the app and makes the request legible. The prompt is the trust moment. If it says only that an app wants to sign something, you still need to know what kind of event, which relay path, which permission and whether the action can be repeated.
Readable identity adds another layer. A NIP-05 address can help people find and verify a public key through a domain, but it does not replace the key. That is powerful because it gives communities, companies and public figures a familiar naming surface. It is risky because people may treat the domain as the account. If the domain changes hands, if the well-known file is wrong, or if a client displays the name without enough context, the social signal can outrun the cryptographic one.
The bech32 formats from NIP-19 solve a different problem. They turn raw hex keys and event references into forms you can paste, recognize and move between apps: npub, nsec, note, nevent, nprofile and naddr. That is usability, not decoration. If a product hides these forms completely, you may never learn how to move. If it exposes them without warning, you may paste a private key into the wrong place. Good products show the public forms as handles and links, while treating the private form as hazardous material.
Signer design is where self-custody becomes usable
A signer is a social contract between your key and the apps around it. NIP-07 gave web apps a browser-signing pattern. Android signer flows move the same idea into mobile operating systems. NIP-46 remote signing extends the room again, allowing one device or service to hold the key while another app requests signatures. The common promise is attractive: use many clients without letting every client touch the private key. The hard part is making the permission understandable before anything is signed.
The worst signer experience trains you to click approve. That recreates the platform pattern in a new shape. The better experience explains the event kind, the destination, the visible effect and the duration of the permission. Signing a short note is not the same as signing a relay list, updating profile metadata, approving a wallet connection, authenticating to a relay or publishing encrypted content. A mature signer does not treat all signatures as the same kind of consent.
Delegation, session keys and remote signing also raise recovery questions. If your phone is lost, which key still has authority? If a remote signer is offline, can you still post? If a session is compromised, how do you revoke it? If the signer vendor disappears, can you export safely? These questions are not pessimism. They are the practical cost of owning identity. Nostr gives you exit, but exit has to be rehearsed before you need it.
For public figures and organizations, signing hygiene becomes reputation hygiene. A leaked key can impersonate a founder, publish misleading statements, change relay lists or poison trust signals. NIP-05 and social verification may help a community notice, but the protocol cannot undo a valid signature after the fact. That is why backups, hardware devices, remote signer policy, organizational signing practice and clear incident notes become part of the identity story.
The NIP pages in this topic
Mapping Nostr keys to DNS-based internet identifiers
NIP-05 gives a public key a readable internet identifier, but it does not turn identity back into a platform login. The key remains the identity; the domain is evidence.
Ask who can sign, which identifier is being displayed, whether the private key is exposed and how you can leave the client without losing identity. Watch "names", <name>, pubkey, "relays", npub, /.well-known/nostr.json?name=<local-part> because these are the terms that usually surface as product behavior. Nearby standards: NIP-19.
window.nostr capability for web browsers
NIP-07 is the browser-signer bridge. It lets a web app request signatures without taking the private key, but the prompt still has to make the signed event legible.
Ask who can sign, which identifier is being displayed, whether the private key is exposed and how you can leave the client without losing identity. Watch id, pubkey, sig because these are the terms that usually surface as product behavior. Nearby standards: NIP-04, NIP-44.
bech32-encoded entities
NIP-19 makes Nostr pointers human-shareable through npub, nsec, note, nevent, nprofile and naddr forms.
Ask who can sign, which identifier is being displayed, whether the private key is exposed and how you can leave the client without losing identity. Watch npub, nsec, nprofile, nevent, naddr, nrelay because these are the terms that usually surface as product behavior. Nearby standards: NIP-01, NIP-05.
Nostr Remote Signing
NIP-46 moves signing away from the app surface and into a remote signer, which changes the trust boundary around every sensitive click.
Ask who can sign, which identifier is being displayed, whether the private key is exposed and how you can leave the client without losing identity. Watch kind 24133, kind 4, kind 1, kind 31990, remote-signer-key, remote-signer-pubkey because these are the terms that usually surface as product behavior. Nearby standards: NIP-44, NIP-05, NIP-89.
HTTP Auth
NIP-98 signs HTTP requests with Nostr keys. It can replace a normal web login for a request, but replay and URL matching must be exact.
Ask who can sign, which identifier is being displayed, whether the private key is exposed and how you can leave the client without losing identity. Watch kind 27235, kind 27235, content, method, kind, created_at because these are the terms that usually surface as product behavior.
Follow List
A special event with kind 3, meaning "follow list" is defined as having a list of p tags, one for each of the followed/known profiles one is following.
Ask who can sign, which identifier is being displayed, whether the private key is exposed and how you can leave the client without losing identity. Watch ["p", <32-bytes hex key>, <main relay URL>, <petname>], .content because these are the terms that usually surface as product behavior.
OpenTimestamps Attestations for Events
OpenTimestamps Attestations for Events -------------------------------------- The official README carries a caution here, so use it as history or compatibility context before you build something new.
Ask who can sign, which identifier is being displayed, whether the private key is exposed and how you can leave the client without losing identity. Watch kind 1040, kind:1040, content because these are the terms that usually surface as product behavior.
Basic key derivation from mnemonic seed phrase
Basic key derivation from mnemonic seed phrase ---------------------------------------------- The official README carries a caution here, so use it as history or compatibility context before you build something new.
Ask who can sign, which identifier is being displayed, whether the private key is exposed and how you can leave the client without losing identity. Watch m/44'/1237'/<account>'/0/0, account because these are the terms that usually surface as product behavior.
Delegated Event Signing
This NIP defines how events can be delegated so that they can be signed by other keypairs. The official README carries a caution here, so use it as history or compatibility context before you build something new.
Ask who can sign, which identifier is being displayed, whether the private key is exposed and how you can leave the client without losing identity. Watch kind 2, relay, kind, =${KIND_NUMBER}, created_at, kind=1&created_at<1675721813 because these are the terms that usually surface as product behavior.
Linking Profiles to Other Platforms
Linking Profiles to Other Platforms -----------------------------------
Ask who can sign, which identifier is being displayed, whether the private key is exposed and how you can leave the client without losing identity. Watch platform:identity, <identity>, <instance>/@<username>, <username>@<instance>, <ref>/<id>, <id> because these are the terms that usually surface as product behavior.
Private Key Encryption (ncryptsec
Private Key Encryption (ncryptsec) ------------------------------------
Ask who can sign, which identifier is being displayed, whether the private key is exposed and how you can leave the client without losing identity.
Android Signer Application
This NIP describes a method for 2-way communication between an Android signer and any Nostr client running on the same device, so that the client never needs to handle the user's private key. The signer is an Android application; the client may be another Android application or a web page.
Ask who can sign, which identifier is being displayed, whether the private key is exposed and how you can leave the client without losing identity. Watch kind 1, com.example.signer, nostrsigner, AndroidManifest.xml, user-pubkey, package name because these are the terms that usually surface as product behavior. Nearby standards: NIP-46.
Gift Wrap
This NIP defines a protocol for encapsulating any nostr event. This makes it possible to obscure most metadata for a given event, perform collaborative signing, and more.
Ask who can sign, which identifier is being displayed, whether the private key is exposed and how you can leave the client without losing identity. Watch kind 13, kind 1059, kind 21059, kind 1, relay, content because these are the terms that usually surface as product behavior. Nearby standards: NIP-44, NIP-13, NIP-17, NIP-42, NIP-09.
Deep reading: where the details become product behavior
NIP-05: Mapping Nostr keys to DNS-based internet identifiers
NIP-05 gives a public key a readable internet identifier, but it does not turn identity back into a platform login. The key remains the identity; the domain is evidence.
Ask who can sign, which identifier is being displayed, whether the private key is exposed and how you can leave the client without losing identity. In the official file, slow down around "names", <name>, pubkey, "relays", npub, /.well-known/nostr.json?name=<local-part>. It also touches NIP-19, so do not read it as an island.
The source structure points you toward Example, Finding users from their NIP-05 identifier, Notes, Identification, not verification. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.
NIP-07: window.nostr capability for web browsers
NIP-07 is the browser-signer bridge. It lets a web app request signatures without taking the private key, but the prompt still has to make the signed event legible.
Ask who can sign, which identifier is being displayed, whether the private key is exposed and how you can leave the client without losing identity. In the official file, slow down around id, pubkey, sig. It also touches NIP-04, NIP-44, so do not read it as an island.
The source structure points you toward Recommendation to Extension Authors, Implementation. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.
NIP-19: bech32-encoded entities
NIP-19 makes Nostr pointers human-shareable through npub, nsec, note, nevent, nprofile and naddr forms.
Ask who can sign, which identifier is being displayed, whether the private key is exposed and how you can leave the client without losing identity. In the official file, slow down around npub, nsec, nprofile, nevent, naddr, nrelay, relay, author. It also touches NIP-01, NIP-05, so do not read it as an island.
The source structure points you toward Bare keys and ids, Shareable identifiers with extra metadata, Examples, Notes. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.
NIP-46: Nostr Remote Signing
NIP-46 moves signing away from the app surface and into a remote signer, which changes the trust boundary around every sensitive click.
Ask who can sign, which identifier is being displayed, whether the private key is exposed and how you can leave the client without losing identity. In the official file, slow down around kind 24133, kind 4, kind 1, kind 31990, remote-signer-key, remote-signer-pubkey, user-pubkey, sign_event. It also touches NIP-44, NIP-05, NIP-89, so do not read it as an island.
The source structure points you toward Changes, Rationale, Terminology, Overview. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.
NIP-98: HTTP Auth
NIP-98 signs HTTP requests with Nostr keys. It can replace a normal web login for a request, but replay and URL matching must be exact.
Ask who can sign, which identifier is being displayed, whether the private key is exposed and how you can leave the client without losing identity. In the official file, slow down around kind 27235, kind 27235, content, method, kind, created_at, payload, ["payload", "<sha256-hex>"].
The source structure points you toward Nostr event, Request Flow, Reference Implementations. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.
NIP-02: Follow List
A special event with kind 3, meaning "follow list" is defined as having a list of p tags, one for each of the followed/known profiles one is following.
Ask who can sign, which identifier is being displayed, whether the private key is exposed and how you can leave the client without losing identity. In the official file, slow down around ["p", <32-bytes hex key>, <main relay URL>, <petname>], .content.
The source structure points you toward Uses, Follow list backup, Profile discovery and context augmentation, Relay sharing. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.
NIP-03: OpenTimestamps Attestations for Events
OpenTimestamps Attestations for Events --------------------------------------
Ask who can sign, which identifier is being displayed, whether the private key is exposed and how you can leave the client without losing identity. In the official file, slow down around kind 1040, kind:1040, content.
The source structure points you toward Example OpenTimestamps proof verification flow. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.
NIP-06: Basic key derivation from mnemonic seed phrase
Basic key derivation from mnemonic seed phrase ----------------------------------------------
Ask who can sign, which identifier is being displayed, whether the private key is exposed and how you can leave the client without losing identity. In the official file, slow down around m/44'/1237'/<account>'/0/0, account.
The source structure points you toward Test vectors. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.
NIP-26: Delegated Event Signing
This NIP defines how events can be delegated so that they can be signed by other keypairs.
Ask who can sign, which identifier is being displayed, whether the private key is exposed and how you can leave the client without losing identity. In the official file, slow down around kind 2, relay, kind, =${KIND_NUMBER}, created_at, kind=1&created_at<1675721813, kind=0&kind=1&created_at>1675721813, kind=1&created_at>1674777689&created_at<1675721813.
The source structure points you toward the event fields, examples and edge cases. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.
NIP-39: Linking Profiles to Other Platforms
Linking Profiles to Other Platforms -----------------------------------
Ask who can sign, which identifier is being displayed, whether the private key is exposed and how you can leave the client without losing identity. In the official file, slow down around platform:identity, <identity>, <instance>/@<username>, <username>@<instance>, <ref>/<id>, <id>.
The source structure points you toward Abstract, Claim types, github, twitter. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.
NIP-49: Private Key Encryption (ncryptsec
Private Key Encryption (ncryptsec) ------------------------------------
Ask who can sign, which identifier is being displayed, whether the private key is exposed and how you can leave the client without losing identity.
The source structure points you toward Password Unicode Normalization, Encryption, Decryption, On Key Derivation. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.
NIP-55: Android Signer Application
This NIP describes a method for 2-way communication between an Android signer and any Nostr client running on the same device, so that the client never needs to handle the user's private key. The signer is an Android application; the client may be another Android application or a web page.
Ask who can sign, which identifier is being displayed, whether the private key is exposed and how you can leave the client without losing identity. In the official file, slow down around kind 1, com.example.signer, nostrsigner, AndroidManifest.xml, user-pubkey, package name, sign_event, kind. It also touches NIP-46, so do not read it as an island.
The source structure points you toward Rationale, Terminology, Communication methods, Setup. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.
NIP-59: Gift Wrap
This NIP defines a protocol for encapsulating any nostr event. This makes it possible to obscure most metadata for a given event, perform collaborative signing, and more.
Ask who can sign, which identifier is being displayed, whether the private key is exposed and how you can leave the client without losing identity. In the official file, slow down around kind 13, kind 1059, kind 21059, kind 1, relay, content, kind:13, kind:1059. It also touches NIP-44, NIP-13, NIP-17, NIP-42, NIP-09, NIP-62, so do not read it as an island.
The source structure points you toward Overview, Protocol Description, 1. The Rumor Event Kind, 2. The Seal Event Kind. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.
What to check before you trust a product claim
Start with the most concrete promise. Does the feature claim portable identity, encrypted messaging, relay discovery, zaps, wallet permissions, long-form publishing, moderation, search or application data? Name the promise before you open the source. Otherwise every NIP starts to look like background reading.
Open the official markdown next. Look for required fields, event kinds, tags, relay messages, status warnings and examples. Do not stop at the title. Many Nostr mistakes happen because a product advertises a NIP number while ignoring the boring edge case that actually protects the user.
Then test another implementation. If the event, payment, list, message, article, badge or relay behavior only works inside one product, the feature may still be useful, but it is not yet a strong portability claim. The second implementation is where the standard stops being a slogan.
Finally, check the risk class. Keys, private messages, money, storage, moderation and identity need more caution than a playful app format. A product can be young and promising, but the page should not ask you to trust it like a mature standard when the source trail is thin.
How this area usually fails
The first failure is overclaiming. A client says it supports a NIP, but it supports only the easiest happy path. That may be enough for a demo and not enough for real use.
The second failure is hidden custody. The app feels convenient because it quietly holds the key, routes the wallet, chooses relays or stores media in a way that makes leaving hard. Nostr is most interesting when those boundaries are visible.
The third failure is stale source material. A guide, blog post or old archive page may describe a version of the ecosystem that changed. The official repository and active implementations matter because Nostr standards are living documents.
The fourth failure is social flattening. Reports, badges, zaps, follows, labels and community events are not neutral numbers. They are signed social signals. You need to know who produced them, who displays them and what the product does with them.
The fifth failure is pretending the protocol solves product judgment. A NIP can define a format. It cannot force a client to explain it well, moderate fairly, store files forever or make a wallet prompt humane. Good pages keep that distinction clear.
Where to go next
The common thread is that a NIP is not a magic wand. It gives independent software a shared object, permission, message, tag, filter or social signal. The product still has to explain what it does with that shared shape.
If you are new to the topic, read the cards first and open only the NIP that matches your immediate question. If you are building, read the official markdown and test against more than one implementation. If you are evaluating a product, ask which parts travel with your key and which parts stay inside the product.
That is the difference between a useful NIP atlas and a numbered archive. The archive tells you that a document exists. The Wissenslexikon tells you why the document changes the way Nostr feels in your hands.
When a NIP touches keys, money, private messages, moderation or storage, slow down. Those are not decorative protocol topics. They decide who can sign, who can pay, who can read, who can hide, who can recover and who can leave.
The best Nostr product writing stays close to those consequences. It does not bury you in acronym soup, and it does not pretend every standard is equally mature. It tells you what you can do next, what you should verify, and where trust enters the room.
Direct sources
Use these sources to verify the text, not as decoration. The official repository is the canonical source; mirrors, guides and project pages help you see how the standard is explained or implemented elsewhere.