Extend API to allow invoice creation with a description hash by joostjager · Pull Request #438 · lightningdevkit/ldk-node

joostjager · 2025-01-21T15:03:53Z

tnull

Thanks! Looks pretty good, but I think we can clean it up a bit further if we follow the approach of #434. Let me know if I should tackle that in a follow-up though!

tnull · 2025-01-23T14:19:30Z

+
+/// Represents the description of an invoice which has to be either a directly included string or
+/// a hash of a description provided out of band.
+pub enum Bolt11InvoiceDescription {


Let's move this type definition to uniffi_types.rs directly.

tnull · 2025-01-23T14:26:26Z

+	#[cfg(not(feature = "uniffi"))]
 	pub fn receive(
- &self, amount_msat: u64, description: &str, expiry_secs: u32,
+ &self, amount_msat: u64, description: &lightning_invoice::Bolt11InvoiceDescription,


I think rather than duplicating all of these, we should be able to follow the same approach as #434, i.e.,
a) add a local type alias
use lightning_invoice::Bolt11InvoiceDescriptionasLdkBolt11InvoiceDescription;#[cfg(not(feature = "uniffi"))]typeBolt11InvoiceDescription = LdkBolt11InvoiceDescription;#[cfg(feature = "uniffi")]typeBolt11InvoiceDescription = crate::uniffi_types::Bolt11InvoiceDescription;
above and have the receives use a macro like this:
macro_rules! maybe_convert_description {($description: expr) => {{ #[cfg(not(feature = "uniffi"))]{ $description } #[cfg(feature = "uniffi")]{&LdkBolt11InvoiceDescription::try_from($description)? }}};}
(could also consider using it in the receive_inner/receive_via_jit_channel_inner, but the former is reused in unified_qr, which complicates things. So probably easier to do the conversion before giving the description to the _inners).

tnull · 2025-01-23T14:30:04Z

 	}

+	#[cfg(feature = "uniffi")]
+	pub fn receive(


I double checked this as it confused me that it be possible to omit docs here. And indeed it doesn't work: note that if you run cargo doc --features uniffi --open, all the receive variants wouldn't have any docs on them.
For non-Uniffi we forbid missing docs on a crate-wide level (see top of lib.rs), but unfortunately we can't do this under the uniffi feature as some of the generated code doesn't have docs on it, which would have the deny(missing_docs) lint fail. This is why we didn't catch the missing docs at build time with the uniffi feature.

tnull · 2025-01-23T15:28:51Z

Feel free to undraft.

tnull · 2025-01-23T15:51:23Z

Flaky python test is pre-existing. Going ahead and landing this.

Add reconversion unit test (#438 followup)

joostjager · 2025-01-21T15:03:53Z

Fixes#325

tnull

Thanks! Looks pretty good, but I think we can clean it up a bit further if we follow the approach of #434. Let me know if I should tackle that in a follow-up though!

tnull · 2025-01-23T14:19:30Z

+
+/// Represents the description of an invoice which has to be either a directly included string or
+/// a hash of a description provided out of band.
+pub enum Bolt11InvoiceDescription {


Let's move this type definition to uniffi_types.rs directly.

tnull · 2025-01-23T14:26:26Z

+	#[cfg(not(feature = "uniffi"))]
 	pub fn receive(
- &self, amount_msat: u64, description: &str, expiry_secs: u32,
+ &self, amount_msat: u64, description: &lightning_invoice::Bolt11InvoiceDescription,


I think rather than duplicating all of these, we should be able to follow the same approach as #434, i.e.,
a) add a local type alias
use lightning_invoice::Bolt11InvoiceDescriptionasLdkBolt11InvoiceDescription;#[cfg(not(feature = "uniffi"))]typeBolt11InvoiceDescription = LdkBolt11InvoiceDescription;#[cfg(feature = "uniffi")]typeBolt11InvoiceDescription = crate::uniffi_types::Bolt11InvoiceDescription;
above and have the receives use a macro like this:
macro_rules! maybe_convert_description {($description: expr) => {{ #[cfg(not(feature = "uniffi"))]{ $description } #[cfg(feature = "uniffi")]{&LdkBolt11InvoiceDescription::try_from($description)? }}};}
(could also consider using it in the receive_inner/receive_via_jit_channel_inner, but the former is reused in unified_qr, which complicates things. So probably easier to do the conversion before giving the description to the _inners).

tnull · 2025-01-23T14:30:04Z

 	}

+	#[cfg(feature = "uniffi")]
+	pub fn receive(


I double checked this as it confused me that it be possible to omit docs here. And indeed it doesn't work: note that if you run cargo doc --features uniffi --open, all the receive variants wouldn't have any docs on them.
For non-Uniffi we forbid missing docs on a crate-wide level (see top of lib.rs), but unfortunately we can't do this under the uniffi feature as some of the generated code doesn't have docs on it, which would have the deny(missing_docs) lint fail. This is why we didn't catch the missing docs at build time with the uniffi feature.

tnull · 2025-01-23T15:28:51Z

Feel free to undraft.

tnull · 2025-01-23T15:51:23Z

Flaky python test is pre-existing. Going ahead and landing this.

Add reconversion unit test (#438 followup)

joostjager · 2025-01-21T15:03:53Z

Fixes#325

tnull

Thanks! Looks pretty good, but I think we can clean it up a bit further if we follow the approach of #434. Let me know if I should tackle that in a follow-up though!

tnull · 2025-01-23T14:19:30Z

+
+/// Represents the description of an invoice which has to be either a directly included string or
+/// a hash of a description provided out of band.
+pub enum Bolt11InvoiceDescription {


Let's move this type definition to uniffi_types.rs directly.

tnull · 2025-01-23T14:26:26Z

+	#[cfg(not(feature = "uniffi"))]
 	pub fn receive(
- &self, amount_msat: u64, description: &str, expiry_secs: u32,
+ &self, amount_msat: u64, description: &lightning_invoice::Bolt11InvoiceDescription,


I think rather than duplicating all of these, we should be able to follow the same approach as #434, i.e.,
a) add a local type alias
use lightning_invoice::Bolt11InvoiceDescriptionasLdkBolt11InvoiceDescription;#[cfg(not(feature = "uniffi"))]typeBolt11InvoiceDescription = LdkBolt11InvoiceDescription;#[cfg(feature = "uniffi")]typeBolt11InvoiceDescription = crate::uniffi_types::Bolt11InvoiceDescription;
above and have the receives use a macro like this:
macro_rules! maybe_convert_description {($description: expr) => {{ #[cfg(not(feature = "uniffi"))]{ $description } #[cfg(feature = "uniffi")]{&LdkBolt11InvoiceDescription::try_from($description)? }}};}
(could also consider using it in the receive_inner/receive_via_jit_channel_inner, but the former is reused in unified_qr, which complicates things. So probably easier to do the conversion before giving the description to the _inners).

tnull · 2025-01-23T14:30:04Z

 	}

+	#[cfg(feature = "uniffi")]
+	pub fn receive(


I double checked this as it confused me that it be possible to omit docs here. And indeed it doesn't work: note that if you run cargo doc --features uniffi --open, all the receive variants wouldn't have any docs on them.
For non-Uniffi we forbid missing docs on a crate-wide level (see top of lib.rs), but unfortunately we can't do this under the uniffi feature as some of the generated code doesn't have docs on it, which would have the deny(missing_docs) lint fail. This is why we didn't catch the missing docs at build time with the uniffi feature.

tnull · 2025-01-23T15:28:51Z

Feel free to undraft.

tnull · 2025-01-23T15:51:23Z

Flaky python test is pre-existing. Going ahead and landing this.

Add reconversion unit test (#438 followup)

joostjager · 2025-01-21T15:03:53Z

Fixes#325

tnull

Thanks! Looks pretty good, but I think we can clean it up a bit further if we follow the approach of #434. Let me know if I should tackle that in a follow-up though!

tnull · 2025-01-23T14:19:30Z

+
+/// Represents the description of an invoice which has to be either a directly included string or
+/// a hash of a description provided out of band.
+pub enum Bolt11InvoiceDescription {


Let's move this type definition to uniffi_types.rs directly.

tnull · 2025-01-23T14:26:26Z

+	#[cfg(not(feature = "uniffi"))]
 	pub fn receive(
- &self, amount_msat: u64, description: &str, expiry_secs: u32,
+ &self, amount_msat: u64, description: &lightning_invoice::Bolt11InvoiceDescription,


I think rather than duplicating all of these, we should be able to follow the same approach as #434, i.e.,
a) add a local type alias
use lightning_invoice::Bolt11InvoiceDescriptionasLdkBolt11InvoiceDescription;#[cfg(not(feature = "uniffi"))]typeBolt11InvoiceDescription = LdkBolt11InvoiceDescription;#[cfg(feature = "uniffi")]typeBolt11InvoiceDescription = crate::uniffi_types::Bolt11InvoiceDescription;
above and have the receives use a macro like this:
macro_rules! maybe_convert_description {($description: expr) => {{ #[cfg(not(feature = "uniffi"))]{ $description } #[cfg(feature = "uniffi")]{&LdkBolt11InvoiceDescription::try_from($description)? }}};}
(could also consider using it in the receive_inner/receive_via_jit_channel_inner, but the former is reused in unified_qr, which complicates things. So probably easier to do the conversion before giving the description to the _inners).

tnull · 2025-01-23T14:30:04Z

 	}

+	#[cfg(feature = "uniffi")]
+	pub fn receive(


I double checked this as it confused me that it be possible to omit docs here. And indeed it doesn't work: note that if you run cargo doc --features uniffi --open, all the receive variants wouldn't have any docs on them.
For non-Uniffi we forbid missing docs on a crate-wide level (see top of lib.rs), but unfortunately we can't do this under the uniffi feature as some of the generated code doesn't have docs on it, which would have the deny(missing_docs) lint fail. This is why we didn't catch the missing docs at build time with the uniffi feature.

tnull · 2025-01-23T15:28:51Z

Feel free to undraft.

tnull · 2025-01-23T15:51:23Z

Flaky python test is pre-existing. Going ahead and landing this.

Add reconversion unit test (#438 followup)

joostjager · 2025-01-21T15:03:53Z

Fixes#325

tnull

Thanks! Looks pretty good, but I think we can clean it up a bit further if we follow the approach of #434. Let me know if I should tackle that in a follow-up though!

tnull · 2025-01-23T14:19:30Z

+
+/// Represents the description of an invoice which has to be either a directly included string or
+/// a hash of a description provided out of band.
+pub enum Bolt11InvoiceDescription {


Let's move this type definition to uniffi_types.rs directly.

tnull · 2025-01-23T14:26:26Z

+	#[cfg(not(feature = "uniffi"))]
 	pub fn receive(
- &self, amount_msat: u64, description: &str, expiry_secs: u32,
+ &self, amount_msat: u64, description: &lightning_invoice::Bolt11InvoiceDescription,


I think rather than duplicating all of these, we should be able to follow the same approach as #434, i.e.,
a) add a local type alias
use lightning_invoice::Bolt11InvoiceDescriptionasLdkBolt11InvoiceDescription;#[cfg(not(feature = "uniffi"))]typeBolt11InvoiceDescription = LdkBolt11InvoiceDescription;#[cfg(feature = "uniffi")]typeBolt11InvoiceDescription = crate::uniffi_types::Bolt11InvoiceDescription;
above and have the receives use a macro like this:
macro_rules! maybe_convert_description {($description: expr) => {{ #[cfg(not(feature = "uniffi"))]{ $description } #[cfg(feature = "uniffi")]{&LdkBolt11InvoiceDescription::try_from($description)? }}};}
(could also consider using it in the receive_inner/receive_via_jit_channel_inner, but the former is reused in unified_qr, which complicates things. So probably easier to do the conversion before giving the description to the _inners).

tnull · 2025-01-23T14:30:04Z

 	}

+	#[cfg(feature = "uniffi")]
+	pub fn receive(


I double checked this as it confused me that it be possible to omit docs here. And indeed it doesn't work: note that if you run cargo doc --features uniffi --open, all the receive variants wouldn't have any docs on them.
For non-Uniffi we forbid missing docs on a crate-wide level (see top of lib.rs), but unfortunately we can't do this under the uniffi feature as some of the generated code doesn't have docs on it, which would have the deny(missing_docs) lint fail. This is why we didn't catch the missing docs at build time with the uniffi feature.

tnull · 2025-01-23T15:28:51Z

Feel free to undraft.

tnull · 2025-01-23T15:51:23Z

Flaky python test is pre-existing. Going ahead and landing this.

Add reconversion unit test (#438 followup)

joostjager · 2025-01-21T15:03:53Z

Fixes#325

tnull

Thanks! Looks pretty good, but I think we can clean it up a bit further if we follow the approach of #434. Let me know if I should tackle that in a follow-up though!

tnull · 2025-01-23T14:19:30Z

+
+/// Represents the description of an invoice which has to be either a directly included string or
+/// a hash of a description provided out of band.
+pub enum Bolt11InvoiceDescription {


Let's move this type definition to uniffi_types.rs directly.

tnull · 2025-01-23T14:26:26Z

+	#[cfg(not(feature = "uniffi"))]
 	pub fn receive(
- &self, amount_msat: u64, description: &str, expiry_secs: u32,
+ &self, amount_msat: u64, description: &lightning_invoice::Bolt11InvoiceDescription,


I think rather than duplicating all of these, we should be able to follow the same approach as #434, i.e.,
a) add a local type alias
use lightning_invoice::Bolt11InvoiceDescriptionasLdkBolt11InvoiceDescription;#[cfg(not(feature = "uniffi"))]typeBolt11InvoiceDescription = LdkBolt11InvoiceDescription;#[cfg(feature = "uniffi")]typeBolt11InvoiceDescription = crate::uniffi_types::Bolt11InvoiceDescription;
above and have the receives use a macro like this:
macro_rules! maybe_convert_description {($description: expr) => {{ #[cfg(not(feature = "uniffi"))]{ $description } #[cfg(feature = "uniffi")]{&LdkBolt11InvoiceDescription::try_from($description)? }}};}
(could also consider using it in the receive_inner/receive_via_jit_channel_inner, but the former is reused in unified_qr, which complicates things. So probably easier to do the conversion before giving the description to the _inners).

tnull · 2025-01-23T14:30:04Z

 	}

+	#[cfg(feature = "uniffi")]
+	pub fn receive(


I double checked this as it confused me that it be possible to omit docs here. And indeed it doesn't work: note that if you run cargo doc --features uniffi --open, all the receive variants wouldn't have any docs on them.
For non-Uniffi we forbid missing docs on a crate-wide level (see top of lib.rs), but unfortunately we can't do this under the uniffi feature as some of the generated code doesn't have docs on it, which would have the deny(missing_docs) lint fail. This is why we didn't catch the missing docs at build time with the uniffi feature.

tnull · 2025-01-23T15:28:51Z

Feel free to undraft.

tnull · 2025-01-23T15:51:23Z

Flaky python test is pre-existing. Going ahead and landing this.

Add reconversion unit test (#438 followup)

joostjager · 2025-01-21T15:03:53Z

Fixes#325

tnull

Thanks! Looks pretty good, but I think we can clean it up a bit further if we follow the approach of #434. Let me know if I should tackle that in a follow-up though!

tnull · 2025-01-23T14:19:30Z

+
+/// Represents the description of an invoice which has to be either a directly included string or
+/// a hash of a description provided out of band.
+pub enum Bolt11InvoiceDescription {


Let's move this type definition to uniffi_types.rs directly.

tnull · 2025-01-23T14:26:26Z

+	#[cfg(not(feature = "uniffi"))]
 	pub fn receive(
- &self, amount_msat: u64, description: &str, expiry_secs: u32,
+ &self, amount_msat: u64, description: &lightning_invoice::Bolt11InvoiceDescription,


I think rather than duplicating all of these, we should be able to follow the same approach as #434, i.e.,
a) add a local type alias
use lightning_invoice::Bolt11InvoiceDescriptionasLdkBolt11InvoiceDescription;#[cfg(not(feature = "uniffi"))]typeBolt11InvoiceDescription = LdkBolt11InvoiceDescription;#[cfg(feature = "uniffi")]typeBolt11InvoiceDescription = crate::uniffi_types::Bolt11InvoiceDescription;
above and have the receives use a macro like this:
macro_rules! maybe_convert_description {($description: expr) => {{ #[cfg(not(feature = "uniffi"))]{ $description } #[cfg(feature = "uniffi")]{&LdkBolt11InvoiceDescription::try_from($description)? }}};}
(could also consider using it in the receive_inner/receive_via_jit_channel_inner, but the former is reused in unified_qr, which complicates things. So probably easier to do the conversion before giving the description to the _inners).

tnull · 2025-01-23T14:30:04Z

 	}

+	#[cfg(feature = "uniffi")]
+	pub fn receive(


I double checked this as it confused me that it be possible to omit docs here. And indeed it doesn't work: note that if you run cargo doc --features uniffi --open, all the receive variants wouldn't have any docs on them.
For non-Uniffi we forbid missing docs on a crate-wide level (see top of lib.rs), but unfortunately we can't do this under the uniffi feature as some of the generated code doesn't have docs on it, which would have the deny(missing_docs) lint fail. This is why we didn't catch the missing docs at build time with the uniffi feature.

tnull · 2025-01-23T15:28:51Z

Feel free to undraft.

tnull · 2025-01-23T15:51:23Z

Flaky python test is pre-existing. Going ahead and landing this.

Add reconversion unit test (#438 followup)

joostjager · 2025-01-21T15:03:53Z

Fixes#325

tnull

Thanks! Looks pretty good, but I think we can clean it up a bit further if we follow the approach of #434. Let me know if I should tackle that in a follow-up though!

tnull · 2025-01-23T14:19:30Z

+
+/// Represents the description of an invoice which has to be either a directly included string or
+/// a hash of a description provided out of band.
+pub enum Bolt11InvoiceDescription {


Let's move this type definition to uniffi_types.rs directly.

tnull · 2025-01-23T14:26:26Z

+	#[cfg(not(feature = "uniffi"))]
 	pub fn receive(
- &self, amount_msat: u64, description: &str, expiry_secs: u32,
+ &self, amount_msat: u64, description: &lightning_invoice::Bolt11InvoiceDescription,


I think rather than duplicating all of these, we should be able to follow the same approach as #434, i.e.,
a) add a local type alias
use lightning_invoice::Bolt11InvoiceDescriptionasLdkBolt11InvoiceDescription;#[cfg(not(feature = "uniffi"))]typeBolt11InvoiceDescription = LdkBolt11InvoiceDescription;#[cfg(feature = "uniffi")]typeBolt11InvoiceDescription = crate::uniffi_types::Bolt11InvoiceDescription;
above and have the receives use a macro like this:
macro_rules! maybe_convert_description {($description: expr) => {{ #[cfg(not(feature = "uniffi"))]{ $description } #[cfg(feature = "uniffi")]{&LdkBolt11InvoiceDescription::try_from($description)? }}};}
(could also consider using it in the receive_inner/receive_via_jit_channel_inner, but the former is reused in unified_qr, which complicates things. So probably easier to do the conversion before giving the description to the _inners).

tnull · 2025-01-23T14:30:04Z

 	}

+	#[cfg(feature = "uniffi")]
+	pub fn receive(


I double checked this as it confused me that it be possible to omit docs here. And indeed it doesn't work: note that if you run cargo doc --features uniffi --open, all the receive variants wouldn't have any docs on them.
For non-Uniffi we forbid missing docs on a crate-wide level (see top of lib.rs), but unfortunately we can't do this under the uniffi feature as some of the generated code doesn't have docs on it, which would have the deny(missing_docs) lint fail. This is why we didn't catch the missing docs at build time with the uniffi feature.

tnull · 2025-01-23T15:28:51Z

Feel free to undraft.

tnull · 2025-01-23T15:51:23Z

Flaky python test is pre-existing. Going ahead and landing this.

Add reconversion unit test (#438 followup)

joostjager force-pushed the invoice-description-hash branch 2 times, most recently from be6be7e to f958924Compare January 21, 2025 15:14

joostjager commented Jan 21, 2025
View reviewed changes

Comment threadsrc/payment/bolt11.rs Outdated

joostjager commented Jan 21, 2025
View reviewed changes

Comment threadsrc/payment/bolt11.rs Outdated

joostjager commented Jan 21, 2025
View reviewed changes

Comment threadbindings/ldk_node.udl Outdated

joostjager force-pushed the invoice-description-hash branch 3 times, most recently from 1eff1ae to 6b131b1Compare January 23, 2025 12:04

Extend API to allow invoice creation with a description hash
7e8a8ab

joostjager force-pushed the invoice-description-hash branch from 6b131b1 to 7e8a8abCompare January 23, 2025 12:07

tnull reviewed Jan 23, 2025
View reviewed changes

This was referenced Jan 23, 2025
Default to description hash if description is too long #312
Closed
LDK Node v0.5 Tracking Issue #360
Closed

Minor cleanup to DRY up duplicate code
3cfb9e5

joostjager marked this pull request as ready for review January 23, 2025 15:31

tnull approved these changes Jan 23, 2025
View reviewed changes

tnull merged commit 92ee62f into lightningdevkit:mainJan 23, 2025

tnull added a commit that referenced this pull request Jan 24, 2025
Merge pull request#442from tnull/2025-01-invoice-desc-followup
3cd1e98
Add reconversion unit test (#438 followup)

joostjager force-pushed the invoice-description-hash branch 2 times, most recently from be6be7e to f958924Compare January 21, 2025 15:14

joostjager commented Jan 21, 2025
View reviewed changes

Comment threadsrc/payment/bolt11.rs Outdated

joostjager commented Jan 21, 2025
View reviewed changes

Comment threadsrc/payment/bolt11.rs Outdated

joostjager commented Jan 21, 2025
View reviewed changes

Comment threadbindings/ldk_node.udl Outdated

joostjager force-pushed the invoice-description-hash branch 3 times, most recently from 1eff1ae to 6b131b1Compare January 23, 2025 12:04

Extend API to allow invoice creation with a description hash
7e8a8ab

joostjager force-pushed the invoice-description-hash branch from 6b131b1 to 7e8a8abCompare January 23, 2025 12:07

tnull reviewed Jan 23, 2025
View reviewed changes

This was referenced Jan 23, 2025
Default to description hash if description is too long #312
Closed
LDK Node v0.5 Tracking Issue #360
Closed

Minor cleanup to DRY up duplicate code
3cfb9e5

joostjager marked this pull request as ready for review January 23, 2025 15:31

tnull approved these changes Jan 23, 2025
View reviewed changes

tnull merged commit 92ee62f into lightningdevkit:mainJan 23, 2025

tnull added a commit that referenced this pull request Jan 24, 2025
Merge pull request#442from tnull/2025-01-invoice-desc-followup
3cd1e98
Add reconversion unit test (#438 followup)

joostjager force-pushed the invoice-description-hash branch 2 times, most recently from be6be7e to f958924Compare January 21, 2025 15:14

joostjager commented Jan 21, 2025
View reviewed changes

Comment threadsrc/payment/bolt11.rs Outdated

joostjager commented Jan 21, 2025
View reviewed changes

Comment threadsrc/payment/bolt11.rs Outdated

joostjager commented Jan 21, 2025
View reviewed changes

Comment threadbindings/ldk_node.udl Outdated

joostjager force-pushed the invoice-description-hash branch 3 times, most recently from 1eff1ae to 6b131b1Compare January 23, 2025 12:04

Extend API to allow invoice creation with a description hash
7e8a8ab

joostjager force-pushed the invoice-description-hash branch from 6b131b1 to 7e8a8abCompare January 23, 2025 12:07

tnull reviewed Jan 23, 2025
View reviewed changes

This was referenced Jan 23, 2025
Default to description hash if description is too long #312
Closed
LDK Node v0.5 Tracking Issue #360
Closed

Minor cleanup to DRY up duplicate code
3cfb9e5

joostjager marked this pull request as ready for review January 23, 2025 15:31

tnull approved these changes Jan 23, 2025
View reviewed changes

tnull merged commit 92ee62f into lightningdevkit:mainJan 23, 2025

tnull added a commit that referenced this pull request Jan 24, 2025
Merge pull request#442from tnull/2025-01-invoice-desc-followup
3cd1e98
Add reconversion unit test (#438 followup)

joostjager force-pushed the invoice-description-hash branch 2 times, most recently from be6be7e to f958924Compare January 21, 2025 15:14

joostjager commented Jan 21, 2025
View reviewed changes

Comment threadsrc/payment/bolt11.rs Outdated

joostjager commented Jan 21, 2025
View reviewed changes

Comment threadsrc/payment/bolt11.rs Outdated

joostjager commented Jan 21, 2025
View reviewed changes

Comment threadbindings/ldk_node.udl Outdated

joostjager force-pushed the invoice-description-hash branch 3 times, most recently from 1eff1ae to 6b131b1Compare January 23, 2025 12:04

Extend API to allow invoice creation with a description hash
7e8a8ab

joostjager force-pushed the invoice-description-hash branch from 6b131b1 to 7e8a8abCompare January 23, 2025 12:07

tnull reviewed Jan 23, 2025
View reviewed changes

This was referenced Jan 23, 2025
Default to description hash if description is too long #312
Closed
LDK Node v0.5 Tracking Issue #360
Closed

Minor cleanup to DRY up duplicate code
3cfb9e5

joostjager marked this pull request as ready for review January 23, 2025 15:31

tnull approved these changes Jan 23, 2025
View reviewed changes

tnull merged commit 92ee62f into lightningdevkit:mainJan 23, 2025

tnull added a commit that referenced this pull request Jan 24, 2025
Merge pull request#442from tnull/2025-01-invoice-desc-followup
3cd1e98
Add reconversion unit test (#438 followup)

joostjager force-pushed the invoice-description-hash branch 2 times, most recently from be6be7e to f958924Compare January 21, 2025 15:14

joostjager commented Jan 21, 2025
View reviewed changes

Comment threadsrc/payment/bolt11.rs Outdated

joostjager commented Jan 21, 2025
View reviewed changes

Comment threadsrc/payment/bolt11.rs Outdated

joostjager commented Jan 21, 2025
View reviewed changes

Comment threadbindings/ldk_node.udl Outdated

joostjager force-pushed the invoice-description-hash branch 3 times, most recently from 1eff1ae to 6b131b1Compare January 23, 2025 12:04

Extend API to allow invoice creation with a description hash
7e8a8ab

joostjager force-pushed the invoice-description-hash branch from 6b131b1 to 7e8a8abCompare January 23, 2025 12:07

tnull reviewed Jan 23, 2025
View reviewed changes

This was referenced Jan 23, 2025
Default to description hash if description is too long #312
Closed
LDK Node v0.5 Tracking Issue #360
Closed

Minor cleanup to DRY up duplicate code
3cfb9e5

joostjager marked this pull request as ready for review January 23, 2025 15:31

tnull approved these changes Jan 23, 2025
View reviewed changes

tnull merged commit 92ee62f into lightningdevkit:mainJan 23, 2025

tnull added a commit that referenced this pull request Jan 24, 2025
Merge pull request#442from tnull/2025-01-invoice-desc-followup
3cd1e98
Add reconversion unit test (#438 followup)

joostjager force-pushed the invoice-description-hash branch 2 times, most recently from be6be7e to f958924Compare January 21, 2025 15:14

joostjager commented Jan 21, 2025
View reviewed changes

Comment threadsrc/payment/bolt11.rs Outdated

joostjager commented Jan 21, 2025
View reviewed changes

Comment threadsrc/payment/bolt11.rs Outdated

joostjager commented Jan 21, 2025
View reviewed changes

Comment threadbindings/ldk_node.udl Outdated

joostjager force-pushed the invoice-description-hash branch 3 times, most recently from 1eff1ae to 6b131b1Compare January 23, 2025 12:04

Extend API to allow invoice creation with a description hash
7e8a8ab

joostjager force-pushed the invoice-description-hash branch from 6b131b1 to 7e8a8abCompare January 23, 2025 12:07

tnull reviewed Jan 23, 2025
View reviewed changes

This was referenced Jan 23, 2025
Default to description hash if description is too long #312
Closed
LDK Node v0.5 Tracking Issue #360
Closed

Minor cleanup to DRY up duplicate code
3cfb9e5

joostjager marked this pull request as ready for review January 23, 2025 15:31

tnull approved these changes Jan 23, 2025
View reviewed changes

tnull merged commit 92ee62f into lightningdevkit:mainJan 23, 2025

tnull added a commit that referenced this pull request Jan 24, 2025
Merge pull request#442from tnull/2025-01-invoice-desc-followup
3cd1e98
Add reconversion unit test (#438 followup)

joostjager force-pushed the invoice-description-hash branch 2 times, most recently from be6be7e to f958924Compare January 21, 2025 15:14

joostjager commented Jan 21, 2025
View reviewed changes

Comment threadsrc/payment/bolt11.rs Outdated

joostjager commented Jan 21, 2025
View reviewed changes

Comment threadsrc/payment/bolt11.rs Outdated

joostjager commented Jan 21, 2025
View reviewed changes

Comment threadbindings/ldk_node.udl Outdated

joostjager force-pushed the invoice-description-hash branch 3 times, most recently from 1eff1ae to 6b131b1Compare January 23, 2025 12:04

Extend API to allow invoice creation with a description hash
7e8a8ab

joostjager force-pushed the invoice-description-hash branch from 6b131b1 to 7e8a8abCompare January 23, 2025 12:07

tnull reviewed Jan 23, 2025
View reviewed changes

This was referenced Jan 23, 2025
Default to description hash if description is too long #312
Closed
LDK Node v0.5 Tracking Issue #360
Closed

Minor cleanup to DRY up duplicate code
3cfb9e5

joostjager marked this pull request as ready for review January 23, 2025 15:31

tnull approved these changes Jan 23, 2025
View reviewed changes

tnull merged commit 92ee62f into lightningdevkit:mainJan 23, 2025

tnull added a commit that referenced this pull request Jan 24, 2025
Merge pull request#442from tnull/2025-01-invoice-desc-followup
3cd1e98
Add reconversion unit test (#438 followup)

joostjager force-pushed the invoice-description-hash branch 2 times, most recently from be6be7e to f958924Compare January 21, 2025 15:14

joostjager commented Jan 21, 2025
View reviewed changes

Comment threadsrc/payment/bolt11.rs Outdated

joostjager commented Jan 21, 2025
View reviewed changes

Comment threadsrc/payment/bolt11.rs Outdated

joostjager commented Jan 21, 2025
View reviewed changes

Comment threadbindings/ldk_node.udl Outdated

joostjager force-pushed the invoice-description-hash branch 3 times, most recently from 1eff1ae to 6b131b1Compare January 23, 2025 12:04

Extend API to allow invoice creation with a description hash
7e8a8ab

joostjager force-pushed the invoice-description-hash branch from 6b131b1 to 7e8a8abCompare January 23, 2025 12:07

tnull reviewed Jan 23, 2025
View reviewed changes

This was referenced Jan 23, 2025
Default to description hash if description is too long #312
Closed
LDK Node v0.5 Tracking Issue #360
Closed

Minor cleanup to DRY up duplicate code
3cfb9e5

joostjager marked this pull request as ready for review January 23, 2025 15:31

tnull approved these changes Jan 23, 2025
View reviewed changes

tnull merged commit 92ee62f into lightningdevkit:mainJan 23, 2025

tnull added a commit that referenced this pull request Jan 24, 2025
Merge pull request#442from tnull/2025-01-invoice-desc-followup
3cd1e98
Add reconversion unit test (#438 followup)

Uh oh!

Conversation

joostjager commented Jan 21, 2025• edited by tnull Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

tnull left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tnull commented Jan 23, 2025

Uh oh!

tnull commented Jan 23, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

joostjager commented Jan 21, 2025• edited by tnull Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

tnull left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tnull commented Jan 23, 2025

Uh oh!

tnull commented Jan 23, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

joostjager commented Jan 21, 2025• edited by tnull Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

tnull left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tnull commented Jan 23, 2025

Uh oh!

tnull commented Jan 23, 2025

Uh oh!

Reviewers

joostjager commented Jan 21, 2025•
edited by tnull
Loading

joostjager commented Jan 21, 2025•
edited by tnull
Loading

joostjager commented Jan 21, 2025•
edited by tnull
Loading

joostjager commented Jan 21, 2025•
edited by tnull
Loading