fix(pairing): default bunker_relay to the spire's public event relay, not localhost #35

Merged
padreug merged 1 commit from fix/pair-bunker-relay-default into main 2026-06-22 15:21:13 +00:00
Owner

The bug (flagged by bitspire on the demo)

A seed minted via the Pair UI bakes an unreachable bunker relay into bunker_url:

bunker_url ?relay= ws://127.0.0.1:5000/nostrrelay/demo   ❌ localhost
relays[]            wss://lnbits.demo.aiolabs.dev/...     ✅ public

The Pair form has no bunker_relay field, so pair_spire falls back to its default settings.lnbits_nsec_bunker_url — which on a deployed instance is the internal relay lnbits uses to reach the co-located bunker (ws://127.0.0.1). The remote Sintra can't reach localhost → connectNewSeed hangs → BunkerTimeoutError "Signer Unreachable." This is the localhost-relay /pair gotcha the coord thread called out long ago.

Fix

Default bunker_relay to the spire's own public event relay (relays[0]): the bunker lives on the same operator nostrrelay the spire publishes its events to, so that URL is machine-reachable. An explicit bunker_relay still overrides (split-relay deploys). An empty override now falls back to the same default instead of raising.

Regression test: with no (or empty) bunker_relay, bunker_url embeds relays[0] and contains no 127.0.0.1.

Pairing tests 15/15; full suite 212 passed (only the 2 pre-existing test_pair_endpoint failures from #29 drift, #34); ruff clean.

Not settled — follow-up

relays[0] is a pragmatic default. Whether the seed should carry multiple relays, or source the bunker relay from the operator's nostrclient relay config, is a real design question — tracked in #36.

🤖 Generated with Claude Code

## The bug (flagged by bitspire on the demo) A seed minted via the **Pair UI** bakes an **unreachable** bunker relay into `bunker_url`: ``` bunker_url ?relay= ws://127.0.0.1:5000/nostrrelay/demo ❌ localhost relays[] wss://lnbits.demo.aiolabs.dev/... ✅ public ``` The Pair form has no `bunker_relay` field, so `pair_spire` falls back to its default `settings.lnbits_nsec_bunker_url` — which on a deployed instance is the **internal** relay lnbits uses to reach the co-located bunker (`ws://127.0.0.1`). The remote Sintra can't reach localhost → `connectNewSeed` hangs → `BunkerTimeoutError` "Signer Unreachable." This is the localhost-relay /pair gotcha the coord thread called out long ago. ## Fix Default `bunker_relay` to the spire's own **public event relay** (`relays[0]`): the bunker lives on the same operator nostrrelay the spire publishes its events to, so that URL is machine-reachable. An explicit `bunker_relay` still overrides (split-relay deploys). An empty override now falls back to the same default instead of raising. **Regression test:** with no (or empty) `bunker_relay`, `bunker_url` embeds `relays[0]` and contains no `127.0.0.1`. Pairing tests 15/15; full suite 212 passed (only the 2 pre-existing `test_pair_endpoint` failures from #29 drift, #34); `ruff` clean. ## Not settled — follow-up `relays[0]` is a **pragmatic** default. Whether the seed should carry **multiple** relays, or source the bunker relay from the operator's **nostrclient** relay config, is a real design question — tracked in **#36**. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
fix(pairing): default bunker_relay to the spire's public event relay, not localhost
Some checks failed
ci.yml / fix(pairing): default bunker_relay to the spire's public event relay, not localhost (pull_request) Failing after 0s
b55fc8bc1c
The seed minted via the Pair UI baked an unreachable bunker relay into
bunker_url. The UI form has no bunker_relay field, so pair_spire fell back to
its default `settings.lnbits_nsec_bunker_url` — which on a deployed instance is
the INTERNAL relay lnbits uses to reach the co-located bunker (e.g.
ws://127.0.0.1:5000/nostrrelay/demo). The remote ATM can't reach localhost, so
connectNewSeed hangs -> BunkerTimeoutError "Signer Unreachable". (Flagged by
bitspire on the demo; the localhost-relay /pair gotcha the coord thread called out.)

Default bunker_relay to the spire's own public event relay (relays[0]) instead:
the bunker lives on the same operator nostrrelay the spire publishes its events
to, so that URL is machine-reachable. An explicit `bunker_relay` still overrides
for split-relay deploys. An empty override now falls back to the same default
rather than raising.

Regression test: with no (or empty) bunker_relay, bunker_url embeds relays[0]
and contains no 127.0.0.1.

NOTE: relays[0] is a pragmatic default; whether the seed should carry multiple
relays / be sourced from the operator's nostrclient relay is a follow-up.
padreug deleted branch fix/pair-bunker-relay-default 2026-06-22 15:21:13 +00:00
Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
aiolabs/spirekeeper!35
No description provided.