Implement first set of Api's by G8XSU · Pull Request #5 · lightningdevkit/ldk-server

G8XSU · 2024-09-05T03:59:20Z

Adds implementation for:

CloseChannel Api
Bolt12Send Api
Bolt12Receive Api
Bolt11Send Api
OpenChannel Api
BOLT11Receive Api
OnchainSend Api
OnchainReceive Api

Based on #2

tnull · 2024-09-09T08:32:17Z

This needs a rebase now.

tnull · 2024-09-11T09:03:49Z

+	node: Arc<Node>, request: OnchainSendRequest,
+) -> Result<OnchainSendResponse, ldk_node::NodeError> {
+	let address = Address::from_str(&request.address)
+ .map_err(|_| ldk_node::NodeError::InvalidAddress)?


Should we import NodeError to avoid the prefix?

I kept it to make it explicit when there are other error types floating around, specifically ldk-server specific.
But I dont mind it either way.

tnull · 2024-09-11T09:05:32Z

+) -> Result<OnchainSendResponse, ldk_node::NodeError> {
+	let address = Address::from_str(&request.address)
+ .map_err(|_| ldk_node::NodeError::InvalidAddress)?
+ .require_network(node.config().network)


I wonder if it would be worth retrieving the Config once and then giving a &Config to the handler methods rather than always calling in? Would at least avoid cloning it every time.

Not all api's need it, and there could be future such instances where a subset of api's need some field.
I think we shouldn't add it to common handler for now.

tnull · 2024-09-11T09:07:49Z

+
+pub(crate) fn handle_onchain_send_request(
+	node: Arc<Node>, request: OnchainSendRequest,
+) -> Result<OnchainSendResponse, ldk_node::NodeError> {


Might be fine for the intial step, but we might need to introduce a separate error type that wraps the NodeError, i.e., will be a superset?

Yeah currently it is only for initial step, will probably spend more time on error handling when we have it in api interface.

tnull · 2024-09-11T09:24:29Z

+ request.announce_channel,
+	)?;
+	let response =
+ OpenChannelResponse { user_channel_id: user_channel_id.0.to_be_bytes().to_vec() };


I wonder if it would be worth down the line defining some kind of de/ser traits to make sure the encoding from these types into their respective field types is always consistent and we can't accidentally, e.g., encode as little-endian in some places?

tnull · 2024-09-11T09:29:07Z

+pub(crate) fn handle_close_channel_request(
+	node: Arc<Node>, request: CloseChannelRequest,
+) -> Result<CloseChannelResponse, ldk_node::NodeError> {
+	//TODO: Should this be string?


IMO, since PaymentId is its dedicated proto type, UserChannelId/ChannelId, etc. should probably also follow the same pattern?

@tnull @jkczyz
The main problem is user interaction with these byte identifiers, for which I could use some ideas. Essentially, IDs such as ChannelId, UserChannelId, and PaymentId are not human-readable in byte form and cannot be easily input or output as bytes.
Using bytes is fine for programmatic access, but for CLI or while interacting with a lightning node through a UI, this isn't really feasible. We have a similar problem for the logs of these IDs as well. (See: lightningdevkit/rust-lightning#3306)
In my opinion, we need a standardized way of interacting with these in a human-friendly manner, not just for debug logs. For this, I was considering whether we can use a hex representation string in the interface. This could be just for the CLI/UI or as part of the main API interface.

Mhh, I don't have a strong opinion, but I do think it should be uniform, at least across all *Id types.

I thought more about this,
I don't think adding separate types for *Id helps from API perspective. It just introduces further nesting of types.
It might make sense in ldk-node api to introduce special types where you can have type checking but not in an api.
{ payment_id :PaymentId{data:[..]}, user_channel_id: UserChannelId{data:[..]}, channel_id: ChannelId{data:[..]}, } compared to: { payment_id :[..], user_channel_id: [..], channel_id: [..], } Bolt11SendResponse { payment_id: Some(PaymentId { data: payment_id.0.to_vec() }) } compared to Bolt11SendResponse { payment_id: payment_id.0.to_vec() }
So to make it uniform, I am thinking of removing PaymentId type itself.

So to make it uniform, I am thinking of removing PaymentId type itself.
Alright, fine by me as long as it's uniform and ~predictable by the user/dev so they don't have to look up every single detail in the docs when using the API. And, at this stage, we could still easily change anything if we find a reason why we need separate types in the future.
Feel free to add the commit dropping PaymentId here before we land this.

Yes added a commit for it.
Squashed and rebased.

G8XSU · 2024-09-16T20:12:27Z

@tnull Is there any additional feedback on this?

tnull

@tnull Is there any additional feedback on this?

Not really, but we should probably come to a conclusion on #5 (comment) and #5 (comment) before we move on?

Besides that, feel free to interleave and squash the fixups into their respective commits.

tnull · 2024-09-17T10:57:52Z

-use crate::api::onchain_send::*;
-use crate::api::open_channel::*;
+use crate::api::bolt11_receive::handle_bolt11_receive_request;
+use crate::api::bolt11_receive::BOLT11_RECEIVE_PATH;


nit: Could group the imports from each module, but doesn't matter too much.

G8XSU · 2024-09-25T05:05:48Z

Squashed.
Need to rebase.

G8XSU · 2024-09-25T05:21:06Z

Squashed and rebased.

Implement first set of Api's

G8XSU · 2024-09-05T03:59:20Z

Adds implementation for:

CloseChannel Api
Bolt12Send Api
Bolt12Receive Api
Bolt11Send Api
OpenChannel Api
BOLT11Receive Api
OnchainSend Api
OnchainReceive Api

Based on #2

tnull · 2024-09-09T08:32:17Z

This needs a rebase now.

tnull · 2024-09-11T09:03:49Z

+	node: Arc<Node>, request: OnchainSendRequest,
+) -> Result<OnchainSendResponse, ldk_node::NodeError> {
+	let address = Address::from_str(&request.address)
+ .map_err(|_| ldk_node::NodeError::InvalidAddress)?


Should we import NodeError to avoid the prefix?

I kept it to make it explicit when there are other error types floating around, specifically ldk-server specific.
But I dont mind it either way.

tnull · 2024-09-11T09:05:32Z

+) -> Result<OnchainSendResponse, ldk_node::NodeError> {
+	let address = Address::from_str(&request.address)
+ .map_err(|_| ldk_node::NodeError::InvalidAddress)?
+ .require_network(node.config().network)


I wonder if it would be worth retrieving the Config once and then giving a &Config to the handler methods rather than always calling in? Would at least avoid cloning it every time.

Not all api's need it, and there could be future such instances where a subset of api's need some field.
I think we shouldn't add it to common handler for now.

tnull · 2024-09-11T09:07:49Z

+
+pub(crate) fn handle_onchain_send_request(
+	node: Arc<Node>, request: OnchainSendRequest,
+) -> Result<OnchainSendResponse, ldk_node::NodeError> {


Might be fine for the intial step, but we might need to introduce a separate error type that wraps the NodeError, i.e., will be a superset?

Yeah currently it is only for initial step, will probably spend more time on error handling when we have it in api interface.

tnull · 2024-09-11T09:24:29Z

+ request.announce_channel,
+	)?;
+	let response =
+ OpenChannelResponse { user_channel_id: user_channel_id.0.to_be_bytes().to_vec() };


I wonder if it would be worth down the line defining some kind of de/ser traits to make sure the encoding from these types into their respective field types is always consistent and we can't accidentally, e.g., encode as little-endian in some places?

tnull · 2024-09-11T09:29:07Z

+pub(crate) fn handle_close_channel_request(
+	node: Arc<Node>, request: CloseChannelRequest,
+) -> Result<CloseChannelResponse, ldk_node::NodeError> {
+	//TODO: Should this be string?


IMO, since PaymentId is its dedicated proto type, UserChannelId/ChannelId, etc. should probably also follow the same pattern?

@tnull @jkczyz
The main problem is user interaction with these byte identifiers, for which I could use some ideas. Essentially, IDs such as ChannelId, UserChannelId, and PaymentId are not human-readable in byte form and cannot be easily input or output as bytes.
Using bytes is fine for programmatic access, but for CLI or while interacting with a lightning node through a UI, this isn't really feasible. We have a similar problem for the logs of these IDs as well. (See: lightningdevkit/rust-lightning#3306)
In my opinion, we need a standardized way of interacting with these in a human-friendly manner, not just for debug logs. For this, I was considering whether we can use a hex representation string in the interface. This could be just for the CLI/UI or as part of the main API interface.

Mhh, I don't have a strong opinion, but I do think it should be uniform, at least across all *Id types.

I thought more about this,
I don't think adding separate types for *Id helps from API perspective. It just introduces further nesting of types.
It might make sense in ldk-node api to introduce special types where you can have type checking but not in an api.
{ payment_id :PaymentId{data:[..]}, user_channel_id: UserChannelId{data:[..]}, channel_id: ChannelId{data:[..]}, } compared to: { payment_id :[..], user_channel_id: [..], channel_id: [..], } Bolt11SendResponse { payment_id: Some(PaymentId { data: payment_id.0.to_vec() }) } compared to Bolt11SendResponse { payment_id: payment_id.0.to_vec() }
So to make it uniform, I am thinking of removing PaymentId type itself.

So to make it uniform, I am thinking of removing PaymentId type itself.
Alright, fine by me as long as it's uniform and ~predictable by the user/dev so they don't have to look up every single detail in the docs when using the API. And, at this stage, we could still easily change anything if we find a reason why we need separate types in the future.
Feel free to add the commit dropping PaymentId here before we land this.

Yes added a commit for it.
Squashed and rebased.

G8XSU · 2024-09-16T20:12:27Z

@tnull Is there any additional feedback on this?

tnull

@tnull Is there any additional feedback on this?

Not really, but we should probably come to a conclusion on #5 (comment) and #5 (comment) before we move on?

Besides that, feel free to interleave and squash the fixups into their respective commits.

tnull · 2024-09-17T10:57:52Z

-use crate::api::onchain_send::*;
-use crate::api::open_channel::*;
+use crate::api::bolt11_receive::handle_bolt11_receive_request;
+use crate::api::bolt11_receive::BOLT11_RECEIVE_PATH;


nit: Could group the imports from each module, but doesn't matter too much.

G8XSU · 2024-09-25T05:05:48Z

Squashed.
Need to rebase.

G8XSU · 2024-09-25T05:21:06Z

Squashed and rebased.

Implement first set of Api's

G8XSU · 2024-09-05T03:59:20Z

Adds implementation for:

CloseChannel Api
Bolt12Send Api
Bolt12Receive Api
Bolt11Send Api
OpenChannel Api
BOLT11Receive Api
OnchainSend Api
OnchainReceive Api

Based on #2

tnull · 2024-09-09T08:32:17Z

This needs a rebase now.

tnull · 2024-09-11T09:03:49Z

+	node: Arc<Node>, request: OnchainSendRequest,
+) -> Result<OnchainSendResponse, ldk_node::NodeError> {
+	let address = Address::from_str(&request.address)
+ .map_err(|_| ldk_node::NodeError::InvalidAddress)?


Should we import NodeError to avoid the prefix?

I kept it to make it explicit when there are other error types floating around, specifically ldk-server specific.
But I dont mind it either way.

tnull · 2024-09-11T09:05:32Z

+) -> Result<OnchainSendResponse, ldk_node::NodeError> {
+	let address = Address::from_str(&request.address)
+ .map_err(|_| ldk_node::NodeError::InvalidAddress)?
+ .require_network(node.config().network)


I wonder if it would be worth retrieving the Config once and then giving a &Config to the handler methods rather than always calling in? Would at least avoid cloning it every time.

Not all api's need it, and there could be future such instances where a subset of api's need some field.
I think we shouldn't add it to common handler for now.

tnull · 2024-09-11T09:07:49Z

+
+pub(crate) fn handle_onchain_send_request(
+	node: Arc<Node>, request: OnchainSendRequest,
+) -> Result<OnchainSendResponse, ldk_node::NodeError> {


Might be fine for the intial step, but we might need to introduce a separate error type that wraps the NodeError, i.e., will be a superset?

Yeah currently it is only for initial step, will probably spend more time on error handling when we have it in api interface.

tnull · 2024-09-11T09:24:29Z

+ request.announce_channel,
+	)?;
+	let response =
+ OpenChannelResponse { user_channel_id: user_channel_id.0.to_be_bytes().to_vec() };


I wonder if it would be worth down the line defining some kind of de/ser traits to make sure the encoding from these types into their respective field types is always consistent and we can't accidentally, e.g., encode as little-endian in some places?

tnull · 2024-09-11T09:29:07Z

+pub(crate) fn handle_close_channel_request(
+	node: Arc<Node>, request: CloseChannelRequest,
+) -> Result<CloseChannelResponse, ldk_node::NodeError> {
+	//TODO: Should this be string?


IMO, since PaymentId is its dedicated proto type, UserChannelId/ChannelId, etc. should probably also follow the same pattern?

@tnull @jkczyz
The main problem is user interaction with these byte identifiers, for which I could use some ideas. Essentially, IDs such as ChannelId, UserChannelId, and PaymentId are not human-readable in byte form and cannot be easily input or output as bytes.
Using bytes is fine for programmatic access, but for CLI or while interacting with a lightning node through a UI, this isn't really feasible. We have a similar problem for the logs of these IDs as well. (See: lightningdevkit/rust-lightning#3306)
In my opinion, we need a standardized way of interacting with these in a human-friendly manner, not just for debug logs. For this, I was considering whether we can use a hex representation string in the interface. This could be just for the CLI/UI or as part of the main API interface.

Mhh, I don't have a strong opinion, but I do think it should be uniform, at least across all *Id types.

I thought more about this,
I don't think adding separate types for *Id helps from API perspective. It just introduces further nesting of types.
It might make sense in ldk-node api to introduce special types where you can have type checking but not in an api.
{ payment_id :PaymentId{data:[..]}, user_channel_id: UserChannelId{data:[..]}, channel_id: ChannelId{data:[..]}, } compared to: { payment_id :[..], user_channel_id: [..], channel_id: [..], } Bolt11SendResponse { payment_id: Some(PaymentId { data: payment_id.0.to_vec() }) } compared to Bolt11SendResponse { payment_id: payment_id.0.to_vec() }
So to make it uniform, I am thinking of removing PaymentId type itself.

So to make it uniform, I am thinking of removing PaymentId type itself.
Alright, fine by me as long as it's uniform and ~predictable by the user/dev so they don't have to look up every single detail in the docs when using the API. And, at this stage, we could still easily change anything if we find a reason why we need separate types in the future.
Feel free to add the commit dropping PaymentId here before we land this.

Yes added a commit for it.
Squashed and rebased.

G8XSU · 2024-09-16T20:12:27Z

@tnull Is there any additional feedback on this?

tnull

@tnull Is there any additional feedback on this?

Not really, but we should probably come to a conclusion on #5 (comment) and #5 (comment) before we move on?

Besides that, feel free to interleave and squash the fixups into their respective commits.

tnull · 2024-09-17T10:57:52Z

-use crate::api::onchain_send::*;
-use crate::api::open_channel::*;
+use crate::api::bolt11_receive::handle_bolt11_receive_request;
+use crate::api::bolt11_receive::BOLT11_RECEIVE_PATH;


nit: Could group the imports from each module, but doesn't matter too much.

G8XSU · 2024-09-25T05:05:48Z

Squashed.
Need to rebase.

G8XSU · 2024-09-25T05:21:06Z

Squashed and rebased.

Implement first set of Api's

G8XSU · 2024-09-05T03:59:20Z

Adds implementation for:

CloseChannel Api
Bolt12Send Api
Bolt12Receive Api
Bolt11Send Api
OpenChannel Api
BOLT11Receive Api
OnchainSend Api
OnchainReceive Api

Based on #2

tnull · 2024-09-09T08:32:17Z

This needs a rebase now.

tnull · 2024-09-11T09:03:49Z

+	node: Arc<Node>, request: OnchainSendRequest,
+) -> Result<OnchainSendResponse, ldk_node::NodeError> {
+	let address = Address::from_str(&request.address)
+ .map_err(|_| ldk_node::NodeError::InvalidAddress)?


Should we import NodeError to avoid the prefix?

I kept it to make it explicit when there are other error types floating around, specifically ldk-server specific.
But I dont mind it either way.

tnull · 2024-09-11T09:05:32Z

+) -> Result<OnchainSendResponse, ldk_node::NodeError> {
+	let address = Address::from_str(&request.address)
+ .map_err(|_| ldk_node::NodeError::InvalidAddress)?
+ .require_network(node.config().network)


I wonder if it would be worth retrieving the Config once and then giving a &Config to the handler methods rather than always calling in? Would at least avoid cloning it every time.

Not all api's need it, and there could be future such instances where a subset of api's need some field.
I think we shouldn't add it to common handler for now.

tnull · 2024-09-11T09:07:49Z

+
+pub(crate) fn handle_onchain_send_request(
+	node: Arc<Node>, request: OnchainSendRequest,
+) -> Result<OnchainSendResponse, ldk_node::NodeError> {


Might be fine for the intial step, but we might need to introduce a separate error type that wraps the NodeError, i.e., will be a superset?

Yeah currently it is only for initial step, will probably spend more time on error handling when we have it in api interface.

tnull · 2024-09-11T09:24:29Z

+ request.announce_channel,
+	)?;
+	let response =
+ OpenChannelResponse { user_channel_id: user_channel_id.0.to_be_bytes().to_vec() };


I wonder if it would be worth down the line defining some kind of de/ser traits to make sure the encoding from these types into their respective field types is always consistent and we can't accidentally, e.g., encode as little-endian in some places?

tnull · 2024-09-11T09:29:07Z

+pub(crate) fn handle_close_channel_request(
+	node: Arc<Node>, request: CloseChannelRequest,
+) -> Result<CloseChannelResponse, ldk_node::NodeError> {
+	//TODO: Should this be string?


IMO, since PaymentId is its dedicated proto type, UserChannelId/ChannelId, etc. should probably also follow the same pattern?

@tnull @jkczyz
The main problem is user interaction with these byte identifiers, for which I could use some ideas. Essentially, IDs such as ChannelId, UserChannelId, and PaymentId are not human-readable in byte form and cannot be easily input or output as bytes.
Using bytes is fine for programmatic access, but for CLI or while interacting with a lightning node through a UI, this isn't really feasible. We have a similar problem for the logs of these IDs as well. (See: lightningdevkit/rust-lightning#3306)
In my opinion, we need a standardized way of interacting with these in a human-friendly manner, not just for debug logs. For this, I was considering whether we can use a hex representation string in the interface. This could be just for the CLI/UI or as part of the main API interface.

Mhh, I don't have a strong opinion, but I do think it should be uniform, at least across all *Id types.

I thought more about this,
I don't think adding separate types for *Id helps from API perspective. It just introduces further nesting of types.
It might make sense in ldk-node api to introduce special types where you can have type checking but not in an api.
{ payment_id :PaymentId{data:[..]}, user_channel_id: UserChannelId{data:[..]}, channel_id: ChannelId{data:[..]}, } compared to: { payment_id :[..], user_channel_id: [..], channel_id: [..], } Bolt11SendResponse { payment_id: Some(PaymentId { data: payment_id.0.to_vec() }) } compared to Bolt11SendResponse { payment_id: payment_id.0.to_vec() }
So to make it uniform, I am thinking of removing PaymentId type itself.

So to make it uniform, I am thinking of removing PaymentId type itself.
Alright, fine by me as long as it's uniform and ~predictable by the user/dev so they don't have to look up every single detail in the docs when using the API. And, at this stage, we could still easily change anything if we find a reason why we need separate types in the future.
Feel free to add the commit dropping PaymentId here before we land this.

Yes added a commit for it.
Squashed and rebased.

G8XSU · 2024-09-16T20:12:27Z

@tnull Is there any additional feedback on this?

tnull

@tnull Is there any additional feedback on this?

Not really, but we should probably come to a conclusion on #5 (comment) and #5 (comment) before we move on?

Besides that, feel free to interleave and squash the fixups into their respective commits.

tnull · 2024-09-17T10:57:52Z

-use crate::api::onchain_send::*;
-use crate::api::open_channel::*;
+use crate::api::bolt11_receive::handle_bolt11_receive_request;
+use crate::api::bolt11_receive::BOLT11_RECEIVE_PATH;


nit: Could group the imports from each module, but doesn't matter too much.

G8XSU · 2024-09-25T05:05:48Z

Squashed.
Need to rebase.

G8XSU · 2024-09-25T05:21:06Z

Squashed and rebased.

Implement first set of Api's

G8XSU · 2024-09-05T03:59:20Z

Adds implementation for:

CloseChannel Api
Bolt12Send Api
Bolt12Receive Api
Bolt11Send Api
OpenChannel Api
BOLT11Receive Api
OnchainSend Api
OnchainReceive Api

Based on #2

tnull · 2024-09-09T08:32:17Z

This needs a rebase now.

tnull · 2024-09-11T09:03:49Z

+	node: Arc<Node>, request: OnchainSendRequest,
+) -> Result<OnchainSendResponse, ldk_node::NodeError> {
+	let address = Address::from_str(&request.address)
+ .map_err(|_| ldk_node::NodeError::InvalidAddress)?


Should we import NodeError to avoid the prefix?

I kept it to make it explicit when there are other error types floating around, specifically ldk-server specific.
But I dont mind it either way.

tnull · 2024-09-11T09:05:32Z

+) -> Result<OnchainSendResponse, ldk_node::NodeError> {
+	let address = Address::from_str(&request.address)
+ .map_err(|_| ldk_node::NodeError::InvalidAddress)?
+ .require_network(node.config().network)


I wonder if it would be worth retrieving the Config once and then giving a &Config to the handler methods rather than always calling in? Would at least avoid cloning it every time.

Not all api's need it, and there could be future such instances where a subset of api's need some field.
I think we shouldn't add it to common handler for now.

tnull · 2024-09-11T09:07:49Z

+
+pub(crate) fn handle_onchain_send_request(
+	node: Arc<Node>, request: OnchainSendRequest,
+) -> Result<OnchainSendResponse, ldk_node::NodeError> {


Might be fine for the intial step, but we might need to introduce a separate error type that wraps the NodeError, i.e., will be a superset?

Yeah currently it is only for initial step, will probably spend more time on error handling when we have it in api interface.

tnull · 2024-09-11T09:24:29Z

+ request.announce_channel,
+	)?;
+	let response =
+ OpenChannelResponse { user_channel_id: user_channel_id.0.to_be_bytes().to_vec() };


I wonder if it would be worth down the line defining some kind of de/ser traits to make sure the encoding from these types into their respective field types is always consistent and we can't accidentally, e.g., encode as little-endian in some places?

tnull · 2024-09-11T09:29:07Z

+pub(crate) fn handle_close_channel_request(
+	node: Arc<Node>, request: CloseChannelRequest,
+) -> Result<CloseChannelResponse, ldk_node::NodeError> {
+	//TODO: Should this be string?


IMO, since PaymentId is its dedicated proto type, UserChannelId/ChannelId, etc. should probably also follow the same pattern?

@tnull @jkczyz
The main problem is user interaction with these byte identifiers, for which I could use some ideas. Essentially, IDs such as ChannelId, UserChannelId, and PaymentId are not human-readable in byte form and cannot be easily input or output as bytes.
Using bytes is fine for programmatic access, but for CLI or while interacting with a lightning node through a UI, this isn't really feasible. We have a similar problem for the logs of these IDs as well. (See: lightningdevkit/rust-lightning#3306)
In my opinion, we need a standardized way of interacting with these in a human-friendly manner, not just for debug logs. For this, I was considering whether we can use a hex representation string in the interface. This could be just for the CLI/UI or as part of the main API interface.

Mhh, I don't have a strong opinion, but I do think it should be uniform, at least across all *Id types.

I thought more about this,
I don't think adding separate types for *Id helps from API perspective. It just introduces further nesting of types.
It might make sense in ldk-node api to introduce special types where you can have type checking but not in an api.
{ payment_id :PaymentId{data:[..]}, user_channel_id: UserChannelId{data:[..]}, channel_id: ChannelId{data:[..]}, } compared to: { payment_id :[..], user_channel_id: [..], channel_id: [..], } Bolt11SendResponse { payment_id: Some(PaymentId { data: payment_id.0.to_vec() }) } compared to Bolt11SendResponse { payment_id: payment_id.0.to_vec() }
So to make it uniform, I am thinking of removing PaymentId type itself.

So to make it uniform, I am thinking of removing PaymentId type itself.
Alright, fine by me as long as it's uniform and ~predictable by the user/dev so they don't have to look up every single detail in the docs when using the API. And, at this stage, we could still easily change anything if we find a reason why we need separate types in the future.
Feel free to add the commit dropping PaymentId here before we land this.

Yes added a commit for it.
Squashed and rebased.

G8XSU · 2024-09-16T20:12:27Z

@tnull Is there any additional feedback on this?

tnull

@tnull Is there any additional feedback on this?

Not really, but we should probably come to a conclusion on #5 (comment) and #5 (comment) before we move on?

Besides that, feel free to interleave and squash the fixups into their respective commits.

tnull · 2024-09-17T10:57:52Z

-use crate::api::onchain_send::*;
-use crate::api::open_channel::*;
+use crate::api::bolt11_receive::handle_bolt11_receive_request;
+use crate::api::bolt11_receive::BOLT11_RECEIVE_PATH;


nit: Could group the imports from each module, but doesn't matter too much.

G8XSU · 2024-09-25T05:05:48Z

Squashed.
Need to rebase.

G8XSU · 2024-09-25T05:21:06Z

Squashed and rebased.

Implement first set of Api's

G8XSU · 2024-09-05T03:59:20Z

Adds implementation for:

CloseChannel Api
Bolt12Send Api
Bolt12Receive Api
Bolt11Send Api
OpenChannel Api
BOLT11Receive Api
OnchainSend Api
OnchainReceive Api

Based on #2

tnull · 2024-09-09T08:32:17Z

This needs a rebase now.

tnull · 2024-09-11T09:03:49Z

+	node: Arc<Node>, request: OnchainSendRequest,
+) -> Result<OnchainSendResponse, ldk_node::NodeError> {
+	let address = Address::from_str(&request.address)
+ .map_err(|_| ldk_node::NodeError::InvalidAddress)?


Should we import NodeError to avoid the prefix?

I kept it to make it explicit when there are other error types floating around, specifically ldk-server specific.
But I dont mind it either way.

tnull · 2024-09-11T09:05:32Z

+) -> Result<OnchainSendResponse, ldk_node::NodeError> {
+	let address = Address::from_str(&request.address)
+ .map_err(|_| ldk_node::NodeError::InvalidAddress)?
+ .require_network(node.config().network)


I wonder if it would be worth retrieving the Config once and then giving a &Config to the handler methods rather than always calling in? Would at least avoid cloning it every time.

Not all api's need it, and there could be future such instances where a subset of api's need some field.
I think we shouldn't add it to common handler for now.

tnull · 2024-09-11T09:07:49Z

+
+pub(crate) fn handle_onchain_send_request(
+	node: Arc<Node>, request: OnchainSendRequest,
+) -> Result<OnchainSendResponse, ldk_node::NodeError> {


Might be fine for the intial step, but we might need to introduce a separate error type that wraps the NodeError, i.e., will be a superset?

Yeah currently it is only for initial step, will probably spend more time on error handling when we have it in api interface.

tnull · 2024-09-11T09:24:29Z

+ request.announce_channel,
+	)?;
+	let response =
+ OpenChannelResponse { user_channel_id: user_channel_id.0.to_be_bytes().to_vec() };


I wonder if it would be worth down the line defining some kind of de/ser traits to make sure the encoding from these types into their respective field types is always consistent and we can't accidentally, e.g., encode as little-endian in some places?

tnull · 2024-09-11T09:29:07Z

+pub(crate) fn handle_close_channel_request(
+	node: Arc<Node>, request: CloseChannelRequest,
+) -> Result<CloseChannelResponse, ldk_node::NodeError> {
+	//TODO: Should this be string?


IMO, since PaymentId is its dedicated proto type, UserChannelId/ChannelId, etc. should probably also follow the same pattern?

@tnull @jkczyz
The main problem is user interaction with these byte identifiers, for which I could use some ideas. Essentially, IDs such as ChannelId, UserChannelId, and PaymentId are not human-readable in byte form and cannot be easily input or output as bytes.
Using bytes is fine for programmatic access, but for CLI or while interacting with a lightning node through a UI, this isn't really feasible. We have a similar problem for the logs of these IDs as well. (See: lightningdevkit/rust-lightning#3306)
In my opinion, we need a standardized way of interacting with these in a human-friendly manner, not just for debug logs. For this, I was considering whether we can use a hex representation string in the interface. This could be just for the CLI/UI or as part of the main API interface.

Mhh, I don't have a strong opinion, but I do think it should be uniform, at least across all *Id types.

I thought more about this,
I don't think adding separate types for *Id helps from API perspective. It just introduces further nesting of types.
It might make sense in ldk-node api to introduce special types where you can have type checking but not in an api.
{ payment_id :PaymentId{data:[..]}, user_channel_id: UserChannelId{data:[..]}, channel_id: ChannelId{data:[..]}, } compared to: { payment_id :[..], user_channel_id: [..], channel_id: [..], } Bolt11SendResponse { payment_id: Some(PaymentId { data: payment_id.0.to_vec() }) } compared to Bolt11SendResponse { payment_id: payment_id.0.to_vec() }
So to make it uniform, I am thinking of removing PaymentId type itself.

So to make it uniform, I am thinking of removing PaymentId type itself.
Alright, fine by me as long as it's uniform and ~predictable by the user/dev so they don't have to look up every single detail in the docs when using the API. And, at this stage, we could still easily change anything if we find a reason why we need separate types in the future.
Feel free to add the commit dropping PaymentId here before we land this.

Yes added a commit for it.
Squashed and rebased.

G8XSU · 2024-09-16T20:12:27Z

@tnull Is there any additional feedback on this?

tnull

@tnull Is there any additional feedback on this?

Not really, but we should probably come to a conclusion on #5 (comment) and #5 (comment) before we move on?

Besides that, feel free to interleave and squash the fixups into their respective commits.

tnull · 2024-09-17T10:57:52Z

-use crate::api::onchain_send::*;
-use crate::api::open_channel::*;
+use crate::api::bolt11_receive::handle_bolt11_receive_request;
+use crate::api::bolt11_receive::BOLT11_RECEIVE_PATH;


nit: Could group the imports from each module, but doesn't matter too much.

G8XSU · 2024-09-25T05:05:48Z

Squashed.
Need to rebase.

G8XSU · 2024-09-25T05:21:06Z

Squashed and rebased.

Implement first set of Api's

G8XSU · 2024-09-05T03:59:20Z

Adds implementation for:

CloseChannel Api
Bolt12Send Api
Bolt12Receive Api
Bolt11Send Api
OpenChannel Api
BOLT11Receive Api
OnchainSend Api
OnchainReceive Api

Based on #2

tnull · 2024-09-09T08:32:17Z

This needs a rebase now.

tnull · 2024-09-11T09:03:49Z

+	node: Arc<Node>, request: OnchainSendRequest,
+) -> Result<OnchainSendResponse, ldk_node::NodeError> {
+	let address = Address::from_str(&request.address)
+ .map_err(|_| ldk_node::NodeError::InvalidAddress)?


Should we import NodeError to avoid the prefix?

I kept it to make it explicit when there are other error types floating around, specifically ldk-server specific.
But I dont mind it either way.

tnull · 2024-09-11T09:05:32Z

+) -> Result<OnchainSendResponse, ldk_node::NodeError> {
+	let address = Address::from_str(&request.address)
+ .map_err(|_| ldk_node::NodeError::InvalidAddress)?
+ .require_network(node.config().network)


I wonder if it would be worth retrieving the Config once and then giving a &Config to the handler methods rather than always calling in? Would at least avoid cloning it every time.

Not all api's need it, and there could be future such instances where a subset of api's need some field.
I think we shouldn't add it to common handler for now.

tnull · 2024-09-11T09:07:49Z

+
+pub(crate) fn handle_onchain_send_request(
+	node: Arc<Node>, request: OnchainSendRequest,
+) -> Result<OnchainSendResponse, ldk_node::NodeError> {


Might be fine for the intial step, but we might need to introduce a separate error type that wraps the NodeError, i.e., will be a superset?

Yeah currently it is only for initial step, will probably spend more time on error handling when we have it in api interface.

tnull · 2024-09-11T09:24:29Z

+ request.announce_channel,
+	)?;
+	let response =
+ OpenChannelResponse { user_channel_id: user_channel_id.0.to_be_bytes().to_vec() };


I wonder if it would be worth down the line defining some kind of de/ser traits to make sure the encoding from these types into their respective field types is always consistent and we can't accidentally, e.g., encode as little-endian in some places?

tnull · 2024-09-11T09:29:07Z

+pub(crate) fn handle_close_channel_request(
+	node: Arc<Node>, request: CloseChannelRequest,
+) -> Result<CloseChannelResponse, ldk_node::NodeError> {
+	//TODO: Should this be string?


IMO, since PaymentId is its dedicated proto type, UserChannelId/ChannelId, etc. should probably also follow the same pattern?

@tnull @jkczyz
The main problem is user interaction with these byte identifiers, for which I could use some ideas. Essentially, IDs such as ChannelId, UserChannelId, and PaymentId are not human-readable in byte form and cannot be easily input or output as bytes.
Using bytes is fine for programmatic access, but for CLI or while interacting with a lightning node through a UI, this isn't really feasible. We have a similar problem for the logs of these IDs as well. (See: lightningdevkit/rust-lightning#3306)
In my opinion, we need a standardized way of interacting with these in a human-friendly manner, not just for debug logs. For this, I was considering whether we can use a hex representation string in the interface. This could be just for the CLI/UI or as part of the main API interface.

Mhh, I don't have a strong opinion, but I do think it should be uniform, at least across all *Id types.

I thought more about this,
I don't think adding separate types for *Id helps from API perspective. It just introduces further nesting of types.
It might make sense in ldk-node api to introduce special types where you can have type checking but not in an api.
{ payment_id :PaymentId{data:[..]}, user_channel_id: UserChannelId{data:[..]}, channel_id: ChannelId{data:[..]}, } compared to: { payment_id :[..], user_channel_id: [..], channel_id: [..], } Bolt11SendResponse { payment_id: Some(PaymentId { data: payment_id.0.to_vec() }) } compared to Bolt11SendResponse { payment_id: payment_id.0.to_vec() }
So to make it uniform, I am thinking of removing PaymentId type itself.

So to make it uniform, I am thinking of removing PaymentId type itself.
Alright, fine by me as long as it's uniform and ~predictable by the user/dev so they don't have to look up every single detail in the docs when using the API. And, at this stage, we could still easily change anything if we find a reason why we need separate types in the future.
Feel free to add the commit dropping PaymentId here before we land this.

Yes added a commit for it.
Squashed and rebased.

G8XSU · 2024-09-16T20:12:27Z

@tnull Is there any additional feedback on this?

tnull

@tnull Is there any additional feedback on this?

Not really, but we should probably come to a conclusion on #5 (comment) and #5 (comment) before we move on?

Besides that, feel free to interleave and squash the fixups into their respective commits.

tnull · 2024-09-17T10:57:52Z

-use crate::api::onchain_send::*;
-use crate::api::open_channel::*;
+use crate::api::bolt11_receive::handle_bolt11_receive_request;
+use crate::api::bolt11_receive::BOLT11_RECEIVE_PATH;


nit: Could group the imports from each module, but doesn't matter too much.

G8XSU · 2024-09-25T05:05:48Z

Squashed.
Need to rebase.

G8XSU · 2024-09-25T05:21:06Z

Squashed and rebased.

Implement first set of Api's

G8XSU · 2024-09-05T03:59:20Z

Adds implementation for:

CloseChannel Api
Bolt12Send Api
Bolt12Receive Api
Bolt11Send Api
OpenChannel Api
BOLT11Receive Api
OnchainSend Api
OnchainReceive Api

Based on #2

tnull · 2024-09-09T08:32:17Z

This needs a rebase now.

tnull · 2024-09-11T09:03:49Z

+	node: Arc<Node>, request: OnchainSendRequest,
+) -> Result<OnchainSendResponse, ldk_node::NodeError> {
+	let address = Address::from_str(&request.address)
+ .map_err(|_| ldk_node::NodeError::InvalidAddress)?


Should we import NodeError to avoid the prefix?

I kept it to make it explicit when there are other error types floating around, specifically ldk-server specific.
But I dont mind it either way.

tnull · 2024-09-11T09:05:32Z

+) -> Result<OnchainSendResponse, ldk_node::NodeError> {
+	let address = Address::from_str(&request.address)
+ .map_err(|_| ldk_node::NodeError::InvalidAddress)?
+ .require_network(node.config().network)


I wonder if it would be worth retrieving the Config once and then giving a &Config to the handler methods rather than always calling in? Would at least avoid cloning it every time.

Not all api's need it, and there could be future such instances where a subset of api's need some field.
I think we shouldn't add it to common handler for now.

tnull · 2024-09-11T09:07:49Z

+
+pub(crate) fn handle_onchain_send_request(
+	node: Arc<Node>, request: OnchainSendRequest,
+) -> Result<OnchainSendResponse, ldk_node::NodeError> {


Might be fine for the intial step, but we might need to introduce a separate error type that wraps the NodeError, i.e., will be a superset?

Yeah currently it is only for initial step, will probably spend more time on error handling when we have it in api interface.

tnull · 2024-09-11T09:24:29Z

+ request.announce_channel,
+	)?;
+	let response =
+ OpenChannelResponse { user_channel_id: user_channel_id.0.to_be_bytes().to_vec() };


I wonder if it would be worth down the line defining some kind of de/ser traits to make sure the encoding from these types into their respective field types is always consistent and we can't accidentally, e.g., encode as little-endian in some places?

tnull · 2024-09-11T09:29:07Z

+pub(crate) fn handle_close_channel_request(
+	node: Arc<Node>, request: CloseChannelRequest,
+) -> Result<CloseChannelResponse, ldk_node::NodeError> {
+	//TODO: Should this be string?


IMO, since PaymentId is its dedicated proto type, UserChannelId/ChannelId, etc. should probably also follow the same pattern?

@tnull @jkczyz
The main problem is user interaction with these byte identifiers, for which I could use some ideas. Essentially, IDs such as ChannelId, UserChannelId, and PaymentId are not human-readable in byte form and cannot be easily input or output as bytes.
Using bytes is fine for programmatic access, but for CLI or while interacting with a lightning node through a UI, this isn't really feasible. We have a similar problem for the logs of these IDs as well. (See: lightningdevkit/rust-lightning#3306)
In my opinion, we need a standardized way of interacting with these in a human-friendly manner, not just for debug logs. For this, I was considering whether we can use a hex representation string in the interface. This could be just for the CLI/UI or as part of the main API interface.

Mhh, I don't have a strong opinion, but I do think it should be uniform, at least across all *Id types.

I thought more about this,
I don't think adding separate types for *Id helps from API perspective. It just introduces further nesting of types.
It might make sense in ldk-node api to introduce special types where you can have type checking but not in an api.
{ payment_id :PaymentId{data:[..]}, user_channel_id: UserChannelId{data:[..]}, channel_id: ChannelId{data:[..]}, } compared to: { payment_id :[..], user_channel_id: [..], channel_id: [..], } Bolt11SendResponse { payment_id: Some(PaymentId { data: payment_id.0.to_vec() }) } compared to Bolt11SendResponse { payment_id: payment_id.0.to_vec() }
So to make it uniform, I am thinking of removing PaymentId type itself.

So to make it uniform, I am thinking of removing PaymentId type itself.
Alright, fine by me as long as it's uniform and ~predictable by the user/dev so they don't have to look up every single detail in the docs when using the API. And, at this stage, we could still easily change anything if we find a reason why we need separate types in the future.
Feel free to add the commit dropping PaymentId here before we land this.

Yes added a commit for it.
Squashed and rebased.

G8XSU · 2024-09-16T20:12:27Z

@tnull Is there any additional feedback on this?

tnull

@tnull Is there any additional feedback on this?

Not really, but we should probably come to a conclusion on #5 (comment) and #5 (comment) before we move on?

Besides that, feel free to interleave and squash the fixups into their respective commits.

tnull · 2024-09-17T10:57:52Z

-use crate::api::onchain_send::*;
-use crate::api::open_channel::*;
+use crate::api::bolt11_receive::handle_bolt11_receive_request;
+use crate::api::bolt11_receive::BOLT11_RECEIVE_PATH;


nit: Could group the imports from each module, but doesn't matter too much.

G8XSU · 2024-09-25T05:05:48Z

Squashed.
Need to rebase.

G8XSU · 2024-09-25T05:21:06Z

Squashed and rebased.

Implement first set of Api's

G8XSU changed the title ~~[Draft Pr] Implement first set of Api's~~Implement first set of Api'sSep 10, 2024

G8XSU requested a review from tnull September 10, 2024 22:12

tnull reviewed Sep 11, 2024
View reviewed changes

G8XSU requested a review from tnull September 16, 2024 20:12

tnull reviewed Sep 17, 2024
View reviewed changes

G8XSU added 9 commits September 25, 2024 14:07

Remove PaymentId as separate type from api.
0485c7a

Add Impl for OnchainReceive Api
f57637d

Add Impl for OnchainSend Api
ba60e59

Add Impl for BOLT11Receive Api
d4295c8

Add Impl for OpenChannel Api
70fb33d

Add Impl for Bolt11Send Api
41eaa1b

Add Impl for Bolt12Receive Api
ac90b8f

Add Impl for Bolt12Send Api
e63d1ae

Add Impl for CloseChannel Api
92d3361

G8XSU requested a review from tnull September 25, 2024 05:20

tnull approved these changes Sep 25, 2024
View reviewed changes

tnull merged commit 1d702ed into lightningdevkit:mainSep 25, 2024

G8XSU mentioned this pull request Oct 14, 2024
Ldk-Server Milestone 2 #10
Closed
13 tasks

joostjager mentioned this pull request Mar 28, 2026
Replace REST and RabbitMQ with gRPC #176
Merged

rsafier pushed a commit to rsafier/ldk-server that referenced this pull request Apr 20, 2026
Merge pull requestlightningdevkit#5from G8XSU/impl-s1-apis
8ca65d1
Implement first set of Api's