# Core Lightning Pay reseach Agenda

## Introduction

- https://github.com/ElementsProject/lightning/issues/7219

--

### Meeting June 10th

- We discuss the current state of the art
- We discuss the time line
- We discuss the code base [github link](https://github.com/tareknaser/barq)

----

# Project Timeline

## Introduction
Barq is an extensible Core Lightning pay plugin written in Rust. Using the strategy design pattern, Barq allows for easy testing with various routing algorithms. Its goal is to make it simpler for developers to experiment with new routing strategies without the risk of breaking existing functionality.

Repository on github: https://github.com/tareknaser/barq

## Relevant Github issues
- https://github.com/ElementsProject/lightning/issues/7219
- https://github.com/ElementsProject/lightning/issues/7180
- https://github.com/ElementsProject/lightning/issues/6793

## Prerequisites and Learning
- Strategy design pattern in Rust
- Existing reference plugins
- `cln-opentelemetry`
- `easy-rgb`
- `folgore`
- `renepay`
## Progress
To track the development of Barq, we have outlined a series of milestones:
- **Set Up Initial Project Structure**: ✅
- Create the basic project structure with two crates: `barq-common` and `barq-plugin`
- **Basic Plugin Functionality** (mephisto): ⏳
- Implement a simple direct payment functionality in the plugin to verify end-to-end operation.
- Explore how to get more information from core lightning failute.
- Keep in mind that exist private channel (Side project for end july)
- **Explore Integration with LDK** (tarek): ⏳
- Examine the feasibility of integrating Lightning Development Kit (LDK) payment logic within the plugin.
- A call with Vincent next week
- **CI Tests** (vincenzo) ⏳:
- Set up CI tests to simulate payment.
- **Database** (we look at it when we need to store payment failure):
- Implement a basic database to log information about payments and network state, to help in future payment optimizations and analytics.
- **Review and Refine Data Structures**:
- Revisit and refine key structs such as `NetworkGraph`, `RouteInput`, `RouteOutput`, and `PluginState` to ensure they hold all necessary information for current and future requirements.
- **Support for Multipart Payments**:
- Implement support for multipart payments. Determine if any modifications are needed in the current implementation.
- **Documentation and Community Feedback**:
- Develop documentation to facilitate community engagement and feedback.
- **Address Reported Issues in existing CLN pay plugin**
- Review reported issues and attempt to reproduce them in the development environment.
- Propose and implement solutions to resolve identified issues and improve overall plugin functionality.
- **Create the graph from gossipmap and not from listchannel**

## Project Structure
Barq is organized into two crates to keep the responsibilities clear
#### `barq-common`
- **Purpose**: Handles routing decisions for payments.
- **Responsibilities**:
- Implements different routing algorithms.
- Provides a `Router` struct that takes payment information and returns the route hops based on the selected routing algorithm.
#### `barq-plugin`
- **Purpose**: Core Lightning plugin.
- **Responsibilities**:
- Interacts with Core Lightning to get necessary information about the invoice and the network state.
- Passes the information to `barq_common::Router` to determine the route hops.
- Executes the payment based on the route hops provided by the `Router`.
# Questions
- [x] Database
- [x] Which to use?
- [x] What to store?
- [x] How to add CI?
- [x] Optimally for now, direct payment using `barq-plugin` on core lightning

----

## Integration testing

- Look at this PR https://github.com/LNOpenMetrics/go-lnmetrics.reporter/pull/147
- https://github.com/LNOpenMetrics/go-lnmetrics.reporter/pull/147/files#diff-e781a99fe35526bb8f340043336c05a60ac59b8483f481c3c757e1bdc2ec2d23
- I will try to implement the PR

## error logs
https://github.com/ElementsProject/lightning/issues/7180#issuecomment-2184130864

## Plugin Architecture (discuss them later)
- Currently, all channels are treated as bidirectional
- How to handle if payment fails
- see if best strategy implementation can be improved
- check for code quality
- check structs
- write tests for plugin architecture