NIP-07: window.nostr capability for web browsers
The web needed a way to sign without swallowing keys
NIP-07 is one of the standards that changed Nostr from a protocol experiment into something usable on the web. Before browser signers, a web client had an ugly choice: ask the user to paste a private key into the site, or avoid full account functionality. Neither route was good enough for a public social protocol.
The NIP defines a small browser capability called window.nostr. A website checks whether that object exists. If it does, the site can ask the signer for the user's public key and ask it to sign an event. The private key stays with the extension or browser-side signer. The web app receives the signed event, not the raw secret.
That boundary is why NIP-07 matters. It does not make every web app trustworthy. It changes the failure mode. A malicious site still can ask the user to sign a bad event, but it no longer needs the user's private key to do damage. The quality of the prompts, permissions and signer UI becomes the real security surface.
A tiny API with a large trust surface
The required API is intentionally small: getPublicKey() returns the user's public key in hex, and signEvent(event) takes an unsigned event object and returns it with id, pubkey and sig. That is enough for a web app to post, update metadata, publish lists or perform many other signed actions.
The optional API tells the history of Nostr encryption. NIP-04 encrypt and decrypt helpers remain listed as deprecated because older direct-message flows used them. NIP-44 encrypt and decrypt helpers are the modern optional path. The file also contains a practical extension-author recommendation: load scripts at document_end so clients can detect window.nostr on page load.
What the NIP does not define is equally important. It does not define a full permission model, account switching, multiple signer selection, a universal prompt design or a generic arbitrary-message signing method. GitHub issues around multiple extensions and generic signing show that the minimal API solved the urgent web-login problem while leaving room for later debates.
The bridge kept absorbing the real web
The visible NIP-07 file came over with the May 2022 migration. It grew because web clients and signer authors kept finding everyday edges. In 2023, contributors clarified what unsigned event objects look like and discussed whether window.nostr could support multiple extensions or arbitrary string signing. In December 2023, NIP-44 support landed, then moved through a brief revision period as Paul Miller's encryption work settled.
In 2024, the spec added the document_end loading recommendation after extension authors ran into page-load timing. In 2025, Greenart7c3 removed get_relays, narrowing the interface to the signing and encryption functions that still fit the standard's role.
The result is a compact but heavily used standard. NIP-07 is not glamorous protocol theory. It is the handshake behind a huge part of web Nostr: click login, approve signature, publish event, keep the private key out of the site.
From nos2x to remote signers
fiatjaf's nos2x is the classic implementation reference: a Nostr signer extension for web apps that exposes window.nostr so users do not hand their keys to every site. Alby made the browser-extension route familiar to many Bitcoin and Nostr users. Nostore, nostr-keyx and related signers explored different storage and platform choices.
The interesting evolution is the bridge to remote signing. The Remote NIP-07 Chrome extension describes itself as a NIP-07 to NIP-46 bridge: a NIP-07-only website can call window.nostr, while the user's approval happens through Amber and NIP-46-style remote signing. That shows NIP-07 becoming a compatibility surface, not only a local-extension pattern.
Libraries have also treated NIP-07 as a signer abstraction. Projects such as nostr-signer-connector expose a NIP-07 extension signer beside NIP-46 remote signer flows. For developers, that is the practical lesson: NIP-07 is one signing transport among several, but it remains the common denominator for browser clients.
A signer protects the key, not the user's judgment
The obvious risk is approval fatigue. If a website can request signatures and the signer shows vague prompts, a user may approve actions they do not understand. A private key held by an extension is safer than a pasted key, but a signed event is still a real action.
The second risk is ecosystem fragmentation. Some sites assume one extension, some signers add nonstandard methods, and users may install more than one tool. The core NIP keeps the minimum stable. Product quality depends on how clearly the signer and client explain the deal at the moment of signing.
Read NIP-07 in the wild
NIP-07 is the browser signer bridge. A web client can ask for a public key, a signature or encryption help without taking custody of the private key. That is one of the standards that made Nostr usable on the open web without making every website a key vault.
The UX is the security boundary. If the signer prompt does not make the event, permission and destination legible, the separation becomes theater. The website may not hold the key, but it can still trick you into approving something you did not understand.
What changes when you actually use it
For you, NIP-07: window.nostr capability for web browsers is felt when identity stops being a username and becomes authority. A client, signer, name, proof or auth event may look like account plumbing, but it decides who can publish, approve, connect, recover or be recognized. Read NIP-04, NIP-44 beside it so you can tell the difference between a convenient identity surface and the key material that actually controls the account.
What changes for builders and operators
For builders, NIP-07: window.nostr capability for web browsers means making authority visible before action. A signer prompt, name proof, delegation, encrypted key, external identity or HTTP auth event needs plain language around scope, expiry, destination and recovery. If a person has to guess what they are authorizing, the protocol has already lost the trust battle.
What the official file makes concrete
The official file is organized around Recommendation to Extension Authors, Implementation. Inspect draft, id, pubkey, sig because these are the pieces most likely to surface as product behavior. Read it beside NIP-04, NIP-44 before treating it as isolated.
NIP-07: window.nostr capability for web browsers is an authority path, not decoration. A name, key, signer, delegation or auth event decides who can act as you.
Where it breaks
The failure mode in NIP-07: window.nostr capability for web browsers is authority drift. A name resolves to an old key, a signer approves too broadly, an auth event gets replayed, a delegation lasts too long or a private key backup gives false comfort. The product has to keep control boundaries visible after onboarding, not only during setup.
Where this appears outside the markdown
In the ecosystem, NIP-07: window.nostr capability for web browsers usually appears at the doorway: account setup, profile recognition, signer approval, cross-platform proof, remote signing, HTTP auth or recovery. That doorway needs unusually clear language because identity mistakes are sticky. Once a key, signer or proof is trusted in the wrong place, every later feature inherits the confusion.
The nearby-standard trap
The nearby-standard trap in NIP-07: window.nostr capability for web browsers is confusing recognition with control. A name, signer, URI, encrypted key, delegation or auth signature may all sit near identity, but they answer different questions. Read NIP-04, NIP-44 and ask one thing each time: who can act, who can verify, and what can be revoked?
Language that keeps the feature honest
Good product copy for NIP-07: window.nostr capability for web browsers names the authority. It says whether you are sharing a public key, approving a signature, trusting a domain, exporting an encrypted secret, delegating power or authenticating to a service. Small labels matter because identity mistakes do not feel small after they happen.
What this page does not promise
NIP-07: window.nostr capability for web browsers does not make identity effortless or risk-free. It can help keys, names, signers, delegation or authentication become portable, but it cannot decide who you trust, how you back up secrets or whether a domain, app or signer deserves authority. Read NIP-04, NIP-44 as a control map before handing any interface the power to sign, verify or speak for you.
Read it as a field test
Start NIP-07: window.nostr capability for web browsers with the moment of authority: signing, naming, delegation, authentication, encryption or recovery. Then ask which key or service can act. The source terms draft, id, pubkey, sig are useful because they turn vague identity language into concrete control points. Without that, a friendly login screen can hide the most important security decision.
Where the standard earns trust
The source links give you places to test the interpretation in public: fiatjaf/nos2x, Remote NIP-07, nostr-keyx, Issue #353: multiple extensions. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-07 source is the anchor for exact wording, and NIP-07 commit history shows how that wording moved over time. The strongest secondary clues here are fiatjaf/nos2x, Remote NIP-07, nostr-keyx. Treat this evidence chain as part of the article, not as footnotes. A NIP page becomes useful when you can move from claim to source to working behavior without guessing.
Keep the chain visible for NIP-07: window.nostr capability for web browsers: first the human promise, then draft, id, pubkey, sig, then the implementation record, then the real-world failure case. That order keeps NIP-07 useful without turning it into marketing copy or protocol trivia.
Three questions to carry forward
- Who gains authority when this NIP is used: your key, a signer, a domain, a delegated key, a wallet or a web service?
- Can you revoke, rotate, back up or inspect that authority before something goes wrong?
- Does the interface separate public recognition from private signing power in language you can act on?
What to verify before you rely on it
- Find
draft,id,pubkey,sigin the official file and check where the UI exposes the same concept. - Read NIP-04, NIP-44 as context before treating NIP-07 as a complete product story.
- Open at least one implementation, mirror, pull request or library source from the source links before trusting that the idea is mature.
- Test the unhappy path: missing relays, stale metadata, invalid signatures, blocked events, expired state, revoked permissions or unavailable media.
- Write the user-facing copy in plain language. If a standard changes authority, privacy, money, moderation or recovery, say that before the click.
Direct sources
Use these sources for NIP-07: window.nostr capability for web browsers in that order: Official NIP-07 source for the current wording; NIP-07 commit history for the change record; fiatjaf/nos2x, Remote NIP-07, nostr-keyx for public context. The article gives you the consequence in plain language, but the source trail is where exact fields, status notes, unresolved debates and implementation proof stay checkable.
