Rename BOLT 12 message paths fields and methods

[valentinewallace]

From #3082 (comment).

Based on #3082.

[valentinewallace]

@jkczyz did you want to rename Offer::paths now as well?

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 91.60%. Comparing base (07f3380) to head (7e8c307).
Report is 100 commits behind head on main.

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3118      +/-   ##
==========================================
+ Coverage   89.92%   91.60%   +1.67%     
==========================================
  Files         121      122       +1     
  Lines       99172   114710   +15538     
  Branches    99172   114710   +15538     
==========================================
+ Hits        89180   105076   +15896     
+ Misses       7391     7098     -293     
+ Partials     2601     2536      -65     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[TheBlueMatt]

Needs rebase.

[valentinewallace]

Rebased

[jkczyz]

LGTM. Feel free to squash

[TheBlueMatt]

ISTM a lot of this confusion comes because we have one BlindedPath type to handle two totally different things - payment blinded paths and messaging blinded paths. Should we split those into two different types?

[jkczyz]

ISTM a lot of this confusion comes because we have one BlindedPath type to handle two totally different things - payment blinded paths and messaging blinded paths. Should we split those into two different types?

Hmmm... would be somewhat annoying to serialize since the payment paths are written in two TLVs.

[TheBlueMatt]

would be somewhat annoying to serialize

Wait, why? We can just have a wrapper and nothing else, the code wouldn't have to change?

[jkczyz]

would be somewhat annoying to serialize

Wait, why? We can just have a wrapper and nothing else, the code wouldn't have to change?

I guess the wrapper just wouldn't implement Writeable. But you would need to change the code that deals with compact paths.

I'm not sure making one really is solving much, though. Blinded payment paths are only used in one place. All the new blinded paths fields are / will be for messages.

[TheBlueMatt]

I guess the wrapper just wouldn't implement Writeable.

Hmm? The wrappers would presumably implement the same thing that the current BlindedPath implements, and the current BlindedPath would be an internal struct that isn't used outside of blinded_path.rs (or whatever).

I'm not sure making one really is solving much, though. Blinded payment paths are only used in one place. All the new blinded paths fields are / will be for messages.

That's fair, its somewhat orthogonal to this PR specifically, but the current code has three methods that all return a BlindedPath, which is just extra confusion if we can get one less.

[TheBlueMatt]

I'm confused, async_receive_paths imply to me that these are payment paths, but the old name was message_paths, should it be like async_awoken_notify_message_paths or something more verbose?

[valentinewallace]

notify_online_message_paths? @jkczyz any thoughts?

[jkczyz]

Could you remind me what message will be sent over this path and who is sending it?

It's in the static invoice that the mailbox sends back to the payer. So the path is to the recipient through their mailbox, IIUC? notify_online seems to align more with the reply path that would be used?

[jkczyz]

Hmm? The wrappers would presumably implement the same thing that the current BlindedPath implements, and the current BlindedPath would be an internal struct that isn't used outside of blinded_path.rs (or whatever).

Payment paths are written in invoices as two separate TLVs, so having it implement Writeable might cause us to inadvertently write the wrong data.

[TheBlueMatt]

Okay, then payment paths wouldn't implement Writeable? Don't really see why splitting the paths into two structs poses more issues than the current API of only having one.