-
Notifications
You must be signed in to change notification settings - Fork 412
Introduce Event Model for Offers Flow #3833
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 incomingInvoiceRequest
s orBolt12Invoice
s based on their configuredFlowConfigs
.By setting custom
FlowConfigs
, users can choose whether to:OfferEvents
for 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.