The ability to build a `ReplyPath` to send messages outside of `ChannelManager`

[TheBlueMatt]

Currently we lean on ChannelManager to build all the reply paths we need to receive replies to our onion messages. As a part of the ongoing OffersFlow work that should change, but one specific feature we should have is the ability to somehow build a reply path from outside of ChannelManager. I currently want this because I was trying to implement DNSSEC proof resolution outside of ChannelManager (to drive conversion of HRNs to offers from outside of LDK "core") and ran into this blocking me.

cc @shaavan @jkczyz

[shaavan]

Hi Matt! We were brainstorming some ideas around this and wanted to get your thoughts on something.

As we understand it, creating a reply_path mainly involves two pieces:

1. Selecting a set of peers for the blinded path, and
2. Using MessageRouter::create_blinded_path to build the path using those peers.

Since MessageRouter is already a trait decoupled from ChannelManager, it seems like — in principle — one could implement this outside ChannelManager, assuming they have their own peer storage and a way to retrieve a suitable Vec<Pubkey>.

So we were wondering — is there something specific that ChannelManager is doing beyond just peer selection and calling create_blinded_path that makes this hard to do externally? Or is the blocker more about how we currently rely on ChannelManager to produce the peer list in practice?

Would love to hear your thoughts — thanks!

[TheBlueMatt]

Ah, good point, indeed. I suppose mostly we're lacking some utility to expose this to users in an obvious way. It'd be nice to be able to call one method with a list of ChannelDetails, an RNG, and a message context authentication secret and have it give me a blinded path that someone can use to reply to us.

[jkczyz]

Still not sure I understand what is wanted here that isn't already available through using DefaultMessageRouter::create_blinded_path. For message paths, the authentication is specific to the MessageContext unlike for payment paths with PaymentContext.

[TheBlueMatt]

Ah, so now I don't need this because release_pending_messages can now just return instructions that ask the OnionMessenger to build the blinded path. Or maybe it always was that way and I just didn't realize it. Either way I don't see an immediate action item here.