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]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 85.86%. Comparing base (3497b59) to head (42ca4b7).
⚠️ Report is 74 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #3118 +/- ##
==========================================
- Coverage 86.09% 85.86% -0.23% 
==========================================
Files 156 159 +3 Lines 103623 104310 +687 Branches 103623 104310 +687 ==========================================
+ Hits 89211 89568 +357 - Misses 11895 12239 +344 + Partials 2517 2503 -14 

Flag	Coverage Δ
tests	85.86% <100.00%> (-0.23%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

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

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[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.

[TheBlueMatt]

@valentinewallace what's the status of this? Should it be closed?

[valentinewallace]

@valentinewallace what's the status of this? Should it be closed?

I pushed an update just renaming StaticInvoice::message_paths, which I think addresses the core of the original issue. If there's too much further bikeshedding, probably not worth it and can be closed 😅

[TheBlueMatt]

thanks