feat(transport): get_machine_config RPC — server-delivered machine config (#41) #42
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "feat/get-machine-config-rpc"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Closes #41. Client half: aiolabs/bitspire#71 (+ its PR).
What
A paired ATM pulls its operator pubkey + fee config over the already-authenticated kind-21000 transport, instead of the operator pubkey being provisioned into the machine's
.envand the fee config learned only from an operator-signed kind-30078 broadcast. This lets a seed-only machine (blank.env, scannedspire-seed) leave "awaiting configuration" with zero per-machine provisioning — closing the gap surfaced by bitspire#70.How
machine_config_transport.pyregisters aget_machine_configRPC (mirrors the reviewedcashin_transportpattern):request.sender_pubkey(the ATM's bunker-minted spire key ==dca_machines.machine_npub) — same lookup ascashin_transport, no client-supplied trust; only ever returns the caller's own config.{operator_pubkey, fee_config, fiat_code, machine_npub, wallet_id, created_at}.fee_configis None until the operator has a super-config;created_atis a freshness watermark (max of machine + super-configupdated_at) for the consumer's replay guard.build_fee_payload+get_account;AUTH_ACCOUNT; the reply is NIP-44 v2 encrypted to the sender by the transport (no operator-key encryption here).register_rpc), like the roster hook — spirekeeper still boots; ATMs fall back to env/kind-30078.The kind-30078 push path stays dual-run for live mid-run fee updates.
Trust rationale (per #41)
Delivering the operator pubkey over the transport means LNbits introduces the operator identity. On this stack that doesn't widen the trust base — spirekeeper is an LNbits extension in the same trust domain, and the ATM already trusts LNbits with the wallet and server-side fee computation. So this aligns config trust with the trust already extended for money. (Full seed-shape / NWC / Lightning.Pub analysis is in #41.)
Tests
6 new tests (
test_machine_config_transport.py) — returns config, watermark-is-max, no-super-config, unpaired sender, operator-without-pubkey, missing-sender. Full suite 235 pass; black + ruff clean.Validated on hardware
Against a patched aio-demo, a Sintra (machine
FqnYZ…) that was sitting at "awaiting configuration" pulled its config and reachedidle— server log:get_machine_config machine=FqnYZ… operator=8b2498… fee_config=present; ATM log:Operator pubkey(s): … (server-delivered, #70 P1)→Server-delivered fee config: applied→State: idle.Process
Money-adjacent extension → merge via the Forgejo UI after review (I don't merge). Additive + soft-failing, so it's safe to ship ahead of the bitspire client.
🤖 Generated with Claude Code
A paired ATM pulls its operator pubkey + fee config over the already- authenticated kind-21000 transport, instead of the operator pubkey being provisioned into the machine's .env and the fee config learned only from an operator-signed kind-30078 broadcast. This lets a seed-only machine (blank .env, scanned spire-seed) leave "awaiting configuration" with zero per-machine provisioning — closing the gap surfaced by bitspire#70. Client half: bitspire#71. The transport is already per-machine authenticated (the ATM signs with its bunker-minted spire key == dca_machines.machine_npub), so the handler resolves the exact machine → operator from the verified request.sender_pubkey — same lookup as cashin_transport, no client-supplied trust — and returns only the caller's own config. Returns {operator_pubkey, fee_config, fiat_code, machine_npub, wallet_id, created_at}; fee_config is None until the operator has a super-config. Reuses build_fee_payload + get_account; AUTH_ACCOUNT; registers soft-failing (older lnbits) like the roster hook. kind-30078 push stays dual-run for live mid-run updates. 6 tests; full suite 235 pass; black + ruff clean. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>