Investigate the best bunker_relay source for seed URLs (multiple relays? nostrclient relay?) #36

New issue

Open

opened 2026-06-22 15:19:03 +00:00 by padreug · 0 comments

padreug commented

2026-06-22 15:19:03 +00:00

Owner

PR #35 (fix/pair-bunker-relay-default) defaults the seed's bunker_url relay to the spire's first event relay (relays[0]) to kill the localhost-relay gotcha (the UI-minted seed embedded ws://127.0.0.1, unreachable from the ATM). That unblocks the common single-public-relay deploy, but relays[0] is a pragmatic choice — let's decide the right long-term design.

Open questions

Single vs. multiple relays. A NIP-46 bunker:// URL can carry several relay= params. Right now we embed exactly one. Should the seed carry all of relays[] (or a configured set) so the spire can reach the bunker via a fallback if one relay is down? The spire's events already publish to multiple; the bunker connection arguably wants the same redundancy.
Is relays[0] the right source at all? It assumes the bunker is reachable on the same relay the spire publishes its events to. True for a single operator nostrrelay, but a split-relay deploy (spire events on relay A, bunker on relay B) breaks it. The bunker's actual relay is what the operator's bunker (and nostrclient) connect to — should we source the bunker relay from there (the nostrclient relay / the bunker's configured public relay) instead of inferring it from the spire's event relays?
Internal → public mapping. settings.lnbits_nsec_bunker_url is the internal relay lnbits uses to reach the co-located bunker (ws://127.0.0.1). There's no automatic internal→public translation. Options: a dedicated LNBITS_NSEC_BUNKER_PUBLIC_URL setting; derive from the instance's public base URL; or keep inferring from relays[].
UI. Should the Pair form expose a bunker_relay field (advanced/optional) for split-relay deploys, or stay simple and rely on the default + a server-side config?

Acceptance

A documented rule for which relay(s) a seed's bunker_url carries, robust across single-relay and split-relay deploys, and matching what the bunker actually listens on. Update pair_spire + the UI accordingly; supersede the relays[0] default from #35 if a better source is chosen.

Refs: #35 (the interim fix), coord thread (localhost-relay /pair gotcha), bitspire demo pairing.

PR #35 (`fix/pair-bunker-relay-default`) defaults the seed's `bunker_url` relay to the spire's first event relay (`relays[0]`) to kill the localhost-relay gotcha (the UI-minted seed embedded `ws://127.0.0.1`, unreachable from the ATM). That unblocks the common single-public-relay deploy, but `relays[0]` is a **pragmatic** choice — let's decide the right long-term design. ## Open questions 1. **Single vs. multiple relays.** A NIP-46 `bunker://` URL can carry several `relay=` params. Right now we embed exactly one. Should the seed carry **all** of `relays[]` (or a configured set) so the spire can reach the bunker via a fallback if one relay is down? The spire's events already publish to multiple; the bunker connection arguably wants the same redundancy. 2. **Is `relays[0]` the right source at all?** It assumes the bunker is reachable on the same relay the spire publishes its events to. True for a single operator nostrrelay, but a **split-relay** deploy (spire events on relay A, bunker on relay B) breaks it. The bunker's *actual* relay is what the operator's bunker (and `nostrclient`) connect to — should we source the bunker relay from there (the **nostrclient relay** / the bunker's configured public relay) instead of inferring it from the spire's event relays? 3. **Internal → public mapping.** `settings.lnbits_nsec_bunker_url` is the *internal* relay lnbits uses to reach the co-located bunker (`ws://127.0.0.1`). There's no automatic internal→public translation. Options: a dedicated `LNBITS_NSEC_BUNKER_PUBLIC_URL` setting; derive from the instance's public base URL; or keep inferring from `relays[]`. 4. **UI.** Should the Pair form expose a `bunker_relay` field (advanced/optional) for split-relay deploys, or stay simple and rely on the default + a server-side config? ## Acceptance A documented rule for which relay(s) a seed's `bunker_url` carries, robust across single-relay and split-relay deploys, and matching what the bunker actually listens on. Update `pair_spire` + the UI accordingly; supersede the `relays[0]` default from #35 if a better source is chosen. Refs: #35 (the interim fix), coord thread (localhost-relay /pair gotcha), bitspire demo pairing.

padreug referenced this issue

2026-06-22 15:19:48 +00:00

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

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#36

No description provided.

Rows
Columns