Files
archy/docs/lightning-flow.md
T

5.2 KiB

Inbound-first Lightning setup

Branch: lightning-flow.

Scope

  • The channel screen offers purchased Olympus inbound capacity first and self-funded outbound channels second.
  • Accept Payments, Open a Shop and Run a Lightning Node all offer the same choice before a wallet deposit. Choosing inbound completes only the funding choice; it does not complete channel setup.
  • The purchase dialog uses the shared BaseModal (keyboard focus/Escape, history, body scroll locking, independently scrolling content and pinned actions).
  • Preparation reads the local LND public key and sync state, requests a persistent peer connection through authenticated lnd.connectpeer, and verifies the peer is actually listed. An asynchronous dial acknowledgement is not readiness.
  • The user copies the public key into the official https://channels.zeuslsp.com/ portal and reviews its current price/lease. This implementation does not create orders, pay invoices, or embed an LSPS checkout.
  • The fee can be paid from another Lightning wallet. Purchased capacity is not owned bitcoin. Closing settles only the local balance to the local LND wallet, subject to fees, confirmations and potential force-close timelocks.
  • Available inbound changes with payments and is less than nominal capacity because of channel overhead. The UI does not promise a permanently available receiving allowance.

Completion

The goal's explicit “Check channels and continue” action fetches fresh channel state. Pending, closing, disconnected and outbound-only channels cannot complete a receiving goal. Routing readiness additionally requires different peers and liquidity in both directions. These checks are prerequisites, not a successful end-to-end payment test or guarantee of routing income.

Merely navigating to channels or opening the external portal never marks channel setup complete. Existing saved goal step IDs are retained.

Safety and limitations

No daemon restart, deployment, real channel purchase or wallet mutation is part of validation. A normal demo-backend connection request fails explicitly rather than handing a fake node identity to a real paid service. The isolated preview simulates preparation and intercepts external links.

Provider terms and prices are external and can change. Consult the live portal before paying. Source documentation: advance purchase, channel limits, fees. A node must stay online while the provider opens the channel. The node's seed and channel backups remain essential.

Local preview

cd neode-ui
npx vite --config vite.lightning-preview.config.ts

Open http://localhost:8194. This mounts the actual channel component with simulated RPC responses. It does not use any node credentials.

Browser smoke test (or omit CHROMIUM_PATH when Playwright's matching Chromium is installed):

CHROMIUM_PATH=/usr/bin/chromium node previews/lightning/smoke.mjs

Validation results

  • Production frontend typecheck/build: passed (existing large-chunk warnings only).
  • Targeted frontend regressions: 67 passed, including all three Lightning goal return/completion paths.
  • Backend LND suite: 67 passed, including the loopback HTTP test of persistent connection preparation, live peer verification, and no channel-open request.
  • Chromium desktop/mobile smoke: passed (Tab focus containment, Escape, pixel scrolling, no horizontal overflow, no page errors, blocked demo checkout).
  • No live node deployment or purchase was performed.

Peer preparation authorization

lnd.connectpeer is a generic administrator-only persistent peer writer, not a payment or channel-opening operation. It requires a successfully loaded Admin record, authenticated session and valid CSRF. Browser callers must use the native dashboard origin; admitted high-port apps cannot invoke it. Originless CLI callers retain the same session/Admin/CSRF requirements. Missing or unreadable user records fail closed. Remember-me restoration does not bypass CSRF for this method. Addresses are administrator-selected; this is not an unauthenticated network probing API. The UI uses only the fixed Olympus peer.

Preparation persists a peer/reconnect entry. Closing the modal does not undo that entry, fund a channel, submit payment or complete a channel goal. The external portal opens using the Companion-aware external URL helper.

Validation commands

cd neode-ui
npm run build
npm test -- --run src/components/__tests__/LightningInbound.test.ts src/components/__tests__/LightningChannelsPanel.test.ts src/components/__tests__/BaseModal.test.ts src/views/goals/__tests__ src/stores/__tests__/goals.test.ts src/composables/__tests__/useIbdFinishWatcher.test.ts src/composables/__tests__/useModalKeyboard.test.ts

Backend unit and loopback HTTP tests:

# From repository root; never run unrestricted backend tests on an app node.
CARGO_BUILD_JOBS=2 scripts/test-backend-isolated.sh api::rpc::lnd::

Sparse checkouts must include tests/fixtures, required by an existing unrelated wallet test compiled into the binary. Set CARGO_TARGET_DIR to a writable location if the repository's existing target directory is root-owned.