• Remote signing on Nostr (NIP-46) in plain words
  • How it works
  • Two ways to connect
  • Signers you can use
  • Why it matters
  • Limits to know
  • Quick checklist

§Remote signing on Nostr (NIP-46) in plain words

If you paste your nsec into every new client you try, each one of them can sign anything as you, forever. NIP-46 (“Nostr Connect”) fixes that: your key stays in one place (the signer, sometimes called a bunker), and clients ask it to sign over Nostr relays.

§How it works

1. The client and the signer agree on a relay and a temporary keypair for the session.
2. When the client wants to post, it sends an encrypted request (event kind 24133) to the signer through that relay: “please sign this event”.
3. The signer checks its permissions (or asks you), signs, and sends the signed event back the same way.
4. The client publishes it. Your nsec never left the signer.

Requests include get_public_key, sign_event, encrypt/decrypt (NIP-04 and NIP-44, so DMs work) and ping.

§Two ways to connect

• bunker:// URI (signer goes first): your signer shows a string like bunker://<signer-pubkey>?relay=wss://...&secret=.... You paste it into the client’s “login with bunker / remote signer” field.
• nostrconnect:// URI (client goes first): the client shows a QR code or link. You scan or open it in your signer and approve.

Treat both strings like a temporary password. Anyone holding a fresh bunker:// secret can request a session.

§Signers you can use

• Amber (Android): keeps the key on the phone. It supports NIP-46 and also NIP-55, which lets Android apps call it directly without relays.
• nsec.app and other web/self-hosted bunkers: hold the key and answer requests from any device.
• Browser extensions (nos2x, Alby and others, NIP-07) are a different method: they sign inside the browser, not over relays. Good on desktop; NIP-46 is what lets you log in on a device or web app without copying the key there.

§Why it matters

• Trying clients is safe. Revoke a client’s session in the signer instead of rotating your whole identity.
• Per-app permissions. Many signers let you allow “kind 1 notes” but ask before “kind 0 profile” or “kind 3 follow list” changes, so a buggy client can’t wipe your follows.
• Scheduling. Some schedulers use NIP-46 so they can sign at posting time. Others ask you to pre-sign the event now and hold it. Either way, you never hand over the nsec.

§Limits to know

• The signer has to be reachable. If the relay in the URI is down or your phone is asleep, signing stalls. Pick a reliable relay, or a signer that lists more than one.
• Every action is a round trip, so it can feel slower than a local key.
• The signer is now your single point of trust. Back up the nsec offline once, then keep it only in the signer.

§Quick checklist

• [ ] Key lives in one signer (Amber, a bunker, or an extension), not in every client
• [ ] Clients connected via bunker:// or nostrconnect://
• [ ] Sensitive kinds (0, 3, 10002) set to “ask me”
• [ ] Old sessions revoked when you drop a client
• [ ] Offline backup of the nsec exists

Questions? Reply and I’ll add answers here. Zaps keep these guides coming.