- nix devShell uses nixos-25.05's prisma-engines 6.7.0 (has
libquery_engine.node) — the 7.x problem is the system/unstable channel
only, not the flake's devShell (corrects an earlier overstatement; #30
closed as invalid).
- start.js migrate-on-boot is a no-op on nix but IS the migration path on
docker (image ENTRYPOINT) — don't assume it's dead everywhere (#31).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Captures the deploy hazard found during #27 rollout (cfaun): the
nsecbunkerd<->LNbits pairing is split across both systems, so a full
nsecbunker.db wipe orphans LNbits's signer_config and forces an
identity-changing re-provision. Documents the targeted
'DELETE FROM SigningCondition' procedure, the keys-live-in-json fact,
and the migrate-on-boot no-op (#31).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
PR #27 review finding #3: step 3a queried SigningCondition method='*'
and the docstring attributed it to rejectAllRequestsFromKey — but that
function writes method=null (never '*') and has zero callers, so the
'reject all' branch could never match. Subject-level reject is already
KeyUser.revokedAt (step 2, via the revoke_user admin command).
Drop the dead step-3a branch and the orphaned rejectAllRequestsFromKey
so the code matches reality. Per-(method,kind) denies (step 3, written
by add_signing_condition) are unaffected.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Move the lifecycle predicate into lib/acl/lifecycle.ts (re-exported from
the ACL module) so it can be unit-tested without a database. Adds Node
built-in test-runner coverage for the boundary conditions that define
the fix: past expiry -> dead, expiry == now -> dead (exclusive), revoke
beats a future expiry, and liveWhere kept in lockstep with grantIsLive.
Runner is node:test via ts-node (no new dependency; pnpm add is blocked
by the nix-built node_modules hoist pattern). 'npm test' -> 7 passing.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The bug (#24): applyToken photocopied a token's policy rules into
SigningCondition rows at redeem; checkIfPubkeyAllowed matched those rows
(step 3) and short-circuited before the live Token join (step 4), so an
expired or revoked token kept signing forever — the copy carried no
lifecycle. Same cause re-shipped by upstream Signet (see docs survey).
Option D fix:
- grantIsLive(grant, now): the single 'valid right now?' predicate
(revokedAt null AND not past expiresAt), used identically at redeem
(Backend.validateToken) and sign (checkIfPubkeyAllowed). Redeem and
sign can no longer disagree.
- Backend.applyToken records ONLY the KeyUser<-Token binding; it no
longer materializes SigningCondition rows. Token policy is evaluated
live every request.
- checkIfPubkeyAllowed step 4 filters tokens through liveWhere(now)
(revoke + expiry) and grants connect off a live bound token; the
manual-override layer (step 3) now honors SigningCondition
expiresAt/revokedAt too (denials beat grants).
Closes the materialization-drift family: a new lifecycle rule is one
more predicate, never a forgotten photocopy. Token-revoke sibling
(spirekeeper#22) falls out of the same seam. Usage caps deferred (no
durable signing log exists yet to count) — follow-up.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Additive, non-breaking schema prep for the Option D live-evaluation ACL:
- Request gains keyUserId (FK) + @@index([keyUserId, method]) so token
usage caps can be derived live by COUNTing allowed Requests, replacing
the never-enforced mutable PolicyRule.currentUsageCount (derive-don't-count,
per lnbits/nostr_bunker prior art).
- SigningCondition gains createdAt/expiresAt/revokedAt so the manual-override
layer carries its own lifecycle and runs through the same grantIsLive(now)
predicate as token grants (D1: two typed sources, one shared rule).
No behavior change yet; the ACL hot path and applyToken de-materialization
follow in subsequent commits.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Surveys Signet, Amber, FROSTR, promenade, NDK/rust-nostr/nak against
actual source; records the decision to keep our fork and treat Signet
as a parts donor (NIP-46 wire boundary keeps the signer substitutable).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
`Backend.start()` calls `this.ndk.subscribe(filter, opts)` to listen for
NIP-46 events targeted at each unlocked key's pubkey (kind:24133 with
`#p=[localUser.pubkey]`). Pre-fix this subscription opts didn't pin a
relay set, so NDK 3.x's outbox routing kicked in: it looked up the
`localUser.pubkey`'s NIP-65 relay list (kind:10002) to decide where to
send the REQ. Newly-provisioned bunker keys have no kind:10002 published
yet, so NDK's subscription manager queued the REQ waiting for a relay
list that would never arrive — the subscription never landed on the
wire.
The user-visible symptom: every NIP-46 RPC from lnbits to a freshly-
provisioned key (`connect`, `get_public_key`, `sign_event`, the
`nip04_*` / `nip44_*` family) was published into the relay, the relay
tried to route, found no subscribed peer matching `["p", new_key_pubkey]`,
and emitted "Filter didn't match". The lnbits-side RPC then timed out
at 15s, breaking eager merchant provisioning (aiolabs/lnbits#46) and
satmachineadmin's per-cassette `nip44_decrypt` polling.
Reproduced + diagnosed by patching the lnbits `nostrrelay` extension's
`_handle_request` to log incoming REQ filters: only the admin
subscription (`{kinds:[24133,24134], #p:[bunker_admin_pubkey]}` from
`AdminInterface.connect()`) appeared on the wire. The per-key Backend
filters from `Backend.start()` did not.
Fix: pass `relayUrls: this.ndk.explicitRelayUrls` in the subscription
opts. `relayUrls` was added in NDK 2.13.0 as the supported way to bypass
outbox routing per subscription; the relay set built from these URLs
matches what the rest of the daemon uses (admin RPC channel + every
per-key Backend channel), so events flow through the same connection
the admin interface already established.
Verified on the regtest dev stack with bunker enabled, fresh signup
provisioning a new key + immediately publishing a kind:30017 stall via
NIP-46 sign_event:
POST /auth/register → HTTP 200 in 1.1s
stalls.event_id = 8a2eb20b929… (populated by bunker signature)
relay sees: nostr event: [30017, <new-key-pubkey>, '{...store...}']
Pre-fix this same flow timed out at `NsecBunkerTimeoutError: no NIP-46
response for 'sign_event' within 15.0s`.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
NDK 3.x's per-relay connectivity machine gives up after ~3 fast-fail
(ECONNREFUSED) cycles. Three sub-second failures look identical, so
`isFlapping()` (std-dev < 1s) returns true and the relay transitions
to FLAPPING; NDKPool's `handleFlapping` then reschedules with doubling
backoff (5s → 10s → 20s → 40s → 80s …). For nsecbunkerd, "disconnected
for 80+s after every lnbits restart" is the failure mode users hit on
the regtest dev stack: bunker container boots before lnbits's
nostrrelay extension is accepting WebSockets → ECONNREFUSED storm →
NDK flagged FLAPPING → bunker stays silently deaf until manual restart.
Symptom is particularly hostile because:
- `relay:connect` fires optimistically; the immediate ECONNREFUSED
follow-up doesn't propagate to user-facing logs.
- `NSEC_BUNKER_DISABLE_WATCHDOG=1` (the dev-stack default) skips the
exit-and-restart safety net.
- Manual `docker compose restart nsecbunker` is the only recovery.
Fix: attach a small supervisor (`attachIndefiniteReconnect`) to both
NDK instances (daemon's backend NDK in run.ts, AdminInterface's admin
NDK in admin/index.ts). On `relay:disconnect` or `flapping`, schedule
a manual `relay.connect()` with a SHORT capped delay (1s → 2s → 4s →
8s → 10s, capped at 10s instead of NDK's unbounded doubling). Successful
connect resets the attempt counter so a future disconnect storm starts
fresh.
Coexists cleanly with the relay-connection watchdog (admin/index.ts:500):
- Brief disconnects (e.g. lnbits restart): supervisor recovers within
seconds, watchdog never fires.
- Persistent disconnects (relay truly down): supervisor keeps trying
every ≤10s; if it can't recover within 60s, watchdog still exits and
the process supervisor restarts the bunker. So the watchdog becomes
a long-tail safety net; this supervisor handles the common case.
Operators with `NSEC_BUNKER_DISABLE_WATCHDOG=1` set as a workaround for
this bug can re-enable the watchdog once this lands.
Trade-off: we may hammer a permanently-down relay every 10s. Acceptable
because the bunker's primary relay is typically on the same host or LAN
(loopback or docker-internal); TCP RSTs are cheap. Public-relay setups
can layer external supervision on top.
Verified on regtest dev stack (cold-boot race): bunker logs
🔁 admin: scheduling reconnect to ws://lnbits:5001/nostrrelay/test/ in 1000ms (attempt 1, overriding NDK give-up)
🔁 backend: scheduling reconnect to ws://lnbits:5001/nostrrelay/test/ in 1000ms (attempt 1, overriding NDK give-up)
on each disconnect, where pre-fix the bunker stayed silently deaf.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Required to keep the nix package buildable: nixpkgs unstable no longer
ships prisma-engines 5.x — the unsuffixed `prisma-engines` attr now
aliases 7.x (no libquery_engine.node), and the only versioned attrs are
`prisma-engines_6` (6.19.3) and `prisma-engines_7`. Bump both
`@prisma/client` and `prisma` to ^6.19.0 so the client matches the only
engine we can pin to.
Also:
- package.nix takes `prisma-engines_6` directly. flake.nix passes
`pkgs.prisma-engines_6 or pkgs.prisma-engines` so the package still
builds on nixos-25.05 (where prisma-engines is 6.7.0 unsuffixed).
- Drop PRISMA_INTROSPECTION_ENGINE_BINARY — prisma 6 collapsed the
introspection engine into schema-engine, the binary no longer ships.
Schema is unchanged so existing fresh installs migrate identically.
Existing dev instances with a prisma_5-tracked _prisma_migrations table
will need a one-time `prisma migrate resolve` step on first boot under
the new client; deploy targets are all fresh installs.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
NDK 2.8.1 → 3.0.3 bump (041f431) regenerated pnpm-lock.yaml at
lockfile v9, which pnpm_8 refuses to read. Switch the derivation to
pnpm_9 and regen the pnpmDeps hash to match the v9 lockfile.
The package.json/pnpm-lock realignment that `patchNdk` used to fix is
no longer needed — the same bump also pinned NDK as `"3.0.3"` in
package.json, so manifest + lockfile already agree. Drop the
substitute (kept as a no-op shim for the next time a bump diverges
them) instead of carrying a substituteStream that errors out under
--replace-fail because the source string no longer exists.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The first cut of `maybeAutounlock` enumerated `prisma.key` based on
the design issue's pseudocode. Empirically that's the wrong source:
the Prisma `Key` table is only populated by the NIP-05
`create_account` path, which stores keys *plain-at-rest* in
`nsecbunker.json` (no encryption involved). The `create_new_key`
flow that lnbits's `RemoteBunkerSigner` uses provisions encrypted
`{iv, data}` blobs directly into the JSON `keys` map without
touching the Prisma table at all.
Result of the v1 enumeration on regtest:
🔓 autounlock: enabled (source=NSEC_BUNKER_AUTOUNLOCK_PASSPHRASE),
unlocked 0/0 keys in 0ms
…despite 67 encrypted blobs sitting in nsecbunker.json. The Prisma
table was empty because none of the regtest keys came from
`create_account`. Greg's key would have been a no-op even with the
autounlock env set; the manual `unlock_key` admin RPC would still
have been required.
Fix: enumerate `this.config.allKeys` (the in-memory snapshot of
`nsecbunker.json`'s `keys` map, populated at daemon-fork time per
`src/commands/start.ts:144`) filtered to entries with the `iv`+`data`
shape. That's the canonical "what's encrypted at rest" set —
exactly the rows for which manual `unlock_key` was previously
required per restart.
Plain-key entries (`{key: ...}` from `create_account`) are skipped
here for log clarity — they were already loaded by `startKeys`'
second pass and live in `activeKeys`; `unlockKey`'s post-#16
idempotency guard would no-op them anyway, but emitting "unlocked"
log lines for keys that didn't need unlocking is noise.
Updates `docs/AUTOUNLOCK.md` accordingly so the description matches
the implementation.
Refs aiolabs/nsecbunkerd#16.
Adds opt-in autounlock to the daemon's boot sequence. Closes the
"O(N) manual unlock_key RPC per bunker restart" paper-cut without
breaking the secure-by-default posture: deployments that want every
restart to gate crypto capability on a human action keep that
property by leaving both env vars unset.
Configuration — two mutually exclusive env vars:
NSEC_BUNKER_AUTOUNLOCK_PASSPHRASE literal passphrase
NSEC_BUNKER_AUTOUNLOCK_PASSPHRASE_FILE path (newline-trimmed)
Both set → fail loud at boot. Neither set → no-op (default,
behavior unchanged from pre-#16). Var names follow the bunker's
existing NSEC_BUNKER_* convention (see NSEC_BUNKER_DEBUG_TRANSPORT,
NSEC_BUNKER_DISABLE_WATCHDOG); the design issue spec'd NSECBUNKER_*
but aligning with the existing prefix matters more for operator
muscle-memory than matching the issue text verbatim.
Implementation:
- `Daemon.maybeAutounlock()` wedged at the tail of `startKeys()`.
Inherits the relay-subscription lifecycle (EOSE-awaited per #9)
that the existing per-key startKey calls established, so there's
no "client sees key locked" race window.
- Enumeration via `prisma.key.findMany({ where: { deletedAt: null } })`
— Key table is the canonical source of truth for what keys exist
on the bunker; respects soft-delete.
- Per-key call to the existing `unlockKey(keyName, passphrase)`,
which is idempotent post-#16 — encrypted-at-rest keys get unlocked
on first call; rows already loaded via the unencrypted-config
passes above are no-ops.
- Sequential loop with continue-on-error. One bad row (corrupted
blob, key encrypted under a historical passphrase, etc.) doesn't
block the rest of the fleet. Per-key INFO/WARN/ERROR + one
summary line.
- File-source error (missing path, permission denied) is fatal at
boot — same severity as a misconfig.
Observability output:
🔓 autounlock: unlocked <keyName> (success)
⚠️ autounlock: unlockKey returned false for <keyName> (...) (soft fail)
❌ autounlock: <keyName> failed: <message> (throw)
🔓 autounlock: enabled (source=<env>), unlocked N/M keys in <Xms> (summary)
Single-passphrase invariant: every `create_new_key(name, passphrase)`
in our usage today uses the same passphrase
(LNBITS_NSEC_BUNKER_KEYSTORE_PASSPHRASE on the lnbits side), so one
autounlock passphrase covers every encrypted key. Per-key passphrase
support is a separate feature (out of scope — see #16 "out of scope"
section + docs/AUTOUNLOCK.md "What's not in scope").
`docs/AUTOUNLOCK.md` ships alongside: usage, the security trade
spelled out by deployment shape, observability hooks, what's
deliberately not in scope. Required-reading link before any operator
flips the env var on for a production-shaped deployment.
Refs aiolabs/nsecbunkerd#16. Builds on idempotent unlockKey from the
previous commit on this branch.
`unlockKey(keyName, passphrase)` previously had no short-circuit on
re-entry — calling it against an already-unlocked key would happily
run through the full path:
1. decryptNsec (cheap, same result)
2. overwrite this.activeKeys[keyName] with the same nsec
3. call startKey(keyName, nsec) → spawn a SECOND Backend instance
Step 3 is the actual hazard. Each Backend opens its own NIP-46 kind-
24133 subscription with the relay, scoped to the key's pubkey. Two
Backends → duplicate subscription → wire events delivered twice and
each handler races to publish its response. Response amplification +
ordering hazards downstream, plus a slow leak of NDK subscription
state every time unlock fires.
This bug was latent under the manual-unlock posture today (admins
rarely re-issue unlock_key for the same name in one session) but
becomes load-bearing for #16's autounlock loop, which is designed
to run alongside the existing startKeys() loops and may legitimately
encounter a key that was already loaded via the unencrypted-config
path. Belt-and-suspenders lnbits-side scripts + future periodic
"re-unlock sweeps for paranoia" can also fire this.
Fix: short-circuit on `this.activeKeys[keyName]` already set. Return
true so callers can rely on "after this call returns, the key is
unlocked and ready" regardless of whether work was done. Doesn't
break the manual flow (still unlocks first-time), doesn't change
the failure path (corrupt blob / wrong passphrase still throws),
just closes the re-entry foot-gun.
Refs aiolabs/nsecbunkerd#16 (autounlock — this is the idempotency
sub-task lnbits flagged in the design surface).
Caught during regtest dogfood after the previous three commits
landed. With `nostr-tools: ^2.17.2` pnpm resolved to 2.23.5, which
in turn pulls `@noble/curves@2.0.1` — ESM-only. The regtest
Dockerfile runs on Node 20.11.1, where CJS `require()` of pure-ESM
modules is hard-blocked:
Error [ERR_REQUIRE_ESM]: require() of ES Module
/app/node_modules/.pnpm/@noble+curves@2.0.1/.../secp256k1.js
from /app/node_modules/.pnpm/nostr-tools@2.23.5/.../index.js
not supported.
nostr-tools 2.21.0 was the cutover — that release flipped
`@noble/curves` from `1.2.0` to `2.0.1`. 2.20.0 is the last
nostr-tools 2.x release that's still CJS-friendly via @noble/curves
1.2.0. Capping our pin at `~2.20.0` keeps us within the
"nostr-tools >= 2.17.2" range NDK 3.0.3 asks for in its
peerDependency while sidestepping the ESM/CJS hazard.
This isn't a regression we introduce — it's a CJS-output footgun
unique to the regtest container's Node 20 + tsup-default-CJS
combination. Long-term fix paths (out of scope here):
* Bump the container's Node base image to >= 22 (where
`--experimental-require-module` is on by default for `.js`
files inside `package.json type: "commonjs"`)
* Switch tsup output to ESM (`tsup --format esm`) — wider
surface change across the daemon, the client CLI, and the
Dockerfile entrypoint
* Accept the cap forever (small downside: 2.21+ patch fixes
won't reach us until we fix one of the above)
The cap is intentionally tight (`~2.20.0` allows 2.20.x patches,
nothing newer) so a future `pnpm update` doesn't silently jump us
back over the 2.21 edge. Revisit when one of the long-term paths
above lands.
Refs aiolabs/nsecbunkerd#14, regtest dogfood 2026-05-31.
NDK 3.x's `NDKNip46Backend` passes the wire method name verbatim
to `pubkeyAllowed` — `nip04_encrypt`, `nip04_decrypt`,
`nip44_encrypt`, `nip44_decrypt`, etc. NDK 2.8.1 normalized these to
`encrypt`/`decrypt` before calling the permit callback; that
normalization was the root of why our encrypt/decrypt path had
never worked end-to-end against lnbits's bunker-backed signer
(lnbits stores `PolicyRule.method` using wire names, our auth
lookup looked for the normalized name → no match → request fell
through to the never-resolved admin prompt and timed out at 15s).
Source `IMethod` directly from NDK's exported `NIP46Method` union so
it can't drift across future bumps. If NDK adds a new method
(e.g. `nip60_*`) we pick it up for free. Drop the `method as IMethod`
cast at the `signingAuthorizationCallback` call site — both sides
now share the same vocabulary by construction.
This is the substantive win that aiolabs/nsecbunkerd#14 is filed for.
With this commit:
- `sign_event` policy rules with kinds continue to match exactly as
before (kind stringification path unchanged).
- `nip04_encrypt` / `nip04_decrypt` / `nip44_encrypt` / `nip44_decrypt`
policy rules — kind-less — now match the live-policy join (step 4
of `checkIfPubkeyAllowed`) by their method-name alone. lnbits's
bunker-mediated `signer.nip44_decrypt` and `signer.nip44_encrypt`
calls (per `aiolabs/lnbits` PR #38 phase 2.4) start succeeding
end-to-end against any operator account whose Policy carries those
rules — which `_ensure_policy`'s self-heal already ensures for
every newly-bound operator (per coord log 2026-05-30T22:00Z).
- `switch_relays` (new in NDK 3) flows through the auth check the
same way as any other method.
`requestToSigningConditionQuery` needs no further change — the
existing `sign_event` switch case covers the only method that
discriminates on kind; all other methods use the default
`{ method }` query against the override layer, which is correct
for the kind-less wire names too.
Refs aiolabs/nsecbunkerd#14, aiolabs/nsecbunkerd#11 (whose live-policy
join this finally puts to use).
Mechanical adjustments to the source after the dep bump in the
previous commit. No semantic changes — every site adapts to API
drift between the pinned versions.
Surface changes addressed:
* `NDKKind` strict numeric enum (was wider in 2.8.1). 18 sites
passed the literal `24134` (NIP-46 admin-RPC response kind) to
`rpc.sendResponse` / `rpc.sendRequest`; NDK 3's `NDKKind` enum
omits 24134. Introduced `src/daemon/admin/kinds.ts` exporting
`NIP46_ADMIN_RESPONSE_KIND = 24134 as NDKKind` so the cast lives
once, and routed all 18 sites through the named constant.
* `NDKPrivateKeySigner` constructor now accepts nsec1 or hex
directly (the `@ai-guardrail` in NDK 3 source explicitly tells
callers not to `nip19.decode` ahead of construction). Simplified
`Daemon.startKey` and `createNewKey` accordingly — the bech32
decode workaround for #8 was tied to NDK 2.8.1's old behavior
and is no longer needed.
* `NDKPrivateKeySigner.privateKey` is `string` (hex) on the public
surface, not `Uint8Array`. `nostr-tools` v2's `nip19.nsecEncode`
wants `Uint8Array`. Replaced `nip19.nsecEncode(key.privateKey!)`
with `key.nsec` (NDK 3 exposes the getter directly), avoiding
both the type mismatch and the unnecessary round-trip. For the
one remaining hex-string-from-config call site, used
`nostrUtils.hexToBytes` to convert before encoding.
* `NDKPool` event rename: `'relay:notice'` → `'notice'`, with
flipped arg order `(notice, relay)` → `(relay, notice)`.
* `NDKUser.fromNip05` now requires the `ndk` instance as a 2nd
positional arg (was implicit-global before).
* `Nip46PermitCallbackParams.params` narrowed to `string |
NostrEvent`; type guards added at the two access sites
(`authorize.ts` and `acl/index.ts:requestToSigningConditionQuery`).
* `req.params` is now `(string | undefined)[]` instead of `any[]`;
`create_account.ts` `authorizationWithPayload` branch now
explicitly throws on missing username/domain before passing to
`createAccountReal` (validates what was implicit before).
* Removed `src/daemon/backend/publish-event.ts` (defined a strategy
that's never registered — wiring is commented out in
`backend/index.ts:22`; in NDK 3 the file refs the removed
`NDKNip46Backend.signEvent`). Dead since at least NDK 2.x; the
bump just made the breakage visible.
Pre-existing `tsc` errors at `src/db.ts` and `src/daemon/authorize.ts`
on `'PrismaClient'` / `'Request'` exports are unrelated to this PR —
the regtest container's nix derivation can't reach the prisma engine
binary store on this host (`nsecbunkerd#14` parked separately).
`pnpm run build` (tsup) is green; the Docker container runs
`prisma generate` against its own engine at image-build time and
resolves these at runtime.
#11's wire-name policy convention adoption is the next commit —
this one is purely keep-it-compiling work.
Refs aiolabs/nsecbunkerd#14.
NDK 2.8.1 (Apr 2024) is 2 years old and predates NIP-46 backend-side
nip44 support. With aiolabs/lnbits#38's phase-2.4 client-side migration
to bunker-mediated nip44_*, the bunker's lack of a `nip44_decrypt`
strategy registration causes wire RPCs to fall through to
`sendResponse(id, remotePubkey, "error", undefined, "Not authorized")`
at NDK 2.8.1's backend/index.ts:179. Even nip04 was silently broken:
2.8.1 normalizes the wire method to `encrypt`/`decrypt` for
`pubkeyAllowed` while lnbits's policy stores wire names. The
encrypt/decrypt path through nsecbunkerd has never actually worked
end-to-end; it just hadn't been exercised until phase 2.4 landed.
3.0.3 (Feb 2026) is the current `latest` dist-tag and ships:
- `nip44_encrypt` / `nip44_decrypt` backend handlers registered
by default + wire-name `pubkeyAllowed` semantics (the immediate fix)
- `switch_relays` NIP-46 support for client-side relay migration
- Configurable NDKNip46Signer timeout (pairs with lnbits PR #38's
matching client-side config)
- NIP-44 default outgoing encryption with NIP-04 compat fallback
- Async error handling fix in backend dispatch — failed strategies
report errors instead of silent drop (deb7f93d)
- "Not enough relays received this event" race-condition fix on
publish (relevant to open #7 — may close that one too)
- Signature verification moved in-house (off legacy nostr-tools v1
path)
- 2 years of security/perf updates in transitive @noble/* crypto
primitives
`nostr-tools` bumped from ^1.17.0 to ^2.17.2 alongside because NDK
3.x's `NDKPrivateKeySigner` imports `finalizeEvent` / `generateSecretKey`
+ uses the `./nip49` subpath, none of which exist in nostr-tools v1.17.
With v1.17 installed, `require('@nostr-dev-kit/ndk')` fails with
"Package subpath './nip49' is not defined". Confirmed against the
post-install module graph.
Source migrations for NDK 3 / nostr-tools v2 API surface land in the
follow-up commit; this commit is intentionally just the dep bump so
the diff stays reviewable. Refs aiolabs/nsecbunkerd#14 +
coord-log 2026-05-31T09:55Z.
Six new admin-RPC handlers that complement the live-policy auth
rewrite. Each follows the canonical create_new_policy.ts pattern
(single JSON-stringified param, kind-24134 response, one prisma
mutation, no per-call ACL — validateRequestFromAdmin gates them
via the admin-npub allowlist).
Policy-level mutations propagate to every KeyUser bound to the
policy at the next sign-time check (the point of #11):
add_policy_rule { policyId, rule: {method, kind?, maxUsageCount?} }
remove_policy_rule { ruleId }
update_policy { policyId, patch: {name?, expiresAt?} }
Per-KeyUser override mutations (override layer):
add_signing_condition { keyUserId, condition: {method, kind?, allowed} }
remove_signing_condition { conditionId }
Surgical token revocation without nuking the KeyUser:
revoke_token { tokenId }
The 'all' kind literal is honored as a wildcard in add_policy_rule
for parity with the SigningCondition override-layer convention.
Param shapes ratified by webapp in
#11 (comment).
refs: #11
Shifts sign-time authorization from materialized SigningCondition
snapshots (frozen at token-bind time) to a layered model:
1. fetch KeyUser; missing → undefined
2. KeyUser.revokedAt set → false
3. SigningCondition override layer (explicit reject, per-(method,
kind) grant/deny) → return matching row's allowed value
4. live policy join: KeyUser → Token (revokedAt IS NULL) →
Policy → PolicyRule. Match on method + kind (exact /
'all' / NULL defensive) → true
5. else → undefined (caller may still prompt admin)
Backwards-compatible. The existing applyToken fan-out of
SigningCondition rows continues to populate step 3 for legacy
auth, so already-bound users keep working with no behavior change.
New users will still go through that fan-out until the follow-up
trim (#12). The key win: PolicyRule mutations via the upcoming
companion RPCs (add_policy_rule / remove_policy_rule / etc.)
propagate live to every KeyUser bound to that policy, rather than
requiring per-user backfill RPCs that don't exist.
Algorithm ratified by webapp in
#11 (comment).
refs: #11
Pre-requisite for the live-policy auth rewrite in #11. The new
revoke_token admin RPC needs a way to mark a single Token as
revoked without nuking the whole KeyUser (revoke_user) or
conflating with future expiry cleanup (deletedAt).
Nullable DateTime — existing rows default to NULL (active), no
data migration needed.
refs: #11
Two-layer fix for the issue where a fresh client chaining
create_new_key + NIP-46 connect on the same target key would
time out — bunker had no subscription registered for the new
key by the time the connect event arrived at the relay.
Layer 1 — run.ts: loadNsec and unlockKey were synchronous and
fire-and-forgot the async startKey promise. create_new_key.ts:35
already awaited loadNsec, but the await was a no-op against a sync
return. Promoted both to async and properly awaited startKey, so
backend.start() at least gets a chance to run before the caller's
response goes out.
Layer 2 — backend/index.ts: NDKNip46Backend.start() registers the
kind-24133 subscription via this.ndk.subscribe(...) but returns
immediately, before the relay's EOSE confirms it has the
subscription on file. Override start() in our Backend subclass to
await EOSE before resolving. This is the actual race-closer —
layer 1's await alone wasn't enough because start() was still
returning before the relay registered the subscription.
Surfaced by aiolabs/lnbits#33's eager-bind chain, which publishes
a NIP-46 connect event in the same HTTP round-trip as
create_new_key. Pre-fix lnbits deferred the connect to first
sign_event (minutes-to-hours after provisioning), so the race
window was hidden.
Verified end-to-end on bohm regtest: demo account creation through
the webapp now completes cleanly, with bunker logs showing
connect + sign_event for the freshly-provisioned key.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Calls `relayConnectionWatchdog` (introduced in the previous commit) at
the end of admin-interface connect(). Gated by NSEC_BUNKER_DISABLE_WATCHDOG=1
for operators who run external liveness checks (Prometheus probes, k8s
readiness, etc.) and don't want the daemon to self-terminate.
This restores the watchdog behavior that was commented out in commit
42dbbd7 (the emergency stopgap for the old self-echo false positives),
but on top of the now-reliable pool-status mechanism.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The original watchdog published a kind-24133 event to its own pubkey
every 20s and exited if no echo arrived within 50s. On a single private
relay setup (LNbits's nostrrelay extension channel), NDK 2.8.1's outbox
model doesn't reliably route self-publishes back through the matching
subscription, so the watchdog fires false positives and exits every 50s
even though admin RPCs over the same channel still work fine. The
upstream patches we landed previously (commit 42dbbd7) commented the
call out as an emergency stopgap; this commit replaces the mechanism
with one that actually answers the right question.
Pool-status watchdog: poll `ndk.pool.connectedRelays().length` every
10s, track the most recent moment any relay was connected, exit if no
relay has been connected for 60s. Uses NDK's own connection-lifecycle
tracking which works reliably across all relay configurations — no
self-publish, no subscription dependency, no relay traffic. Same intent
as pingOrDie (detect partition from relay layer and let the supervisor
restart us), reliable signal.
Call site re-enable + env-flag opt-out follow in the next commit.
Drops the now-unused NostrEvent import.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Three correctness fixes to the nix derivation that mirror the Dockerfile
correctness fixes:
1. Drop `pnpm prune --prod --ignore-scripts` from the build phase. The
prune step removed the prisma CLI (devDependency) from the output,
so the runtime invocation of `prisma migrate deploy` had nothing to
exec. Same trap the upstream Dockerfile fell into via `--prod` install.
2. Copy `scripts/` into `$out/share/nsecbunkerd/` alongside dist,
node_modules, prisma, templates. Without it the launcher script
(which contains the migration step) wasn't present.
3. The makeWrapper target switches from `dist/index.js` to
`scripts/start.js`. Same change the Dockerfile ENTRYPOINT got in
the previous commit. Also adds nodejs_20 to PATH so `npm` is
resolvable from inside start.js, and drops `--chdir` so the caller
(systemd, docker compose) controls cwd — start.js now resolves
sibling paths from `__dirname`, independently committed.
The `patchNdk` substitution narrows from the old `workspace:*` form
(no longer in the package.json after fork commit 06272c8) to the
current `"2.8.1"` → `"^2.8.1"` rewrite needed to align package.json
with the lockfile under --frozen-lockfile.
Remaining known gap: nixpkgs ships prisma-engines 7.7.0 while the
JS prisma CLI in node_modules is 5.4.1, an RPC vocabulary mismatch
that breaks the migrate step at runtime (`Method not found:
listMigrationDirectories`). Either bump prisma JS to ^7.x or overlay
prisma-engines to 5.4.1. Out of scope for this commit; docker build
unaffected.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The launcher previously assumed cwd was the package root: `mkdir config`
in cwd, `npm run prisma:migrate` in cwd, `node ./dist/index.js`. Works
under docker (WORKDIR /app, writable) but breaks anywhere cwd differs
from the package root — e.g. a nix-built bunker invoked from a systemd
unit whose WorkingDirectory is the state dir (/var/lib/nsecbunkerd) and
not the nix store path that holds dist/, scripts/, prisma/.
Resolve sibling paths via `path.resolve(__dirname, '..')` so the
package-internal layout is robust to cwd. Use `path.join(pkgRoot, 'dist/index.js')`
for the daemon spawn and `{ cwd: pkgRoot }` for the npm migrate exec.
Switch `mkdir config` (which only works in writable cwd) to
`fs.mkdirSync(configDir, { recursive: true })` where configDir defaults
to `./config` relative to cwd, overrideable via NSEC_BUNKER_CONFIG_DIR.
This lets the nix package install the launcher into the read-only store
while the systemd unit still does its config/state work in
/var/lib/nsecbunkerd with no shell wrapping.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Upstream Dockerfile sets `ENTRYPOINT [ "node", "./dist/index.js" ]`,
which boots the daemon directly and silently bypasses `scripts/start.js`
— the only place that runs `prisma migrate deploy`. On a clean install,
the SQLite db file at $DATABASE_URL is created empty (0 bytes) and
every Policy / KeyUser / Token / SigningCondition operation throws
"table does not exist." `ping` / `get_keys` / `create_new_key` happen
to survive because they only touch the JSON config, not the db.
Two changes:
1. ENTRYPOINT switches to `node ./scripts/start.js`. The CMD arg
(`start`) and any additional argv pass through to the daemon
unchanged via process.argv.
2. Runtime pnpm install drops `--prod`. The prisma CLI lives in
devDependencies; with `--prod`, `npx prisma migrate deploy` tries to
download prisma@latest at runtime, which OOMs in modest containers.
Including devDeps at runtime adds modest image bulk for correctness.
Validated end-to-end against the local regtest stack — after the
rebuild the SQLite db boots populated with 22 migrations, and the
lnbits-side admin spike harness passes all 9 steps including NIP-46
sign_event with Schnorr-valid signatures.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The wire-level `create_new_token` RPC carries `policyId` as a string
(everything in NDK RPC params is string). The handler correctly
parseInts it for the `findUnique({where:{id:parseInt(policyId)}})` call
but then forwards the unparsed string straight into the Prisma
`token.create({data:{...policyId}})` payload. Prisma rejects with
"Argument `policyId`: Invalid value provided. Expected Int or Null,
provided String" because `Token.policyId` is declared `Int` per the
schema (references `Policy.id`, which is autoincrement Int).
Hoist `policyIdInt = parseInt(policyId)` and use it for both the
findUnique lookup and the create payload. Latent upstream bug — no one
would have seen it before because the wrong-kind error response (fixed
in the previous commit) made the symptom look like a transport timeout
rather than a Prisma validation error.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The catch block in handleRequest and both response paths in create_account
pass `NDKKind.NostrConnectAdmin` as the response kind. That constant does
NOT exist in NDK 2.8.1 — only `NostrConnect = 24133` is exported — so it
resolves to `undefined` and NDKNostrRpc.sendResponse falls through to its
own default of `NDKKind.NostrConnect = 24133`. Net effect: any error
response to an admin-channel (kind 24134) request is published on the
NIP-46 signing channel (24133) instead, which clients subscribed for
24134 never see. Looks like a transport-layer NDK-echo / silent-drop
issue from the client's perspective, but the bunker IS publishing
reliably — just on the wrong kind.
Mirror `req.event.kind` so the error response goes back on the same
channel the request came in on. Same pattern the unknown-method path
and create_account's validation-error path already used; just propagate
it to the remaining sites. Drops the now-unused NDKKind import from
create_account.ts.
Validated end-to-end against the local bunker via the lnbits-side admin
spike harness — after this fix + the migration entrypoint fix + the
policyId type fix, all 9 spike steps including NIP-46 sign_event pass
with Schnorr-valid signatures. See coordination log entry 2026-05-27T14:30Z.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Add NSEC_BUNKER_DEBUG_TRANSPORT=1 opt-in logging that emits REQUEST_IN
on inbound NIP-46 RPCs, RESPONSE_SENT around NDKNostrRpc.sendResponse,
and PUBLISHED / PUBLISH_FAILED per-relay on the bunker's pool. Surfaces
the diagnostic signal NDKNostrRpc itself discards: sendResponse calls
`event.publish(this.relaySet)` and throws away the Set<NDKRelay> it
returns, so silent outbox-drops and wrong-kind responses are invisible
without hooking the pool's per-relay events directly.
Validated against the local bunker via the lnbits-side admin spike
harness (~/dev/lnbits/misc-aio/bunker_admin_spike.py): the instrumentation
made the 9-step harness reveal a wrong-kind error response path (separate
fix in the next commit) that had been masquerading as an NDK echo issue
for a week. With the env flag unset the daemon stays as quiet as before.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
NDK 2.8.1's NDKPrivateKeySigner constructor forwards its arg straight
to nostr-tools getPublicKey() which requires 32-byte hex/bytes/bigint
and throws on bech32 input. Every key loaded through startKey (i.e.
every key created via create_new_key, plus boot-time reloads of any
plain-nsec entries in the config) was failing silently with the
nostr-tools type error. The try/catch caught the throw and returned
without loading the key, so the bunker would happily report
create_new_key as successful, the key would persist encrypted on
disk, but the runtime keystore would not have a signer for it.
NIP-46 connect / sign_event against any admin-provisioned target
therefore silently timed out from the client side — blocking
essentially every signing flow.
Sister bug to #5 (getKeys iterator) in a different code path. The
fix matches the existing pattern in create_new_key.ts:16:
hexpk = nip19.decode(nsec).data as string;
Verified against the local spike harness: create_new_key now loads
the target into runtime; get_keys returns the new entry (assuming
#5 is patched separately for the iterator path).
Fixes#8.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
NDK 2.8.1's outbox model doesn't reliably deliver self-published
events back through subscriptions when the configured relay set is
a single custom (non-public) relay. The pingOrDie self-watchdog
publishes a kind-24133 event to its own pubkey every 20s and exits
the bunker if it doesn't see the echo within 50s — which means on
a private relay channel (e.g. LNbits's nostrrelay extension), the
bunker exits cleanly every 50s even though admin RPCs over that
same channel are working fine.
Plain-WebSocket round-trips to the same relay echo correctly in
<1s, so the issue is on NDK's side, not the relay's.
Commenting out the watchdog is the minimum patch to keep the
daemon alive. Real fix is either an env-flag opt-out, a simpler
connectivity check that doesn't depend on self-echo, or an NDK
upgrade that fixes the outbox-vs-subscribe race.
Fixes#4. See also #7 for the underlying NDK echo investigation.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Two upstream-rot issues fixed in one commit (same root cause: the
upstream Dockerfile predates the move to pnpm and the lockfile has
drifted):
- npm install can't resolve workspace:* deps (which package.json used
to declare for @nostr-dev-kit/ndk — see prior commit for the pin).
Switching to pnpm@9 matches the lockfile that ships in-repo.
- pnpm-lock.yaml is out of date vs package.json (likely from
generation-time vs commit-time drift), so --frozen-lockfile fails
with ERR_PNPM_OUTDATED_LOCKFILE. Drop the flag in both build and
runtime stages to let pnpm resolve fresh, at the cost of giving up
determinism — to be restored once the lockfile is regenerated.
Also reorders the build stage to COPY lockfile + manifest before the
source, so the install layer caches across source-only edits.
Fixes#1, #2.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Upstream declares the dependency as workspace:*, but the repo has no
pnpm-workspace.yaml and no sibling @nostr-dev-kit/ndk package — so
pnpm install fails with ERR_PNPM_WORKSPACE_PKG_NOT_FOUND on a clean
clone. The shipped pnpm-lock.yaml was resolving to ndk 2.8.1, so pin
to that exact version to match what the lockfile already expects.
Fixes#3.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
devShell: nodejs_20, pnpm_8, prisma + prisma-engines, sqlite, openssl,
plus the env wiring so prisma uses nix-provided engines instead of
fetching from binaries.prisma.sh.
packages.default: full native build via pnpm_8.fetchDeps + configHook.
Patches the workspace:* ndk spec to the lockfile-resolved ^2.8.1 so
--frozen-lockfile accepts it, then re-runs install with scripts to
trigger bcrypt's node-pre-gyp fallback-to-build (uses python311 since
node-gyp 9.4.1 bundled with pnpm 8 still imports distutils).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
