valentinewallace
valentinewallace
Since that's somewhat orthogonal, how about renaming the methods to include `_message` and` _payment` for this PR?
@TheBlueMatt I scoped this refactor out a bit and it looks like a fair amount of work. We also currently support constructing non-LDK-specific blinded paths in our API, and it...
Renamed the methods and rebased due to conflicts. > I don't see why we'd break that? We'd just force users to specify if a BlindedPath is for payments or not...
Ok, updated with the split into `BlindedMessagePath`/`BlindedPaymentPath`.
I think/hope CI is fixed now
> > So keep the BlindedPath type public and have 3 path types, then? > > Wait why does `BlindedPath` need to be public? I mean we can implement (de)serialization...
> We could have a `Blinded{Message,Payment}::from_raw` constructor that just takes the fields we need, no? Sure, but that feels like scope creep to me and I'd rather save it for...
Squashed with the following diff making `BlindedPath` private: ```diff diff --git a/lightning/src/blinded_path/mod.rs b/lightning/src/blinded_path/mod.rs index 0f48044f2..6a278b7fd 100644 --- a/lightning/src/blinded_path/mod.rs +++ b/lightning/src/blinded_path/mod.rs @@ -26,7 +26,7 @@ use crate::prelude::*; /// Onion messages and...
Pushed with the following diff: ```diff diff --git a/lightning/src/blinded_path/message.rs b/lightning/src/blinded_path/message.rs index 602c447ab..93d36d621 100644 --- a/lightning/src/blinded_path/message.rs +++ b/lightning/src/blinded_path/message.rs @@ -141,14 +141,14 @@ impl BlindedMessagePath { /// Advance the blinded onion message...