Skip to content

Conversation

@Camillarhi
Copy link
Contributor

Opening this as an early draft to get feedback on the overall API direction

The current setup ties you to a single LSP per protocol via set_liquidity_source_lsps1 / set_liquidity_source_lsps2. This refactor replaces that with a unified Vec<LspNode> model where LSP nodes are added via add_lsp() and protocol support is discovered at runtime through LSPS0 list_protocols. Multi-LSP support has been requested previously in #529.

  • Deprecated set_liquidity_source_lsps1 / set_liquidity_source_lsps2 in favor of add_lsp()
  • Replaced the per-protocol LSPS1Client / LSPS2Client with global pending request maps keyed by LSPSRequestId
  • Added LSPS0 protocol discovery with event handling for ListProtocolsResponse
  • Background discovery task spawns on Node::start()
  • LSPS2 JIT channels now query all LSPS2-capable LSPs and automatically select the cheapest fee offer
  • Added request_channel_from_lsp() for explicit LSPS1 LSP selection
  • Updated event handling to use is_lsps_node() for multi-LSP counterparty checks

Replace per-protocol single-LSP configuration `LSPS1Client, LSPS2Client`
with a unified `Vec<LspNode>` model where users configure LSP nodes via
`add_lsp()` and protocol support is discovered at runtime via LSPS0
`list_protocols`.

- Replace separate `LSPS1Client/LSPS2Client` with global pending request
  maps keyed by `LSPSRequestId`
- Add LSPS0 protocol discovery `discover_lsp_protocols` with event
  handling for `ListProtocolsResponse`
- Update events to use is_lsps_node() for multi-LSP counterparty
  checks
- Deprecate `set_liquidity_source_lsps1/lsps2` builder methods in favor
  of `add_lsp()`
- LSPS2 JIT channels now query all LSPS2-capable LSPs and automatically
  select the cheapest fee offer across all of them
- Add `request_channel_from_lsp()` for explicit LSPS1 LSP selection
- Spawn background discovery task on `Node::start()`
@ldk-reviews-bot
Copy link

👋 Hi! I see this is a draft PR.
I'll wait to assign reviewers until you mark it as ready for review.
Just convert it out of draft status when you're ready for review!

@Camillarhi
Copy link
Contributor Author

@tnull Early draft up for review, would appreciate feedback on the general API direction

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants