Introduce Event Model for Offers Flow #3833
Conversation
|
I've assigned @joostjager as a reviewer! |
|
cc @jkczyz |
|
🔔 1st Reminder Hey @joostjager! This PR has been waiting for your review. |
|
Is this proposed change a response to a request from a specific user/users? |
|
Hi @joostjager! This PR is actually a continuation of the original thread that led to the The motivation behind it was to provide users with the ability to handle So, as a first step, we worked on refactoring most of the Offers-related code out of Hope that gives a clear picture of the intent behind this! Let me know if you have any thoughts or suggestions—would love to hear them. Thanks a lot! |
|
Another use case is Fedimint, where they'll want to include their own payment hash in the |
Does Fedimint plan to use the |
| let invoice_request = match self.flow.determine_invoice_request_handling(invoice_request) { | ||
| Ok(Some(ir)) => ir, | ||
| Ok(None) => return None, | ||
| Err(_) => { | ||
| log_trace!(self.logger, "Failed to handle invoice request"); | ||
| return None; | ||
| } | ||
| }; |
There was a problem hiding this comment.
Hmm... so the user may want to handle this asynchronously because they just need to verify that an amount (or supply that is) is sufficient for the offer's currency denomination. In that case, we should really have some function that continues the code below (i.e. creating a payment hash / secret, building the invoice, and enqueuing it to be sent).
Another reason is they want to supply their own payment hash. Similarly, they would need to build the invoice and enqueue it for sending. They may be even want to customize the invoice in some other ways using the builder.
I'm not quite sure how we want to do this. For the first case, it seems we should make it easy for them, which means they would need to call something on ChannelManager to continue the flow. Whereas, the second case is more about calling methods on OffersMessageFlow. But it would be weird for the former since the events' docs would need to reference ChannelManager.
| pub enum InvoiceBuilderVariant<'a> { | ||
| /// An [`InvoiceBuilder`] that uses a derived signing public key. | ||
| Derived(InvoiceBuilder<'a, DerivedSigningPubkey>), | ||
| /// An [`InvoiceBuilder`] that uses an explicitly set signing public key. | ||
| Explicit(InvoiceBuilder<'a, ExplicitSigningPubkey>), | ||
| } |
There was a problem hiding this comment.
I'm not sure yet, but we may instead want to try making different VerifiedInvoiceRequest types(w/ and w/o derived keys). Then we'd have have two versions of create_invoice_builder_from_invoice_request for each type.
| @@ -588,6 +588,36 @@ pub struct InvoiceRequest { | |||
| signature: Signature, | |||
| } | |||
|
|
|||
| impl InvoiceRequestContents { | |||
| pub(crate) fn amount_source(&self) -> Result<InvoiceRequestAmountSource, Bolt12SemanticError> { | |||
There was a problem hiding this comment.
We should look into using InvoiceRequestAmountSource as the internal representation in InvoiceRequestContents to avoid needing a Result. Maybe similar for Bolt12Invoice.
| /// | ||
| /// [`Amount::Currency`]: crate::offers::offer::Amount::Currency | ||
| /// [`Amount::Bitcoin`]: crate::offers::offer::Amount::Bitcoin | ||
| amount_source: InvoiceRequestAmountSource, |
There was a problem hiding this comment.
May not need this here if we can get it directly from VerifiedInvoiceRequest as per the other comment.
I believe with one. |
|
🔔 2nd Reminder Hey @joostjager! This PR has been waiting for your review. |
This PR introduces the event-model for Flow, that allows a user to asynchronously examine, and handle and InvoiceRequest, or an Invoice, based on their selected
FlowConfig.# Introduce Event Model for Offers FlowThis PR introduces an event-based model for
OffersMessageFlow, enabling users to asynchronously examine and handle incomingInvoiceRequests orBolt12Invoices based on their configuredFlowConfigs.By setting custom
FlowConfigs, users can choose whether to:OfferEventsfor manual inspection and handling.This makes offer handling more flexible, especially in use-cases like:
The default configuration (
NeverTrigger) maintains backward compatibility by preserving the existing synchronous behavior.