Expose Kotlin/Swift bindings for lightning-transactions-sync crate

[henghonglee]

Building a mobile application for ios and android currently require Kotlin/Swift bindings to be generated from the main rust-lightning crates.

the current bindings workflow generates all the public interfaces of all the LDK core crates, and its up to the mobile developer to splice them together, this is challenging and requires alot of context around how LDK should be set up for proper non-custodial setup. doing it wrongly also might result in loss of funds.

in recent times, newer rust-lightning crates such as lightning-transactions-sync have been created to wire more ready-to-go pieces together. lightning-transaction-sync crates includes wiring up esplora client and ldk main, to create a set of primitives that can be used to create non-custodial lightning mobile applications quickly and fairly easily.

Currently, also we do have ldk-node bindings from the ldk-node project, however those include a more opinionated and heavily abstracted system where most of the wiring and feature choices have already been selected and set. such as using BDK wallet to sync transactions broadcasting instead of bitcoin core

Developers may need more flexibility, (like selecting their sync/async or electrum/esplora etc)and could do with having more control over the features that are selected from the mid-level abstraction crates like lightning-transaction-sync

This task is to generate bindings for lightning-transactions-sync in the same way LDK is generated currently through ldk-c-bindings, ldk-garbagecollected and ldk-swift

Blocking this task

• [ ] MSRV considerations?

Steps

• [ ] figure out how to generate bindings with changes on the rust-lightning library (or wait for 0.116 bindings from matt)
• [ ] make changes to ldk-c-bindings (Cargo.toml and genbindings.sh) to include generating c bindings for lightning-transactions-sync crate
  • [ ] this might include finding out the new MSRV with potentially new http/tls libraries that have lower MSRV limits
• [ ] generate garbagecollected and swift bindings
• [ ] ??

[tnull]

Building a mobile application for ios and android currently require Kotlin/Swift bindings to be generated from the main rust-lightning crates.

Note that rust-lightning technically provides Java bindings, which however may be used from Kotlin.

the current bindings workflow generates all the public interfaces of all the LDK core crates, and its up to the mobile developer to splice them together, this is challenging and requires alot of context around how LDK should be set up for proper non-custodial setup. doing it wrongly also might result in loss of funds.

This is mostly correct, although a few things are not exported. Watch out for This is not exported to bindings users comments in the Rust docs.

in recent times, newer rust-lightning crates such as lightning-transactions-sync have been created to wire more ready-to-go pieces together. lightning-transaction-sync crates includes wiring up bdk wallet, esplora client and ldk main, to create a set of primitives that can be used to create non-custodial lightning mobile applications quickly and fairly easily.

No, lightning-transaction-sync as of today only syncs the LDK wallet via the Confirm interface against an Esplora backend, no BDK on-chain wallet is included/synced.

Currently, also we do have ldk-node bindings from the ldk-node project, however those include a more opinionated and heavily abstracted system where most of the wiring and feature choices have already been selected and set.

Developers may need more flexibility, (like selecting their sync/async or electrum/esplora etc)and could do with having more control over the features that are selected from the mid-level abstraction crates like lightning-transaction-sync

This task is to generate bindings for lightning-transactions-sync in the same way LDK is generated currently through ldk-c-bindings, ldk-garbagecollected and ldk-swift

Yes, it should be exposed via these projects, just as any other LDK features.

Blocking this task [ ] MSRV considerations? [ ] ...?

Yes, it's currently mostly blocked on MSRV considerations. In the short term we might slightly bump our MSRV to get started, but that doesn't solve the longer-term issue of HTTP/TLS clients taking too many dependencies that constantly push the MSRV boundaries. To solve this a lot more work might be required, i.e., switch to (in this regard) saner HTTP / TLS libraries, even if it means implementing some of the missing features on our own.

[henghonglee]

No, lightning-transaction-sync as of today only syncs the LDK wallet via the Confirm interface against an Esplora backend, no BDK on-chain wallet is included/synced.

ah yes, thats right. also i think it should be the Filter interface against esplora updated

In the short term we might slightly bump our MSRV to get started, but that doesn't solve the longer-term issue of HTTP/TLS clients taking too many dependencies that constantly push the MSRV boundaries. To solve this a lot more work might be required, i.e., switch to (in this regard) saner HTTP / TLS libraries, even if it means implementing some of the missing features on our own.

got it

[TheBlueMatt]

In the short term we might slightly bump our MSRV to get started

Let's definitely focus on this for now. I think the immediate goal is to allow HTTP calls to be hooked by a trait. We need to chat with BDK as to whether they will accept a patch for this to their esplora-client that we use, or otherwise we can just drop that and make the HTTP calls directly (which would be pretty trivial). Once we have that in place, we'll have to think about how to handle async but we can work on that once we have the trait in place.

[tnull]

Let's definitely focus on this for now. I think the immediate goal is to allow HTTP calls to be hooked by a trait. We need to chat with BDK as to whether they will accept a patch for this to their esplora-client that we use

Already spoke to them, they'd be open for a PR that creates a new optional feature once we figured out which HTTP lib to use (which is on my TODO list).

[TheBlueMatt]

This wouldn't be switching HTTP libs but rather having a hook. For now that hook probably lives in BDK, but we could definitely switch it to living elsewhere, just need to decide.