RFC: A Simplified API for LDK

[tnull]

The Lightning Dev Kit is a collection of modules implementing the Lightning protocol that can be used in many different ways. While this allows for a very flexible adoption depending on the user's needs, the number of steps currently required to make use of LDK is pretty high. Hooking up LDK's modules in the right way requires the user not only to have a good understanding of Lightning Network fundamentals, but also to read up and get familiar with LDK quite a bit. Even though we try to provide great resources for that (documentation, tutorials, etc.) and to reduce the potential for error as far as possible, getting everything right is still non-trivial, in particular for a first-time user.

Towards a Simpler API for LDK

In order to make LDK adoption easier and less error prone for users—and in particular for first-time users—we plan to create a new project that wraps LDK's API and provides a reduced and simplified API to get the user started with LDK.

To this end, the ldk-simple-api (name subject to change) project will include a number of opinionated module choices that should allow the user to get started with in very few steps. However, we envision to make these modules somewhat configurable and also aim to provide a smooth transition path for users that eventually outgrow the limited feature set of the simplified API and that therefore want to migrate to the full LDK experience.

As the simplified API neither wants to become the new main API for LDK, nor aims to be a full Lightning node implementation, we're still discussing what sane default functionalities and modules should be included to get the user started and what should be considered out-of-scope for this project.

Currently, we plan to include the following default modules in the initial version:

• Utilizing BDK to implement an on-chain wallet and to access chain data,
  estimate fees, etc. via an Electrum server (e.g. Blockstream)
• Persisting channel state to local disk
• Networking via the operating system's TCP stack
• Path-finding/scoring/probing via LDK's default implementations.

Supported Platforms and Language Bindings

We aim to initially provide support for Desktop, iOS, and Android build targets, and to enable running in browsers eventually. Furthermore, we plan to provide bindings for a broad range of languages. To this end, we'll explore using Mozilla's UniFFI which should help us support Kotlin, Swift, Python and Ruby to get us started. From there, we will see how we can create support for JavaScript, ReactNative, and potentially also Flutter/Dart.

Initial API Design

The API we envision aims to be as simple and as minimal as possible for two main reasons:

• We want to make using LDK very easy for (first-time) users.
• We want to support a broad range of languages, and a small set of exposed API
  methods allows us to potentially write and update some of the bindings by hand.

To this end, the initial API design will likely look something like the following mock-up:

// Single struct instantiates necessary LDK and BDK modules.
struct LdkLite;

impl LdkLite {
	new() -> Self;
	
	// Query to get our own node id
	pub my_node_id(&self) -> NodeId;

	// Connect to a node and open a new channel. Disconnects and re-connects should be handled automatically
	pub connect_open_channel(&mut self, node_id: PublicKey, node_address: NetAddress) -> Result<u64>;

	// Close a previously opened channel
	pub close_channel(&mut self, channel_id: u64) -> Result<()>;

	// Pay an invoice
	pub send_payment(&mut self, invoice: Invoice) -> Result<PaymentId>

	// Send a spontaneous, aka. "keysend", payment 
	pub send_spontaneous_payment(&mut self, amount: u64, node_id: PublicKey) -> Result<PaymentId>;

	// Create an invoice to receive a payment
	pub receive_payment(&mut self, amount: Option<u64>) -> Invoice;

	// Get a new on-chain/funding address.
	pub new_funding_address(&mut self) -> Address;

	// Query for information about payment status.
	pub payment_info(&mut self) -> PaymentInfo;

	// Query for information about our channels
	pub channel_info(&mut self) -> ChannelInfo;

	// Query for information about our on-chain/funding status.
	pub funding_info(&mut self) -> FundingInfo;
}

// Structs wrapping the particular information which should easily be
// understandable, parseable, and transformable, i.e., we'll try to avoid
// exposing too many technical detail here.
struct PaymentInfo;
struct ChannelInfo;
struct FundingInfo;

Request for Comments

As all this is not only work in progress, but it's main purpose is to make users' lives easier, we'd love to get feedback from the LDK community. In particular, but in no particular order:

• Do you think the chosen default modules make sense?
• Do you think you'd immediately miss something in this reduced API?
• Would you be interested in using this? If so, do you have any particular needs regarding language or platform support?
• Do you have general comments regarding 'drawing the line' here? What should or should not be part of this?

I'm really looking forward to your feedback and comments. After a first round of general feedback I'll advance this process and will open a corresponding repository with a PR in which we can focus on the specifics and technical details of the initial API.

[TheBlueMatt]

pub connect_open_channel(&mut self, node_id: PublicKey, node_address: NetAddress) -> Result<(), Error>;

While it would substantially complexify the bindings, I do wonder if we can return futures for a few of these methods. open_channel generally ~always succeeds, and then fails later when the peer responds saying "no, i want a bigger balance" or whatever. Same goes for sending payments - we kick it off but it can take some time to complete (or fail). Sadly a simple future class that supports anything other than only polling may be too complicated for uniffi, but it does have some basic trait support so maybe its doable?

pub close_channel(&mut self, node_id: PublicKey) -> Result<()>;

Dont we need a channel_id here?

Do you think you'd immediately miss something in this reduced API?

payment history. In "full LDK" we don't track this and expect users to, but I imagine "simplifed API" users where we're handling the on-chain wallet as well really ideally just want us to keep history and everything for them. It wouldn't be too hard to include sqlite and just keep payment history in it, no?

[tnull]

While it would substantially complexify the bindings, I do wonder if we can return futures for a few of these methods. open_channel generally ~always succeeds, and then fails later when the peer responds saying "no, i want a bigger balance" or whatever. Same goes for sending payments - we kick it off but it can take some time to complete (or fail). Sadly a simple future class that supports anything other than only polling may be too complicated for uniffi, but it does have some basic trait support so maybe its doable?

Yikes, so far my plan was to not do this async, but simply let the user block on these calls until they succeed. Returning Rust Futures into other language contexts sounds nightmarish to impossible. I know PyO3 tries something like this for Python (see https://pyo3.rs/v0.13.2/ecosystem/async-await.html), but good luck getting this to work in every single language, especially since I'd argue we'd really want to at least try to move towards automatic binding generation with this.

Dont we need a channel_id here?

Ah, right, I'll add that right away.

payment history. In "full LDK" we don't track this and expect users to, but I imagine "simplifed API" users where we're handling the on-chain wallet as well really ideally just want us to keep history and everything for them. It wouldn't be too hard to include sqlite and just keep payment history in it, no?

Yes, the idea here was to return data on recent payments with the PaymentInfo struct and possibly let the user dig deeper into the past. So far I had not thought what the backend for a full history would be, but sqlite is probably a good contender to start with.

[AnthonyRonning]

"so far my plan was to not do this async, but simply let the user block on these calls until they succeed."

+1 on this IMO. Blocking until succeed or fail is really beneficial for simplicity's sake. That said, I imagine most of these need to return a Result<Something, Error>, where Something is like a preimage for successfully paid payments and error is something meaningful for the user to act on. Other than that, looks good to me.

[tnull]

That said, I imagine most of these need to return a Result<Something, Error>, where Something is like a preimage for successfully paid payments and error is something meaningful for the user to act on.

Thanks, ah, good point. Yes, more than likely all methods above will return some kind of Result.

[TheBlueMatt]

Returning Rust Futures into other language contexts sounds nightmarish to impossible.

I mean, it wouldn't be that bad, no, futures are a really dead-simple interface - poll and a notify callback. I dunno if it'd be practical with uni-ffi, though I imagine it could be. Still, mapping those to native futures in other languages sounds like it could be hard.

That said, these methods can block for a long time, so I'm a bit dubious of outright blocking on them - in many languages (JavaScript, Android without some effort to get it off the main thread, etc) blocking isn't an option. Even if we don't go the futures route, we should maybe have some kind of simpler Future, eg return an ID representing the thing happening and let users poll to see what the latest state of it is, with a method on said object to block until completion.

[tnull]

Yes, I still have to work out how we could expose some form of events to the user. I don't think we want to hand LDK's events through, but maybe a simple ticketing/event queue could allow us to notify the user and could replace the need for (native) futures.

[thunderbiscuit]

Hi there. I think a simplified API is a really interesting idea. As a dev fairly new to lightning, I did struggle with getting my node working (currently building in Kotlin). I did get awesome help in the Discord server however, so that's been really helpful.

When I think of the lightning-related "tasks" I want to perform as a developer of some simple app or bot or whatever, here is what I have in mind:

1. On-chain related transactions/wallet
2. Connecting to peers
3. Opening channels
4. Sending payments
5. Receiving payments
6. Closing channels

Looking at your mock code above this seems to fit the bill fairly well. The only things I'm curious about are (a) is the on-chain wallet handled completely internally in this ldk-simple-api, and (b) it appears I won't be able to connect to peers without opening channels with them; that probably makes things simpler, but is there a downside to that? (just wondering).

[tnull]

Hi there. I think a simplified API is a really interesting idea. As a dev fairly new to lightning, I did struggle with getting my node working (currently building in Kotlin). I did get awesome help in the Discord server however, so that's been really helpful.

Great to hear! :)

(a) is the on-chain wallet handled completely internally in this ldk-simple-api

Yes, the plan so far is to use and wrap BDK's wallet interface to setup an on-chain wallet and here provide simple API support for the two central functionalities: generate a new funding address to receive on-chain funds and withdraw to another on-chain address.

(b) it appears I won't be able to connect to peers without opening channels with them; that probably makes things simpler, but is there a downside to that?

I don't think there should be a downside to that. Though, internally we may opt to create additional connections to improve network connectivity. We will probably also want to include support for the rapid-gossip-sync crate to enable fast retrieval of gossip data.

[thunderbiscuit]

Just FYI we're keeping track of issues for APIs that would be required for LDK/BDK compatibility in the FFI layer here.

These would allow for our language bindings in BDK to work with the "full" LDK, but of course LdkLite might not need them if they're all performed on the Rust side (in fact I assume you might not use the BDK language bindings at all in this scenario for the Lite version of the API).

[tnull]

Thanks, will have a look! But I agree these issues likely do not match our case, because we'd do everything on the Rust side.

[jkczyz]

Yes, the plan so far is to use and wrap BDK's wallet interface to setup an on-chain wallet and here provide simple API support for the two central functionalities: generate a new funding address to receive on-chain funds and withdraw to another on-chain address.

Is the purpose of wrapping the BDK wallet to limit the interface exposed for bindings? Would it be useful / possible to simply have the interface be parameterized by the wallet so users can have a single on-chain wallet in their app?

[tnull]

Is the purpose of wrapping the BDK wallet to limit the interface exposed for bindings? Would it be useful / possible to simply have the interface be parameterized by the wallet so users can have a single on-chain wallet in their app?

Good point regarding the single on-chain wallet. We should definitely explore ways to allow users to do that. However, I'll probably leave it out of the first version since I assume BYOW (bring your own wallet) could introduce quite some complexity to the interface.

[G8XSU]

Nit, Proposed name: LdkLite 🍺 , it implies there is more extensible lib available not just a more complex one :)

Api's

Do we support batch operations ?

pub close_channel(&mut self, node_id: PublicKey, channel_id: u64) -> Result<()>;

• Doesn't channel_id uniquely identify a channel? Do we need node_id as well?

Query Api's

Do payment_info() and channel_info() need any identifiers to query upon ?

Safe out of the box

I think one of the goals apart from making it very easy to use, should be to make it safe and secure to use.
And persistence to local disk, doesn't seem really safe for clients to use out of the box.
To save user from unintended costly mistake:

• Is their a possibility of providing native cloud support for common providers using plug-ins?
• Should we enforce clients to inject simple KVStore implementation?

Configurable

While we provide default modules, will they still be injectable ?

Supported Platforms and Language Bindings

Not applicable to desktop, iOS, and android, but does it make sense to support server-mode along with bindings support?
LDK java and typescript bindings are in beta/alpha. how safe is application level gc-language support using bindings to run as server?

[TheBlueMatt]

Doesn't channel_id uniquely identify a channel? Do we need node_id as well?

Only post-funding. Pre-funding it does not, but I suppose if we are returning futures or blocking until acceptance we can simply hide that from users and return the channel_id only after funding.

However, as this may require quite some work

Notably, we need fsync() which I don't believe most native mobile cloud APIs have support for :(

While we provide default modules, will they still be injectable ?

In a totally ideal world I think we'd write a LdkLite wrapper in all of the various languages we support, with the same interface, and tell users to start by forking it and then they can tweak everything to their heart's desire. Sadly we don't have an army of monkeys to build and maintain such a sprawling set of wrappers. Given we may go a different language-bindings-direction with LdkLite, I think making the various modules injectable is going to be kinda challenging - we can certainly provide a module or two (ie just KV-store), but getting into the full API will probably never be practical. I agree we need to do it on a case-by-case basis and be pretty conservative here to retain maintainability.

[jkczyz]

Doesn't channel_id uniquely identify a channel? Do we need node_id as well?

Only post-funding. Pre-funding it does not, but I suppose if we are returning futures or blocking until acceptance we can simply hide that from users and return the channel_id only after funding.

Doesn't closing the channel now require both node_id and channel_id?

[G8XSU]

I don't think so: LDK already allows users to implement their own solutions for a variety of different functionalities (storage, networking, randomness, etc.) which is very powerful but is also the reason why getting it running can be a quite a barrier. I think in this simplified API we'd want to put together an opinionated selection of implementations and config choices that should provide most first-time users with a solid ready-to-go solution.

I agree but I don't think we need to go to another extreme, as for a backend dev providing KVStore impl is fairly simple, whereas for other modules one might have to get their hands dirty.

I think making the various modules injectable is going to be kinda challenging - we can certainly provide a module or two (ie just KV-store)

Yes, the request was to decide it per module, and definitely support providing custom KVStore(i don't think others are as simple to implement).
I believe without customizable KVStore, the functionality would be significantly limited and not built for real use. I am considering device storage as highly unreliable.

@ConorOkus Photon

Photon seems like a react wallet lib, I don't think it solves for this problem. Photon server does just key storage and private key backup afaiu. I meant support for storage solutions for channel state, channel manager state etc.
I wanted to consider providing default impl with popular cloud providers or evaluate how difficult it is to maintain 2-3 KVStore impl in separate crate. So that clients can just provide some config and get running.

what exactly you mean with 'injectable'?

I meant dependency injection pattern

Payment History

The idea so far was that the return structs provide overall information on the state of payments or channels. Methods to query for specific information will however likely become needed, especially if we want to keep track of the full payment history. Then the PaymentInfo would only store information on the N most-recent payments, and for more we'd need to write a getter for a specific PaymentId.

Is providing payment history absolutely necessary ? It introduces additional service dependencies, adds significant complexity. Moreover, i don't think we should own this functionality.
Clients should be maintaining payment history on their own. Let me know what are our thoughts on this.
Instead, should we provide channel status or query against particular paymentId which could potentially be served using existing key-value storage?

[G8XSU]

Regarding PaymentHistory, discussed the need for client's to have payment history in meeting.
On further understanding, proposed kvstore as replaceable module and payment history as "add-on module".

Enables:

1. Custom LN state storage solution
2. Custom payment history and also an option to skip payment history altogether along with its relevant dependencies.

Something like:

LdkLite.default().build()

LdkLite.default()
.paymentHistoryService(PaymentHistoryService)
.build()

LdkLite.default()
.kvStore(KVStore)
.paymentHistoryService(PaymentHistoryService)
.build()

// LDKLite Main Api doesn't have payment history related api's 
// PaymentHistoryService will have api's related to that functionality.

PaymentHistoryService.listPayments(startFrom, PAGE_SIZE)
PaymentHistoryService.getPaymentById(paymentId)

[moneyball]

Do you think payment history should be stored in the cloud? In the same cloud server as LN state?

[wpaulino]

pub close_channel(&mut self, channel_id: u64) -> Result<()>;

Will this force close the channel if it cannot be closed cooperatively?

Relatedly, once we have anchors support, channel closing will require onchain funds to be present. The commitment/HTLC fee bumping should all be abstracted away from the user of course, but the requirement still holds.

[tnull]

Will this force close the channel if it cannot be closed cooperatively?

Good question. I'm not too sure how we should handle that. Probably we would escalate that to a force close after some timeout?

Relatedly, once we have anchors support, channel closing will require onchain funds to be present. The commitment/HTLC fee bumping should all be abstracted away from the user of course, but the requirement still holds.

Right, thanks for the heads up. IIUC, this is not that different from before, but now also the party that did not initiate the close would need some funds?

[jkczyz]

struct LdkSimpleApi;

Will there be a safe shutdown procedure? Presumably, RAII would handle it?

impl LdkSimpleApi {

I'd imagine a user may want to know their own node_id?

	new() -> Self;

Is there any configuration parameters we may want to expose? Or will v1 use a default util::UserConfig?

	// Connect to a node and open a new channel. Disconnects and re-connects should be handled automatically
	pub connect_open_channel(&mut self, node_id: PublicKey, node_address: NetAddress) -> Result<u64>;

May have touched on this offline, but how will inbound open_channel requests be handled?

	// Get a new on-chain/funding address.
	pub new_funding_address(&mut self) -> Address;

When would a user need to call this if LdkSimpleApi is managing channel opens? Or is it simply to expose the wallet functionality so two on-chain wallets aren't needed?

	// Query for information about payment status.
	pub payment_info(&mut self) -> PaymentInfo;

	// Query for information about our channels
	pub channel_info(&mut self) -> ChannelInfo;

	// Query for information about our on-chain/funding status.
	pub funding_info(&mut self) -> FundingInfo;

Do these take parameters in order to return a single instance of a payment/channel or do they return a Vec of all of them?

// Structs wrapping the particular information which should easily be
// understandable, parseable, and transformable, i.e., we'll try to avoid
// exposing too many technical detail here.
struct PaymentInfo;
struct ChannelInfo;
struct FundingInfo;

Just thought, we could make this a bit more object-oriented. For instance, have:

    pub channels(&self) -> Vec<Channel>;

where Channel has a close method (or two). Likewise, connect_open_channel could return a Result<Channel>. Channel itself would have a reference to ChannelManager and enough information to delegate to it.

Otherwise, it seems like having node_id and channel_id in the higher-level interface is exposing too much lower-level detail. Or at least makes the interface more error prone. Might be fine to have them as informational methods on Channel, though.

[tnull]

Will there be a safe shutdown procedure? Presumably, RAII would handle it?

Yes, I'll at least try to let it be handled on Drop.

I'd imagine a user may want to know their own node_id?

Ah, yes, this would likely be useful.

Is there any configuration parameters we may want to expose? Or will v1 use a default util::UserConfig?

I think I'll generally stick with defaults and will make things configurable when there is concrete user demand for it, in order to keep the API minimal. That said, I'll now probably either expose with_xyz constructors or follow a builder pattern to make some modules exchangeable from the getgo.

May have touched on this offline, but how will inbound open_channel requests be handled?

I'll very likely implement an event queue, which then would yield a new event for such incoming requests.

When would a user need to call this if LdkSimpleApi is managing channel opens? Or is it simply to expose the wallet functionality so two on-chain wallets aren't needed?

Well I assume the user needs to get the on-chain wallet funded in some way to begin with?

Do these take parameters in order to return a single instance of a payment/channel or do they return a Vec of all of them?

So far my thought was that the *Info structs would expose collected information on a higher level and then I may add further methods that allow the user to look up additional information on a particular channel/payment/etc.

Just thought, we could make this a bit more object-oriented. For instance, have:

    pub channels(&self) -> Vec<Channel>;

where Channel has a close method (or two). Likewise, connect_open_channel could return a Result<Channel>. Channel itself would have a reference to ChannelManager and enough information to delegate to it.

Otherwise, it seems like having node_id and channel_id in the higher-level interface is exposing too much lower-level detail. Or at least makes the interface more error prone. Might be fine to have them as informational methods on Channel, though.

Mh, I see the utility of this approach and that it could also resolve the question how to 'drill down' to get more specific information. I'm however hesitant to go that route because I tried so far to center the API around the main struct and keep the set of 'objects' rather minimal, especially those that kind of mirror types already present in LDK.

[jkczyz]

Well I assume the user needs to get the on-chain wallet funded in some way to begin with?

Right, I had been assuming the BDK wallet may be exposed somehow if we are being opinionated on having one on-chain wallet. But I suppose that is not necessarily the case if someone wants to bring their own.

[TheBlueMatt]

Yes, I'll at least try to let it be handled on Drop.

Good point, @jkczyz - that may not map super well in lots of application designs, we should consider having a "stop" method, I think.

[danielgranhao]

As I said on Discord, something like this would be very useful for the project I'm working on. The idea is to deploy LDK in Android and iOS using native dev, and I would love to avoid having 2 separate code bases for the LDK and BDK integration logic.

I have some specific needs regarding pathfinding and persistence, so allowing customisation from the get-go would be awesome if possible :)

[moneyball]

Even if we get Ruby "for free" I do not think we should claim support for it, as I've never heard of a single developer demanding it. Whereas Flutter/Dart should absolutely be part of the plan (as opposed to "potentially") given the known demand for it.

[devrandom]

Just noting that depending on a single Electrum server is a bigger security deal with Lightning than it is with Bitcoin wallets.

[moneyball]

Can you elaborate?

Mobile wallets essentially have 3 choices:

1. Connect to a trusted server running Core
2. Use Electrum
   a. using a specific server
   b. randomly choosing servers
3. Use compact block filters

I assume security is similar for 1 and 2a. 3 is better but has performance tradeoffs.

[devrandom]

stating the obvious, the security model of Lightning is sensitive to eclipse / Sybil.

when an "enterprise" node operator runs a node, they presumably connect to their own bitcoind (or electrum backed by bitcoind), which connects to random places in the network and is therefore hopefully resistant to eclipse.

a mobile node likely connects to bitcoind / electrum that is controlled by someone else. if it connects to a single such server, then it has basically no protection against eclipse.

so I would say best practice should be to connect to multiple block sources and the LDK API / mobile samples should encourage that.

BTW, what are the performance tradeoffs for 3 that you were thinking of? is the concern that downloading CFs from multiple sources is wasting bandwidth? if so, then encouraging independent entities to sign CFs would solve that (and that's the direction VLS wants to go in).

[moneyball]

I'm aware of no mobile wallets that currently use multiple block sources to improve security. I agree this is a good future direction. I don't agree it is a priority for the simplified API. Many more basic things to get right first. I mean we're still at a point where it is non-trivial for a developer to just get a BASIC wallet up and running...

As for performance tradeoff of 3, I'm referring to downloading CBFs. It is on the order of 3-6MB/day of data. If a user doesn't open their wallet for weeks, they might have to download dozens of MB of data when they open the app, causing many (dozens?) seconds delay. For some users they might also have to pay extra money for this data. I personally want to see at least one serious mobile wallet attempt to use CBFs so we can see how good we can make it, but it is unproven.

[moneyball]

Pretty sure I've commented on this elsewhere, but I don't see a comment in this discussion. I feel strongly there needs to be a version of this Lite API which uses the forthcoming LSP spec and completely hides all channel management details from the user of this API. An app should be able to use the API to send and receive bitcoin and have no idea about under the hood the opening and closing of channels and rebalancing of channels. It just magically happens for the app.

Do we agree? If so, are we imagining once the LSP API is available, we'll write the code that glues this API to that API, obviating the need for a user to call open or close channel? And in the dev docs really being clear that open/close channel are "power user portions of the simplified API"?

[tanx]

Thanks again for the overview of LDK/LdkLite yesterday @moneyball and @TheBlueMatt. I agree it would be desirable to have channel management be as hidden as possible and not necessary to send and receive payments. I would imagine configuring the LSP via a URI and then having the library handle as much as possible. Although it would likely be desirable to have access to channel management (maybe behind an optional api) if that's required later.

The question remains how opinionated the api is wrt the architecture. For the non-custodial wallet planned for the Swan mobile app I envision a single balance / lightning only architecture similar to Breez. The wallet would be funded by the user by receiving a lightning payment at which point a 0-conf channel is opened from the LSP to the mobile node. On-chain transactions into and out of the channel could happen via submarine swaps.

Once we have async receive and send (via the upcoming "hold HTLC in sender LSP spec") this type of architecture would provide a very similar UX to on-chain wallets. Maybe we could even use unified QR codes to completely hide Lightning from the user.

Backup of the seed and channel state could happen via Photon.

But these are just some thoughts of the architecture I imagine would enable the best UX. Not sure it would be too opinionated of an API for LdkLite though. Would love feedback on this. Thanks :)

[danielnordh]

"An app should be able to use the API to send and receive bitcoin and have no idea about under the hood the opening and closing of channels and rebalancing of channels. It just magically happens for the app."

Yes please!

As someone trying to build a mobile 'Daily spending wallet' for beginners, I have quickly realized that the UX we want is not possible without a server component. Ideally the 'LSP standard' being worked on would sprout several compatible providers that I as a developer can opt to use with my mobile code.

So specifying a URL to an LSP provider when initializing ldk-lite, and then being able to do (in common language) would be fantastic:

• generate request, compatible with lightning and onchain sends (with or without current channels)
• send to lightning or onchain address (with or without current channels)