lightningdevkit
Move BOLT 12 into its own crate
As long as there are no dependencies we want to take that want to depend on our invoice types, there's no reason to have them in a separate crate, but with the addition of bitcoin-payment-instructions I think that might change. It might be nice to be able to have a pay_for method in ChannelManager for a bitcoin-payment-instructions::FixedAmountPaymentInstructions, but that would require the BOLT 12 structs (even if not the serialization for them) living in a separate crate.
For reference: https://docs.rs/bitcoin-payment-instructions/latest/bitcoin_payment_instructions/
Played with this, I don't really actually think its worth it as we'd have to first split out all our TLV and serialization logic into some kind of lightning-ser crate and then we can do this...Instead, maybe we should just do #3733 and then depend on bitcoin-payment-instructions in ldk-node and do the right mapping there but leave it out of ldk.
Played with this, I don't really actually think its worth it as we'd have to first split out all our TLV and serialization logic into some kind of lightning-ser crate and then we can do this...
Hmm, just want to mention that I've be in favor of the original idea (splitting out BOLT12-types to a crate similar to lightning-invoice) for a while. And I have also encountered a few user requests that would like to use LDK's BOLT12 de/ser logic independent from the node-y types like ChannelManager.
IMO it would also be pretty powerful to use these crates as initial PoC for providing Uniffi bindings in rust-lightning, but that is a discussion for another issue.
And I have also encountered a few user requests that would like to use LDK's BOLT12 de/ser logic independent from the node-y types like ChannelManager.
I'm not sure what's stopping them? It being in the same crate isn't really a huge deal, the compiler should happily remove stuff from the finished binary that's unused. It impacts compile-time, but not hugely, most developers aren't re-compiling all dependencies very often. The only reason to do this would be if we want to depend on something that depends on BOLT12, IMO.
IMO it would also be pretty powerful to use these crates as initial PoC for providing Uniffi bindings in rust-lightning, but that is a discussion for another issue.
Hmm, yea, possible, though again we could do that now. I'd also very much like to avoid maintaining our own bindings crate for the full API since that is a lot of work. We should really look into having our existing bindings generation flow generate UniFFI bindings, instead, IMO......some day.