Add support for sending to human-readable names (BIP 353) #528

chuksys · 2025-04-22T00:41:55Z

This PR is a first step to add support for human-readable names as outlined in BIP 353 and implemented in LDK 0.1.

Changes

A send_to_human_readable_name function was added under Bolt12Payment.
A HrnBolt12Offer PaymentKind variant was added.
A HrnParsingFailed Error variant was added.
These new enum variants were added to the uniffi bindings.

I plan to follow up with a PR for #436 and another PR that will add HRN sending for on-chain payments.

ldk-reviews-bot · 2025-04-22T00:41:58Z

👋 Thanks for assigning @tnull as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

chuksys · 2025-04-22T02:27:17Z

src/payment/bolt12.rs

+	pub fn send_to_human_readable_name(
+		&self, name: &str, amount_msat: u64, dns_resolvers: Vec<Destination>,
+	) -> Result<PaymentId, Error> {


I should probably expose this method to uniffi bindings?

Also, for dns_resolvers maybe I should add a method in graph.rs which helps find all nodes that have a certain feature flag. This could make it simpler for the user to find all dns_resolver nodes.

I should probably expose this method to uniffi bindings?

Yes, you'll need to expose this method and all types it requires.

Also, for dns_resolvers maybe I should add a method in graph.rs which helps find all nodes that have a certain feature flag. This could make it simpler for the user to find all dns_resolver nodes.

Yes, populating the list of default Destinations (see above) from the network graph is probably a good idea.

ldk-reviews-bot · 2025-04-24T17:07:28Z

🔔 1st Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2025-04-28T00:00:09Z

🔔 2nd Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

tnull

Thanks for looking into this, and please excuse the delay here!

tnull · 2025-04-29T09:31:46Z

src/payment/store.rs

+	/// [HumanReadableName]: crate::lightning::onion_message::dns_resolution::HumanReadableName
+	/// [BIP 353]: https://github.com/bitcoin/bips/blob/master/bip-0353.mediawiki
+	/// [bLIP 32]: https://github.com/lightning/blips/blob/master/blip-0032.md
+	HrnBolt12Offer {


Hmm, I'm not sure we want to add a separate PaymentKind variant for this. Likely it should just be a Bolt12Offer? In the upcoming 'payment metadata store' (see #425), we might then store the HRN as associated metadata though.

tnull · 2025-04-29T09:35:04Z

src/payment/bolt12.rs

+	/// These nodes can be found by running a search through the `NetworkGraph` to find nodes that announce the
+	/// `dns_resolver` feature flag.
+	pub fn send_to_human_readable_name(
+		&self, name: &str, amount_msat: u64, dns_resolvers: Vec<Destination>,


I think rather then replicating LDK's API and have the user give the Destination for each send, in LDK Node we should probably allow users to set default DNS resolvers via the Builder and/or the Config. Here, we'd then error-out if the user didn't configure them upfront, and in the future we might be able to supply some default values.

tnull · 2025-04-29T09:36:43Z

src/payment/bolt12.rs

+	pub fn send_to_human_readable_name(
+		&self, name: &str, amount_msat: u64, dns_resolvers: Vec<Destination>,
+	) -> Result<PaymentId, Error> {


I should probably expose this method to uniffi bindings?

Yes, you'll need to expose this method and all types it requires.

Also, for dns_resolvers maybe I should add a method in graph.rs which helps find all nodes that have a certain feature flag. This could make it simpler for the user to find all dns_resolver nodes.

Yes, populating the list of default Destinations (see above) from the network graph is probably a good idea.

tnull · 2025-04-29T09:43:07Z

src/uniffi_types.rs

@@ -429,6 +430,18 @@ impl UniffiCustomTypeConverter for DateTime {
 	}
 }

+impl UniffiCustomTypeConverter for HumanReadableName {


Let's avoid introducing yet another UniffiCustomTypeConverter for this, as we're actually currently working towards removing them for Bolt11Invoice, Offer, etc.

So we should just expose the HumanReadableName as a Uniffi interface, and if we find its API can't fully exposed, we'll need to create a type wrapper in uniffi_types.rs for it that is switched based on the uniffi flag (see #522 for reference).

chuksys · 2025-04-30T17:42:52Z

Thank you for the feedback @tnull. I will address the comments and push the updated changes as soon as possible.

sangbida · 2025-05-05T12:13:28Z

Had a quick look at why some of the CI tests could be failing. I think the cln test is potentially failing because of the dnssec addition. The test env may need to be configured to support dnssec?

EDIT: Nevermind, I think this is the CLN issue: #527 The test seems to be flaky.

chuksys · 2025-05-10T09:41:15Z

I will address the comments and push the updated changes as soon as possible.

Still actively working on this. Will push updates once I'm done (likely within the next week).

tnull · 2025-05-12T08:15:03Z

Still actively working on this. Will push updates once I'm done (likely within the next week).

Cool! Also don't hesitate to reach out (e.g. via LDK Discord -- I'm _tnull there) if you have any questions and/or are blocked on a particular issue! Happy to help!

chuksys · 2025-05-12T13:18:51Z

Also don't hesitate to reach out (e.g. via LDK Discord -- I'm _tnull there) if you have any questions and/or are blocked on a particular issue! Happy to help!

Thank you!

…2 Offers BIP 353 introduced human-readable names which has been implemented in LDK (0.1). This commit adds support for sending to HRNs that resolve to Bolt12 Offers by using the LDK pay_for_offer_from_human_readable_name method in ChannelManager.

…o Bolt12 Offers

chuksys · 2025-05-13T20:12:37Z

Hi @tnull, thanks once again for the pointer you gave me in our discord chat. I just pushed some updates that allow the user to set a list of default node_ids to use as the Destination for HRNs dns resolution. As advised, I would follow up with another PR later that would fully expose Destination from LDK to uniFFI bindings and allow using BlindedPaths as the Destination for HRNs dns resolution. I am yet to implement the method which allows the user to easily fetch dns_resolver nodes from the network_graph - I will work on that next and push when done or perhaps open a new PR for that. Thanks!

tnull

Already looks pretty good, some comments

tnull · 2025-05-15T11:05:00Z

src/builder.rs

@@ -457,6 +462,17 @@ impl NodeBuilder {
 		Ok(self)
 	}

+	/// Sets the default dns_resolvers to be used when sending payments to HRNs.


Can we link to the actual config field here (and below accordingly)?

tnull · 2025-05-15T11:06:32Z

src/config.rs

@@ -167,6 +168,11 @@ pub struct Config {
 	/// **Note:** If unset, default parameters will be used, and you will be able to override the
 	/// parameters on a per-payment basis in the corresponding method calls.
 	pub sending_parameters: Option<SendingParameters>,
+	/// The dns_resolvers node_ids to be used for resolving Human-readable Names.


nit: Let's avoid using non-local variable names like dns_resolvers and node_ids. Instead, just say "The DNS resolvers.."

tnull · 2025-05-15T11:06:46Z

src/config.rs

+	/// The dns_resolvers node_ids to be used for resolving Human-readable Names.
+	///
+	/// If set to `Some`, the values set will be used as dns_resolvers when sending to HRNs.
+	/// **Note:** If set to `None`, payments to HRNs will fail.


nit: Lets put this note in a dedicated paragraph.

tnull · 2025-05-15T11:07:59Z

src/config.rs

+	///
+	/// If set to `Some`, the values set will be used as dns_resolvers when sending to HRNs.
+	/// **Note:** If set to `None`, payments to HRNs will fail.
+	pub dns_resolvers_node_ids: Option<Vec<PublicKey>>,


Why is this an option rather than just having a Vec? Is this so that in the future it can more easily be converted to an override value, once we discover default resolvers via the network graph?

Also, should we maybe only add this as part of an new HumanReadableNamesConfig object, as we may be adding addtional configs in the future?

tnull · 2025-05-15T11:19:02Z

src/lib.rs

@@ -829,6 +829,11 @@ impl Node {
 		self.config.node_alias
 	}

+	/// Returns the list of dns_resolvers that will be used to resolve HRNs.
+	pub fn dns_resolvers(&self) -> Option<Vec<PublicKey>> {


No need for this extra accessor, users can just access the config.

tnull · 2025-05-15T11:29:51Z

src/payment/bolt12.rs

+		}?;
+
+		let destinations: Vec<Destination> =
+			dns_resolvers.into_iter().map(|public_key| Destination::Node(public_key)).collect();


Let's do this directly in the match above, so we don't have to first clone and then collect again, which is an unnecessary allocation.

tnull · 2025-05-15T11:30:29Z

src/payment/bolt12.rs

+			dns_resolvers.into_iter().map(|public_key| Destination::Node(public_key)).collect();
+
+		match self.channel_manager.pay_for_offer_from_human_readable_name(
+			hrn.clone(),


I don't think this clone is necessary?

tnull · 2025-05-15T11:31:20Z

src/payment/bolt12.rs

+					Some(amount_msat),
+					None,
+					PaymentDirection::Outbound,
+					PaymentStatus::Pending,


Wouldn't we add it as Failed here?

tnull · 2025-05-15T11:52:48Z

src/payment/bolt12.rs

+		) {
+			Ok(()) => {
+				log_info!(self.logger, "Initiated sending {} msats to {}", amount_msat, name);
+				let kind = PaymentKind::Bolt12Offer {


Hmm, it's a bit weird that we can't set any of these fields and they'd never really be updated. I wonder if we should intercept the InvoiceReceived event to at least set some of these fields when we get access to the invoice for this payment?

Also opened lightningdevkit/rust-lightning#3779 as it would be helpful to have a dedicated event that emits the offer after it has been retrieved.

tnull · 2025-05-15T11:54:40Z

src/payment/bolt12.rs

+	/// amount paid to be determined by the user.
+	///
+	/// If `dns_resolvers_node_ids` in Config is set to `None`, this operation will fail.
+	pub fn send_to_human_readable_name(


Do you think we can add a test case to check that this works somehow? Or would we need to wait for #436 to be able to create an end-to-end test?

ldk-reviews-bot requested a review from jkczyz April 22, 2025 00:52

chuksys commented Apr 22, 2025

View reviewed changes

tnull requested review from tnull and removed request for jkczyz April 22, 2025 17:06

tnull reviewed Apr 29, 2025

View reviewed changes

TheBlueMatt mentioned this pull request May 1, 2025

Add new store for inbound payment metadata #425

Open

chuksys added 10 commits May 13, 2025 18:51

fixup! Add support for sending to human-readable names that resolve t…

36bda24

…o Bolt12 Offers

fixup! Add support for sending to human-readable names that resolve t…

5713f43

…o Bolt12 Offers

Allow setting default DNS resolvers for HRNs

27058a8

fixup! Allow setting default DNS resolvers for HRNs

605d45d

fixup! Add support for sending to human-readable names that resolve t…

a71ce33

…o Bolt12 Offers

fixup! Allow setting default DNS resolvers for HRNs

3913fe5

fixup! Add support for sending to human-readable names that resolve t…

9d8d3ff

…o Bolt12 Offers

fixup! Add support for sending to human-readable names that resolve t…

549b4cf

…o Bolt12 Offers

fixup! Allow setting default DNS resolvers for HRNs

2e75be9

chuksys force-pushed the send-to-human-readable-names branch from 386f95f to 2e75be9 Compare May 13, 2025 18:31

Fix Formattting Issues

8bf2184

tnull reviewed May 15, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add support for sending to human-readable names (BIP 353) #528

Add support for sending to human-readable names (BIP 353) #528

chuksys commented Apr 22, 2025

ldk-reviews-bot commented Apr 22, 2025 •

edited

Loading

chuksys Apr 22, 2025

tnull Apr 29, 2025

ldk-reviews-bot commented Apr 24, 2025

ldk-reviews-bot commented Apr 28, 2025

tnull left a comment

tnull Apr 29, 2025

tnull Apr 29, 2025

tnull Apr 29, 2025

tnull Apr 29, 2025

chuksys commented Apr 30, 2025

sangbida commented May 5, 2025 •

edited

Loading

chuksys commented May 10, 2025

tnull commented May 12, 2025

chuksys commented May 12, 2025

chuksys commented May 13, 2025 •

edited

Loading

tnull left a comment

tnull May 15, 2025

tnull May 15, 2025

tnull May 15, 2025

tnull May 15, 2025

tnull May 15, 2025

tnull May 15, 2025

tnull May 15, 2025

tnull May 15, 2025

tnull May 15, 2025

tnull May 15, 2025

Add support for sending to human-readable names (BIP 353) #528

Are you sure you want to change the base?

Add support for sending to human-readable names (BIP 353) #528

Conversation

chuksys commented Apr 22, 2025

Changes

ldk-reviews-bot commented Apr 22, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ldk-reviews-bot commented Apr 24, 2025

ldk-reviews-bot commented Apr 28, 2025

tnull left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

chuksys commented Apr 30, 2025

sangbida commented May 5, 2025 • edited Loading

chuksys commented May 10, 2025

tnull commented May 12, 2025

chuksys commented May 12, 2025

chuksys commented May 13, 2025 • edited Loading

tnull left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ldk-reviews-bot commented Apr 22, 2025 •

edited

Loading

sangbida commented May 5, 2025 •

edited

Loading

chuksys commented May 13, 2025 •

edited

Loading