Why a hardware signer for Nostr?

Fri, 15 May 2026 00:00:00 GMT

A Nostr account is just a keypair. Whoever holds the secret key can speak as you, forever, with no recovery path. The interesting question is therefore not “is Nostr secure?” — it is where does my key live, and what does it take to use it?

Soft signers leak the key into too many places

When the key lives in a browser extension or a copy-pasted nsec, the answer is “everywhere”:

inside every page the extension touches (NIP-07 reads),
inside every relay-side bridge that asks for a signature (NIP-46 client),
inside every backup file you forgot you made,
inside whatever clipboard manager auto-archived the nsec you typed once.

Each of those places is a different attack surface, and most of them sign without showing you what they are signing. A compromise of any one of them is a permanent account takeover.

Hardware signers move the secret behind a boundary

A hardware signer changes the model from “the key is everywhere a program can read it” to “the key is inside a device, and to use it something physical has to happen”. nSealr makes that boundary explicit through five solutions:

stateless QR vaults (Raspberry/Pi, ESP32) — secret only in RAM for the current session, no network at all, every signing decision happens on a trusted display through a physical button;
USB/NIP-46 signer — daily-use connected device with a display, reviewing every request before signing;
smartcard — persistent secret in a card, where the external reviewer acknowledges what is being signed before the APDU goes out;
custom hardware wallet — research line for purpose-built persistent-secret hardware.

What that actually buys you

A hardware boundary is not magic. It does not eliminate trust, it relocates it. The wins are concrete:

The host can lie, the device cannot be silently bypassed. A compromised companion or client can show you a fake event template, but the device renders its own review screen bound to the exact bytes it will sign through <code>approval_digest</code>. Lying to the screen would also corrupt the signature.
No automatic signing. Every <code>sign_event</code> requires a physical approval gesture, distinct from navigation, connection, or request receipt.
No accidental key extraction. The signer exposes <code>sign_event</code>, not <code>export_key</code>. The host never sees the secret.

What it does not yet buy you

This is pre-production research. <code>signing_disabled</code> is the default on every prototype firmware until camera, display, button, provisioning, and secure-boot gates pass independently. See the trust boundaries and the per-solution maturity in docs/signers.

A hardware signer is not safer because the box is shiny. It is safer because the trust boundary is documented, reviewable, and the same across implementations through shared contract_ids in <code>nSealr/specs</code>.

That is the whole point.

approval_digest: binding what you reviewed to what you sign

Thu, 14 May 2026 00:00:00 GMT

A trusted display is necessary but not sufficient. If the firmware can display screen A and sign payload B, the display is worth nothing. nSealr closes that gap with one specific contract: <code>approval_digest</code>.

The contract

approval_digest is a deterministic hash over the exact canonical material the user reviewed: signer pubkey, event kind, created_at, the full unmodified content, the complete tag list (including detail pages for long fields), the request id, and the review context.

The local approval action — pressing a physical button, completing an on-card acknowledgement — is bound to that digest. The signer refuses to emit a signature whose underlying serialization does not reproduce the same digest. Any drift between “what was shown” and “what gets signed” fails closed.

# companion, when verifying a signed response:
$ nsealr verify --request req.json --response resp.json
✓ event id matches BIP-340 signature
✓ approval_digest matches reviewed material

If the second line fails, the response is rejected even if the BIP-340 signature is mathematically valid. No display, no signature.

What it specifically prevents

Host-side template swap. A compromised client cannot show you benign metadata then sneak a different kind or different tags into the bytes the device signs — the digest would not match.
Unicode look-alikes inside content. Long content goes through the review-detail-page contract; the digest covers the same canonical bytes the user sees, with explicit Unicode fallback for codepoints the display cannot render.
Replay across contexts. The digest includes the request id and review context, so an approval gesture for request A cannot authorize signing request B.

Why it lives in the shared specs and not in each firmware

Every signer solution that claims trusted review uses the same approval-digest-v0 contract from nSealr/specs. Raspberry/Pi QR vault, ESP32 QR vault, ESP32 USB/NIP-46 signer, and (for displayful hardware) the custom wallet line — they share the contract, so swapping the hardware does not silently downgrade the safety story.

Display-less solutions are an exception: a smartcard cannot bind a review it cannot show. The smartcard line therefore depends on the external-review-acknowledgement-v0 contract instead — an explicit external reviewer takes responsibility for binding what was reviewed to the APDU that gets sent.

Status today

The approval_digest contract is implemented on:

Raspberry/Pi stateless QR vault,
ESP32 stateless QR vault (host-core review flow),
ESP32 USB/NIP-46 signer (disabled-signing development firmware).

It is partial on smartcard (acknowledgement plumbing under development) and planned on the custom hardware-wallet line. See the feature matrix per solution for the exact target/current status.

The point of writing this down: when someone asks “what does the hardware actually guarantee?” the answer is not “we promise” — the answer is a contract_id you can read, vectors you can run, and a digest the device refuses to lie about.

nSealr Blog