-
Notifications
You must be signed in to change notification settings - Fork 376
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
Bolt12 Assessor and Fiat Currency Support for Offers #3525
Open
shaavan
wants to merge
26
commits into
lightningdevkit:main
Choose a base branch
from
shaavan:currency
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
+2,318
−1,635
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
To decouple offers and onion message-related code from `ChannelManager`, this commit introduces the `message_received` function in `Offer/OnionMessageHandler`. Currently, the function focuses on handling the retry logic for `InvoiceRequest` messages. Moving this responsibility ensures a cleaner separation of concerns and sets the foundation for managing offers/onion messages directly within the appropriate handler.
Since `ChannelMessageHandler`'s `message_received` function was solely used for handling invoice request retries. This function has been removed from `ChannelMessageHandler`, and the relevant code has been migrated to `OffersMessageHandler`'s `message_received`. This ensures invoice request retries are now handled in the appropriate context.
This commit temporarily removes support for async BOLT12 message handling to enable a smoother transition in the upcoming refactor. The current implementation of async handling is abrupt, as it requires delving into the synchronous case and generating an event mid-flow based on the `manual_handling` flag. This approach adds unnecessary complexity and coupling. A later commit will introduce a new struct, `OffersMessageFlow`, designed to handle and create offer messages. This new struct will support async handling in a more structured way by allowing users to implement a parameterized trait for asynchronous message handling. Removing the existing async support now ensures a cleaner and more seamless migration of offer-related code from `ChannelManager` to `OffersMessageFlow`.
This commit introduces a new struct, `OffersMessageFlow`, to extract all offers message-related code out of `ChannelManager`. By moving this logic into a dedicated struct, it creates a foundation for separating responsibilities and sets up a base for further code restructuring in subsequent commits.
A new trait, `OffersMessageCommons`, is introduced to encapsulate functions that are commonly used by both BOLT12-related functionality and other parts of `ChannelManager`. This enables a clean transition of BOLT12 code to `OffersMessageFlow` by moving shared functions into the new trait, ensuring they remain accessible to both `ChannelManager` and the refactored BOLT12 code.
This commit introduces the `OffersMessageHandler` implementation for `OffersMessageFlow`, enabling direct access to offer-specific functionality through `OffersMessageFlow`. With `OffersMessageFlow` now serving as the source of `OffersMessageHandler` implementation, the implementation in `ChannelManager` is no longer needed and has been safely removed.
- This commit introduces a new struct, `AnOffersMessageFlow`, which generically implements `OffersMessageFlow`. - In subsequent commits, this struct will be utilized for documentation purposes.
- The _persistence_guard here was not serving any purpose, and hence can be removed in this refactoring.
1. This allow removing an extra function from commons, simplifying the flow trait.
Introduce a new category of Bolt12 errors that contains the error generated while trying to generate response to Bolt12 messages.
The new trait allow taking the invoice_request, and access it. For now this allows accessing, that it contains the correct amount or if not then getting the right amount from the offer.
This implements the default behavior for Bolt12Assessor & Bolt12CurrencyAssessor
Parametised OffersMessageFlow over Bolt12Assessor & Bolt12CurrencyAssessor trait
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Builds on #3412
This PR introduces an Assessor for
Bolt12Messages
and adds the ability to support fiat currencies for offer amounts.Bolt12Assessor
Bolt12Assessor
trait provides the ability to process received offer messages and analyze them to determine whether they should be responded to.InvoiceRequest
orBolt12Invoice
).Currency Support
Bolt12CurrencyAssessor
enables users to implement support for their chosen currency by defining the correct conversion rate from fiat to millisatoshis.InvoiceRequest
s for their ownoffers
denominated in fiat.