Merge ldk-server into ldk-node repository #773
Conversation
Implement first set of Api's
It is helpful in case of wrong input by user.
Add suggestions/error-context clap features.
Implement ListChannels and GetNodeInfo Api.
Now the setting in the example configuration file gets read correctly.
Previously, the daemon required a config file path argument and the CLI required explicit --api-key and --tls-cert flags. Now both default to reading from ~/.ldk-server/config.toml, so you can just run the daemon and CLI without having to specify any flags. We make sure to separate out data by network so we don't conflict anywhere and accidentally lose anything important
Create default data directory at ~/.ldk-server
…ll-request/patch Automated nightly rustfmt (2026-01-19)
For most of these I tried to just copy from the proto docs or ldk-node docs, adapting the wording when necessary.
Add help text for all cli commands and args
Add support for bash completions
The load_or_generate_api_key function would fail with "No such file or directory" when the network-specific storage directory didn't exist. This adds fs::create_dir_all() to ensure the directory exists before writing the API key file. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Adds a new endpoint to connect to a peer on the Lightning Network without opening a channel. This is useful for establishing connections before channel operations or for maintaining peer connectivity. The endpoint accepts node_pubkey, address, and a persist flag that indicates whether the peer should be re-connected on restart. Also adds client library and CLI support for the new endpoint. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
…ll-request/patch
- Add ldk-server crates to root workspace - Remove ldk-server's separate workspace Cargo.toml and Cargo.lock - Update ldk-server's ldk-node dependency path to point to root - Move GitHub workflows to root .github/workflows/ - Add per-package release profile settings for ldk-server crates Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
|
👋 Hi! I see this is a draft PR. |
IMO let's avoid this - independent releases of separate crates in the same repo leads to an absolute indecipherable mess - branches for different sub-crates that are out of sync and tags specific to each crate is really hard to follow. I don't see a reason why ldk-server shouldn't just follow a release cadence with ldk node (assuming we do this)? |
|
That's even better. Synchronized releases simplify everything, one tag, one branch, one changelog section per release. Flexibility compounds into friction. It's just that independent releases are possible if needed. |
|
Had similiar reaction as @TheBlueMatt about releases being potentially more complicated. However, if we keep releases in sync with ldk-node that gets rid of most of that worry. Otherwise Concept ACK |
15 participants
Motivation
ldk-server is tightly coupled to ldk-node. Maintaining them as separate repositories creates friction that slows down development without providing meaningful benefits.
Ultimately, I think all three repositories (ldk-node, ldk-server, and rust-lightning) should be merged into a single monorepo. However, bringing ldk-node and ldk-server together first seems like the path of least incremental resistance.
This is a demonstrator branch to show what the merged repository would look like. It also shows that we preserve the full commit history from both repositories.
Benefits
Development efficiency
CI/Testing
Maintenance
What doesn't change
Implementation
Using a Cargo workspace, both crates live as subdirectories with their own
Cargo.toml. Each remains independently publishable with its own version number. The only change is that they now share a repository.