Remote Signing (NIP-46 and Friends)

Why remote signing matters for Nostr

A Nostr identity is just a secp256k1 keypair (see Nostr). The nsec (private key) does everything: signs DMs, posts, zap requests, profile updates, FIPS routing announcements. Whoever has the nsec is the identity.

The early UX was disastrous: every Nostr client wanted the user to paste the nsec into a text field on first run. Web apps, mobile apps, browser tabs, all asking for the secret key. This violated every principle of key custody:

• A malicious or compromised client steals the key.
• The user has no idea how many clients hold their key.
• Revocation is impossible — Nostr identity is the key.
• Multi-device use means the key is in N places, each a separate compromise vector.

Remote signing fixes this. The signer holds the nsec; clients request signatures over the wire. The client never sees the key. This pattern aligns Nostr's UX with how modern wallets, password managers, and SSH agents work.

NIP-07 — browser extension signers

NIP-07 ("Window.nostr capability for web browsers") defines a browser API that web Nostr clients can call to request signatures from a browser extension. Spec: NIP-07: browser signing interface.

// Web client never touches the key directly:
const event = await window.nostr.signEvent({
    kind: 1,
    content: "hello world",
    tags: [],
    created_at: Math.floor(Date.now() / 1000),
});

The extension holds the key, prompts the user for confirmation (or auto-approves whitelisted origins), and returns the signed event.

Implementations

Threat model

• Key sits in the browser extension's storage (encrypted with a password, ideally).
• Web origin is checked; per-site approval prompts.
• Compromised browser or extension stack leaks the key.
• No hardware isolation. A determined attacker with browser access wins.

NIP-07 is the convenience tier: better than pasting nsec, worse than hardware. Acceptable for low-stakes identities (casual social posting, low-value zaps).

NIP-46 — Nostr Connect (the bunker pattern)

NIP-46 ("Nostr Connect / Remote Signing") is the protocol for remote signing over Nostr relays. Spec: NIP-46: remote signing.

The flow:

Client (e.g., a web app)             Bunker (signer service)
    │                                       │
    │  Pairing: user pastes bunker URI      │
    │  ─────────────────────────────────►   │
    │                                       │  (User on bunker
    │                                       │   side approves)
    │                                       │
    │  signEvent(unsigned_event) request    │
    │  ───── via Nostr relay (encrypted) ─► │
    │                                       │  (Bunker signs)
    │  signed_event response                │
    │  ◄──── via Nostr relay (encrypted) ── │
    │                                       │

Key properties:

• Transport is Nostr relays. Both sides connect to a shared relay; messages are encrypted (NIP-44 v2, which uses ChaCha20 and HMAC-SHA-256).
• Pairing: the user gets a bunker:// or nostrconnect:// URI from the bunker, pastes it into the client. The URI contains the bunker's signing pubkey and a connection secret.
• The client never sees the nsec. It only sends unsigned events to the bunker and gets signed events back.
• The bunker can enforce policy: rate limits, allowed event kinds, approval prompts before signing.

Bunker implementations

Self-hosted bunker in a TEE

A pattern increasingly discussed: run the bunker inside a TEE (Intel TDX, AMD SEV-SNP, AWS Nitro Enclaves) so the key is hardware-isolated. The bunker exposes signing via NIP-46; the TEE attests to its code so the user can verify the bunker isn't a malicious copy. See Overview - Confidential Computing.

This gives: - Hardware key isolation. - Remote signing UX from any client. - Verifiable bunker code (no rogue admin extracting the key).

It's the best-of-both-worlds option for users with serious operational threat models.

Threat model for NIP-46

• The bunker holds the key. Compromise of the bunker = compromise of the identity.
• The relay sees encrypted traffic. Choose relays you trust not to log metadata.
• Pairing leaks the bunker pubkey (which is the signing key in some implementations) — a privacy concern, not a security one.
• Replay attacks are mitigated by per-session keys and timestamp validation.
• A compromised client can request many signatures; bunker policy (rate limit, kind filter, approval prompts) is the defense.

Amber (Android) — the deep dive

Amber (Amber implementation) is the dominant Android signer. It's not just a NIP-46 client; it can also act as a system-wide intent target, so any Nostr client on Android can request a signature via Android's intent mechanism.

Architecture:

• Key stored on Android device, encrypted with a user-set password / biometric.
• Signing requests come in via Android intents (local IPC) or NIP-46 (relay-based).
• Each request prompts the user (or follows policy: auto-approve specific event kinds for whitelisted apps).
• Multi-account support; one Amber install can hold many nsecs.

For Android Nostr users, Amber is the de-facto standard. UX is comparable to a password manager.

iOS lacks an Amber equivalent (Apple's intent system is more locked-down); iOS users typically use NIP-46 to a web bunker or a desktop signer.

Hardware-wallet signing

The strongest custody option: the key never leaves a hardware wallet.

Coldcard

Coldcard’s documented message-signing interface must not be assumed to implement Nostr event signing. Check the exact firmware and event format before designing a hardware-signing workflow; Bitcoin signed-message support alone does not establish NIP-01 compatibility.

Foundation Passport

Passport added Nostr signing capabilities (2024-2025). Similar QR-based UX. Targets Bitcoin-Nostr users who want unified hardware key management.

Keystone

Keystone Pro added Nostr signing support. Air-gapped QR workflow.

Research: PSBT-like Nostr signing

A research direction: a "NSBT" (Nostr-equivalent of PSBT) format that lets multiple parties contribute to event construction (e.g., multisig FROST signing) and pass partially-signed events between hardware devices and software clients. As of early 2026, this is exploratory; no standard exists.

Comparison table

Threshold signing — Frostr / FROST-Nostr

A future-facing direction: FROST (Komlo & Goldberg, IACR 2020/852) threshold Schnorr signatures, applied to secp256k1 Nostr keys. The Frostr proposal (Frostr FROST implementation) and related drafts let t-of-n cosigners produce a Nostr signature without ever reconstructing the full nsec.

Use cases:

• Personal: split your key 2-of-3 across phone, laptop, hardware wallet. Lose one device, identity survives.
• Organizational: a Nostr account controlled by 3-of-5 board members.
• Custody-as-a-service: a user holds 1-of-3 shares; a custodian holds 2-of-3 but can't sign without the user.

This intersects with Threshold Signatures (forthcoming) and is relevant to Marmot Protocol group identity.

As of early 2026: tooling is alpha. Production-grade UX is at least 6-12 months out.

Marmot and remote signing

Marmot Protocol (MLS over Nostr) signs a lot: every group operation, every welcome, every commit. A user in 5 active Marmot groups might generate dozens of signatures per day. This makes:

• Hardware-wallet signing impractical for Marmot (too many prompts).
• NIP-07 / NIP-46 the right fit, with policy: auto-approve Marmot event kinds for the Marmot client.
• TEE bunkers especially attractive: hardware-isolated key + high-frequency signing without UX friction.

A typical recommendation: hardware wallet for high-stakes events (profile changes, account rotations, kind-0 metadata), NIP-46 or Amber for everything else. The signer's policy distinguishes between event kinds.

Threat models in practice

Trade-offs

Strengths of remote signing generally

• Removes the "every client holds your nsec" footgun.
• Makes high-stakes Nostr accounts viable (organizations, journalists, whistleblowers).
• Enables policy enforcement (rate limits, approval prompts, kind whitelists).
• Composable with hardware isolation (TEE, hardware wallets).
• NIP-46's relay-based transport works across NAT, firewalls, anywhere Nostr works.

Limitations

• More moving parts. A bunker is one more thing to operate or trust.
• Latency. Every signature is a round-trip via relay.
• Bunker compromise is identity compromise. Operational discipline matters.
• UX is still rough for non-technical users.
• iOS lacks an Amber equivalent.
• Hardware-wallet flow is too slow for active Nostr use.

Attack surface

Primary sources

• Nostr Implementation Possibilities registry
• NIP-07: browser signing interface
• NIP-46: remote signing
• NIP-44: versioned encryption
• FROST: Flexible Round-Optimized Schnorr Threshold Signatures
• Amber implementation
• nsecbunker implementation
• Alby browser extension
• nos2x browser signer
• Frostr implementation
• Coldcard firmware release history
• Coldcard message signing
• Frostr FROST implementation

Also in Devices and Operational Security