CraysNIP-07 Signers
NIP-07 is one of the small standards that changes the whole product experience. It lets a browser or extension expose a signing interface to a web app so the app can ask for signatures without receiving the private key itself.
The problem NIP-07 solves
Web apps are convenient because they open instantly. That convenience becomes dangerous when the app asks for a Nostr private key. A private key is not a recoverable platform password. It is the signing authority for the public identity. If a web app stores it badly, logs it, leaks it through a dependency or trains users to paste it everywhere, the account-level damage can follow the user across clients.
NIP-07 gives web clients a better pattern. A browser extension or compatible environment can expose window.nostr. The website asks that object for public-key access or a signed event. The signer decides whether the request is allowed. The website receives the signature or public result, not the raw private key. The standard is small, but the shift is large: signing becomes a permissioned boundary instead of a text box.
That is why NIP-07 belongs inside the Apps hub, not only inside the NIPs route. Readers encounter it as a product decision. A web client that supports NIP-07 can ask for signatures in a different way from a site that wants the key directly. A browser extension such as nos2x made the pattern visible early. Other signers and wallet-adjacent products extend the same idea into more polished or mobile-specific experiences.
What window.nostr changes
The interface exposed by NIP-07 is intentionally practical. A client can request the public key, ask the signer to sign an event and use helper methods for encryption-related flows depending on implementation. The exact product experience varies, but the mental model is stable: the app asks, the signer signs, and the private key stays on the signer side of the boundary.
That boundary does not magically make every app safe. A signer can still approve a malicious event if the user does not understand the request. A client can still ask for too much. A browser extension can still have its own bugs. A user can still import the same private key into risky places. But NIP-07 gives the ecosystem a place to build better warnings, permissions and habits. Without that boundary, the user has to trust every web app with the raw key.
This is also why copywriting matters. A good signer does not describe every request in opaque protocol terms. It helps the reader understand whether they are logging in, posting, reacting, encrypting, delegating or doing something unusual. The standard creates the technical hook; product design decides whether a normal person can use it safely.
nos2x and the early browser pattern
The nos2x repository is important because it made the browser-extension pattern concrete for early Nostr web apps. It gave websites a way to request Nostr signatures without asking the user to paste an nsec directly into the page. In a young ecosystem, that kind of tool becomes more than a convenience. It teaches both users and developers what a better login flow can look like.
The lesson from nos2x is not that one extension solves key custody forever. It is that the signing boundary belongs outside the web app whenever possible. The extension model lets multiple websites use one signer, and it lets a user change the web client without changing the core identity secret. That is the same portability story that makes Nostr interesting, translated into browser security.
Modern signers continue that path with more features, better UX and different platform assumptions. Some focus on desktop browsers. Some connect to mobile signers. Some bridge to NIP-46 remote signers. The product question remains the same: where does the private key live, and how much does the app get to touch?
Where NIP-46 enters the picture
NIP-46 takes the signing boundary further by letting a client communicate with a remote signer. The signer can live on another device, in a bunker-style service or in a more controlled environment. A browser extension can then become a bridge: the website speaks something like NIP-07 to the browser, while the browser relays signing requests to a NIP-46 signer.
Bunker46 is useful as a concrete example of that model. Its public materials emphasize keeping keys away from the browser and letting the remote signer produce signatures. The bunker46-extension project shows the bridge idea in code: a web app can use the familiar browser interface while the actual signing authority sits elsewhere.
This is powerful, but it adds complexity. Remote signing introduces connection setup, permissions, availability, pairing and recovery questions. For some readers, a local browser signer is simpler. For high-value identities or more careful operators, a remote signer may be worth the extra friction. The Apps hub keeps both paths visible so the reader does not mistake convenience for the only design.
How to judge a signer
A signer deserves more scrutiny than a normal client. It sits near the private key. Before trusting one, ask whether the project is open source, who maintains it, how it stores keys, what platforms it supports, whether it explains requests clearly and how it behaves when a website asks for unusual permissions. The answer may not be perfect, but the questions need to be visible.
On mobile, the signer story changes. Android has enabled app-to-app signing patterns through projects such as Amber, while iOS has different platform limits. Desktop browsers have their own extension model. Hardware-backed or OS-keychain approaches, such as nostr-keyx experiments, point toward a future where keys can be harder to extract than a plain browser secret. Each path has tradeoffs.
A signer also needs to be boring in the right places. It should not turn every signature into a panic moment, but it should interrupt actions that carry real risk. It should make routine posting easy and unusual signing legible. The best signer UX is calm at the exact point where a careless click can matter.
What web apps should learn from it
A web app that supports NIP-07 is making a reader-facing promise: you do not have to hand this page your private key just to participate. That promise should be reflected in onboarding copy, buttons, warnings and fallback flows. If the fallback is still “paste nsec here,” the page needs to say clearly what that means and why a signer is safer.
Web clients should also avoid treating NIP-07 as a magic login badge. The signer tells the app which public key is available and can sign events, but the app still needs to explain relays, content, zaps, encryption and permissions. Signing is the door handle, not the whole house.
For readers, the practical rule is simple: prefer clients that support a signer, learn what the signer prompt means and treat private-key copy-paste as an exception. NIP-07 is not the whole security story, but it is one of the clearest places where Nostr turns protocol design into everyday safety.
Sources worth opening
- NIP-07 - Browser signer interface exposed as window.nostr.
- NIP-46 - Remote signing flow for clients and bunker-style signers.
- fiatjaf/nos2x - Early browser extension pattern for web signing without handing keys to sites.
- Bunker46 - Remote signer example built around the NIP-46 model.
- bunker46-extension - Browser bridge connecting NIP-07 websites to a NIP-46 signer.
- nostr-keyx - Signer experiment using operating-system keychain and hardware-backed ideas.
- Amber - Android signer app for keeping signing outside ordinary clients.
