(android) Add support for BIP-353 DNS addresses #585
Merged
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
Also fixed contact photo border, and move outgoing offer message to its own section in payment details.
If a scan input contains an @ we maeke a DNS lookup for bip-353 (expecting a bolt12 offer), or fallback to the LNURL lightning addresses behaviour. This allows Phoenix to pay bip-353 addresses.
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.
This PR adds support for paying and receiving with a BIP353 DNS address. This BIP353 scheme provides a human readable address that resolves to a Bolt12 offer through a DNS lookup.
This address makes it much easier to share a Bolt12 offer, since the offer is so large and unwieldy. For example, to share an offer on Twitter, one has to use the QR code image. Having a short and cool handle similar to email is also common in modern payment apps.
Paying a BIP353 address
Paying a BIP353 DNS address is done through the manual input (for now contacts are not linked to addresses, see below). A DNS lookup is made through https://dns.google (more resolvers to be added soon) to retrieve the associated offer. Note that the domain hosting the address does not learn that a query was made, which brings some privacy to the payer and the payee (see the BIP for details).
Compatibility with classic Lightning address
The wallet is still able to pay regular LNURL-based Lightning address. It will first try a DNS lookup and if it fails, will try a LNURL resolution.
Claiming a Bip353 address
See ACINQ/lightning-kmp#683
For convenience, the LSP can provide a BIP353 DNS address, which is made up of random words (English only for now) and a few digits, associated to a domain hosted by the LSP (phoenixwallet.me). When available, this address is displayed below the Offer QR code, in the Receive screen.
Feature is opt-in
This feature is opt-in since it's experimental. Also many users will prefer to self-host, or to use a third party service, which will let them customise the name and have a pretty domain.
Resetting the wallet
If the wallet is reset and restored, the address will stay the same and payments to that address will still work and pay the same offer.
Linking a BIP353 address to a contact
A BIP353 address is linked to an offer, which itself may be linked to a contact. As such, a contact could be linked to a BIP353 address. This relation is not yet handled in Phoenix, that will be done in a later PR. But we'll be able to pin an BIP353 address to a given contact, and inform the user when that address now points to a different offer than before (which could be an issue).
iOS support
Paying an offer should not need much additional work since most of the logic is in
phoenix-shared. However to claim the offer, some UI work will have to be done.