NIP-07 (Browser Signer)

NIP-07 defines a standard window.nostr object that a browser extension injects into web pages, giving websites a controlled way to request Nostr operations without ever receiving the user's private key. It is the Nostr equivalent of a hardware-wallet boundary applied to web apps: the page asks, the extension signs. For anyone using Nostr through a browser, NIP-07 is the single most important piece of key hygiene available.

The interface

The required methods are getPublicKey(), which returns the user's public key as hex, and signEvent(event), which takes an event object and returns it populated with id, pubkey, and sig. Optional methods include getRelays() and encryption helpers under nip04 (deprecated) and nip44. Extensions are advised to inject at document_end so that window.nostr is available before page scripts run, avoiding race conditions where a client loads faster than the signer. From the web client's perspective the flow is simple: detect window.nostr, request the public key to establish who the user is, then submit each event for signing as the user acts.

Why it matters for key security

Without NIP-07, a web client would need your secret key pasted into the page, exposing it to any script or compromise on that site — and a Nostr key, unlike a password, cannot be rotated without abandoning your identity. NIP-07 inverts that: the signing key stays inside the extension's isolated context, and the page only ever receives signed results. This keeps a single key usable across many Nostr apps while keeping each app at arm's length from the secret material. The architecture will be familiar to Bitcoiners: it is the same separation a hardware wallet enforces between your private key and the computer composing a transaction — the untrusted environment prepares the payload, the trusted boundary signs it.

Limits of the model

NIP-07 narrows the attack surface; it does not eliminate it. A malicious or compromised site can still ask the extension to sign events, so the quality of the signer's approval UX matters: good extensions show what is being signed and let users approve per-event, per-app, or with scoped permissions. The key also still lives on the same machine as the browser, so a compromised operating system remains fatal. Users wanting stronger separation move the key off the device entirely with a remote signer, keeping even the extension from holding secret material. And because the interface is per-browser, mobile platforms use different patterns (signer apps invoked via intents) to achieve the same boundary.

Where it fits in a sovereign stack

The pattern NIP-07 encodes — keys in the most trusted compartment, everything else treated as hostile — is the same discipline that runs through self-custody generally. Identity on Nostr is the keypair; there is no password reset and no support desk. Treating the key accordingly from day one, by never letting a web page touch it, is what NIP-07 makes practical.

Getting set up is deliberately unexciting: install a reputable signer extension, generate a keypair inside it (or import one), and back the secret up offline exactly as you would a seed phrase — because it plays the same role. From then on, any NIP-07-aware client you visit simply asks the extension for your public key and requests signatures as you post. The habit to build is refusal: if a Nostr site ever asks you to paste your private key directly, that is not an inconvenience to work around but a disqualifying red flag, no matter what the site promises.

For remote-wallet control with the same trust-minimizing spirit, see Nostr Wallet Connect (NIP-47); for the encryption those optional helpers implement, see NIP-44; and for verifiable identity tied to that key see NIP-05. D-Central covers NIP-07 as part of self-custodied Nostr usage.