Conversation
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
This implements the PAY side of the lightning gateway using the Alby API, with no changes alby side.
To implement the RECEIVE side, we'd have to implement a webhook or htlc interceptor form the alby side. See
route_htlcsandcomplete_htlc.Pending Questions:
Is the receiver pubkey for any alby invoice always the
030a58b8653d32b99200a2334cfe913e51dc7d155aa0116c176657a4f1722677a3aliased to getalby.com? If that changes, we'd need a way to get that through the alby api, but from my hitting get invoice and hitting a bunch of different getalby.com lightning addresses it looks like it's always that oneThere's a couple nuances about private payments that are worth discussing and depend on Alby's API architecture
Are Alby pay requests via the API idemompotent? If not we have to use
check_statusso the gateway doeesn't try to pay the invoice twice. I think we can use the existing GET status endpoints for this but it's redundant to do so if the pay API is idempotent.