NIP-46: Nostr Remote Signing
The private key must not live in every app
NIP-46 is one of the most important user-safety NIPs because it changes where the secret key sits. Instead of pasting an nsec into every website, mobile app, desktop client or experiment, a user can keep the key in a dedicated signer. The client asks the signer to sign events. The signer can approve, deny, restrict and log those requests.
The official rationale is blunt: private keys needs to be exposed to as few systems as possible because every system adds attack surface. That is the core of remote signing. A client can be useful without being trusted with the user's identity secret.
NIP-46 is also where Nostr starts to look less like a hobby protocol and more like an account system with separable devices. A phone can be the signer. A server can be a bunker. A hardware device can sign. A browser app can ask without owning the key.
Bunker URLs, disposable client keys and JSON-RPC-ish requests
The NIP distinguishes three key roles: the client keypair used for the communication session, the remote-signer keypair used by the signer, and the user keypair that represents the actual Nostr account. That distinction was clarified in the file history because early versions blurred it.
Connections can begin with a bunker:// token from the remote signer or a nostrconnect:// token from the client. The messages use event kind 24133. Requests and responses are encrypted, p-tagged and shaped like a JSON-RPC conversation with methods such as connect, sign_event, get_public_key, ping, NIP-04 and NIP-44 encrypt/decrypt helpers, switch_relays and, as of June 2026, logout.
Permissions are not an afterthought. The client can request permissions in the connection token, and a signer can restrict what the client may do. That is what makes remote signing more than a relay tunnel. It becomes a policy boundary around identity.
A living security standard, not a frozen login trick
NIP-46 began visibly in February 2023 with Marco Argentieri's Nostr Connect work. fiatjaf rewrote the NIP later in 2023, and the file saw a major new version in February 2024. The history is unusually active because key management has remained one of Nostr's hardest product problems.
Several changes are worth calling out. The old npub#secret style was replaced with bunker://. NIP-44 calls were added and, in December 2024, NIP-46 abandoned NIP-04 entirely and moved to NIP-44. Nostr.Band's 2024 upgrade clarified nostrconnect metadata and removed older account-creation assumptions. In January 2026, switch_relays was added. In June 2026, hzrd149 added logout to end remote signer sessions.
This is the kind of source history you need to see. NIP-46 is not just sign this blob remotely. It is the place where Nostr is learning how to make identity usable without normalizing private-key paste culture.
Amber, bunkers and libraries show the real shape
Amber is the most visible everyday example: an Android signer that can hold the nsec and sign for other apps via NIP-46 remote signing or Android's on-device NIP-55 flow. OpenSats describes Amber as the app that holds your nsec so other clients do not have to, with per-app prompts when a new client wants to sign.
The bunker direction is the other branch. nsecBunker, Bunker46 and similar tools keep a key in a server or daemon and answer remote signing requests over relays. Rust-nostr has a nostr-connect crate with client and signer modules. Nostrify exposes an NConnectSigner for using a remote signer from TypeScript. These are not all the same security model, but they share the NIP-46 grammar.
The best product test is permission clarity. Can the user see which app is asking, what method it wants, which event kind it wants to sign, which relays are involved and how to revoke the session? Without that, NIP-46 can become a prettier way to lose control of the key.
Remote signing moves trust; it does not erase it
A remote signer can be safer than pasting a private key everywhere. It can also become a single, high-value target. A hosted bunker operator, a compromised phone, a malicious permission prompt or a poorly scoped session can still harm the user.
The UX risk is just as serious. If users approve every signing request because the prompt is vague, remote signing becomes security theater. Good NIP-46 software needs boring details: app name, origin, relay, method, event preview, permission duration and revoke controls.
Read NIP-46 in the wild
NIP-46 lets signing move away from the app that displays the feed. A remote signer can approve events for many clients without putting the private key into each one.
This is powerful account safety and a serious permission problem. Sessions, methods, relays, prompts, revocation and device trust all become part of the identity surface. Hide them, and you have rebuilt platform login with better cryptography.
What changes when you actually use it
For you, NIP-46: Nostr Remote Signing 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-44, NIP-05, NIP-89 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-46: Nostr Remote Signing 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 Changes, Rationale, Terminology, Overview, Initiating a connection, Direct connection initiated by remote-signer, Direct connection initiated by the client, Request Events kind: 24133. Inspect kind 24133, kind 4, kind 1, kind 31990, remote-signer-key, remote-signer-pubkey, user-pubkey, sign_event because these are the pieces most likely to surface as product behavior. Read it beside NIP-44, NIP-05, NIP-89 before treating it as isolated.
NIP-46: Nostr Remote Signing 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-46: Nostr Remote Signing 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-46: Nostr Remote Signing 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-46: Nostr Remote Signing 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-44, NIP-05, NIP-89 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-46: Nostr Remote Signing 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-46: Nostr Remote Signing 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-44, NIP-05, NIP-89 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-46: Nostr Remote Signing with the moment of authority: signing, naming, delegation, authentication, encryption or recovery. Then ask which key or service can act. The source terms kind 24133, kind 4, kind 1, kind 31990, remote-signer-key, remote-signer-pubkey 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: Amber GitHub repository, OpenSats Amber project page, nostr-connect crate, Nostrify Nostr Connect docs. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-46 source is the anchor for exact wording, and NIP-46 commit history shows how that wording moved over time. The strongest secondary clues here are Amber GitHub repository, OpenSats Amber project page, nostr-connect crate. 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-46: Nostr Remote Signing: first the human promise, then kind 24133, kind 4, kind 1, kind 31990, remote-signer-key, remote-signer-pubkey, then the implementation record, then the real-world failure case. That order keeps NIP-46 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
kind 24133,kind 4,kind 1,kind 31990,remote-signer-keyin the official file and check where the UI exposes the same concept. - Read NIP-44, NIP-05, NIP-89 as context before treating NIP-46 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-46: Nostr Remote Signing in that order: Official NIP-46 source for the current wording; NIP-46 commit history for the change record; Amber GitHub repository, OpenSats Amber project page, nostr-connect crate 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.
