Add OfferManager #624
Add OfferManager #624
Conversation
|
Assuming this PR stays in review for a while, and since it's a large change, we could use a temporary specific version name to differentiate this offer branch from the |
thomash-acinq
force-pushed
the
offer-manager
branch
2 times, most recently
from
edbf21e to
ed10fe2
Compare
|
Can you rebase this? It will make it easier to test with the latest Bolt 12 changes available on |
thomash-acinq
force-pushed
the
offer-manager
branch
2 times, most recently
from
daf6a19 to
4c856bb
Compare
src/commonMain/kotlin/fr/acinq/lightning/payment/OfferManager.kt
Outdated
Show resolved
Hide resolved
src/commonMain/kotlin/fr/acinq/lightning/payment/OfferManager.kt
Outdated
Show resolved
Hide resolved
src/commonMain/kotlin/fr/acinq/lightning/payment/OfferManager.kt
Outdated
Show resolved
Hide resolved
src/commonMain/kotlin/fr/acinq/lightning/payment/OfferManager.kt
Outdated
Show resolved
Hide resolved
| override val paymentHash: ByteVector32 = paymentRequest.paymentHash | ||
| } | ||
|
|
||
| /** KeySend payments are spontaneous donations that don't need an invoice from the recipient. */ | ||
| data class KeySend(val preimage: ByteVector32) : Details() { |
There was a problem hiding this comment.
KeySend doesn't seem to be supported, should we just remove all references to it?
There was a problem hiding this comment.
True, we defined the types initially to ensure that the architecture allowed different types of lightning payments, but we don't support it. You can remove all references to it now that we have the Blinded case that shows a different type of lightning payment!
src/commonMain/kotlin/fr/acinq/lightning/payment/OfferManager.kt
Outdated
Show resolved
Hide resolved
|
After converging on #633, we should rebase to include #626 and register that default offer: private val offerManager = run {
val (pathId, offer) nodeParams.defaultOffer(walletParams.trampolineNode)
val manager = OfferManager(nodeParams, walletParams, _eventsFlow, logger)
manager.registerOffer(offer, pathId)
manager
}And we should be done with the changes to |
We always use the invoice's `node_id`, so instead of duplicating this argument we can extract it automatically from the invoice. It avoids mistakes that could mess up our accounting.
And rename top-level `SendMessage` to `SendOnionMessage`.
We may want to display a spinner in the UI while requesting the invoice for an offer payment, to quickly report back when the recipient cannot be contacted. This means we need to fail as soon as the timeout provided is hit, so we cannot rely on a regular background task. We instead create a dedicated coroutine for each payment, with the timeout provided in the `PayOffer` request.
This commit keeps the business logic mostly unchanged, but re-works the error handling to ensure that we log as much details as possible to help troubleshoot compatibility issues. It adds support for sending `invoice_error` on some error cases to help debug potential issues. When the introduction node of the recipient is our trampoline node, we remove an unnecessary hop in the onion message.
thomash-acinq
force-pushed
the
offer-manager
branch
from
598068f to
ec69a3c
Compare
|
I've merged your refactoring, implicit node id and default offer. |
Add
OfferManagerthat handles offer related onion messages (which is all the onion messages that we support).It can request an invoice and pay it, answer to invoice requests.
Depends on #621 and #623