This PR adds support for lightning addresses within the Contacts functionality.
For existing contacts, the UI looks nearly identical:
But it now allows for multiple offers to be added, and multiple lightning addresses too:
When you add/edit an offer, you're now able to (optionally) provide a label:
This is quite helpful because, if a user does have multiple offers, they're probably for different wallets, or different services (in the case of a business). So the label is quite necessary.
Tapping the 3-line button provides a menu with various options:
Technical notes:
There's a new database table called contact_addresses, which basically uses the same layout as the existing contact_offers.
When you fetch a ContactInfo, it now looks like this:
data class ContactInfo(
// ...
val offers: List<ContactOffer>,
val addresses: List<ContactAddress>
)
data class ContactOffer(
val id: ByteVector32,
val offer: OfferTypes.Offer,
val label: String?,
val createdAt: Instant
)
// ...
ContactsManager has been simplified. That is, there used to be various functions like these:
suspend fun saveNewContact() { /* ... */}
suspend fun updateContact() { /* ... */}
suspend fun detachOfferFromContact() { /* ... */}
These functions are gone, and in their place is a single function that does everything for you:
/**
* This method will:
* - insert or update the contact in the database (depending on whether it already exists)
* - insert any new offers
* - update any offers that have been changed (i.e. label changed)
* - delete offers that have been removed from the list
* - insert any new addresses
* - update any addresses that have been changed (i.e. label changed)
* - delete any addresses that have been removed
*
* In other words, the UI doesn't have to track which changes have been made.
* It can simply call this method, and the database will be properly updated.
*/
suspend fun saveContact(contact: ContactInfo) { /* ... */}
Note that even though this function is helpful, the UI cannot call it blindly. We don't support duplicate offers within the system. That is, you can't add offer X to contact Bob if offer X is already associated with contact Alice. Attempting to do so will throw a sqlite error. And the same restriction applies to duplicated addresses. So the UI is responsible for checking, and displaying the proper error message to the user.
Since the ContactsManager already keeps all contacts in memory (via contactsList: StateFlow<List<ContactInfo>>), there are a bunch of (non-suspending) functions to fetch the ContactInfo given a:
payment
offerId
offer
publicKey
address
This means you can replace the call to suspend fun getContactForOffer(offer: OfferTypes.Offer) with fun contactForOffer(offer: OfferTypes.Offer)
Todo:
[x] If the user pastes an offer in the Send screen, we have a "Add to contacts" option. The same is not true for pasting/typing a lightning address.
[x] The "Add to contacts" should also allow the offer/address to be added to an existing contact.
[x] After sending a payment to an offer, and later viewing the sent payment, there should be a "add to contacts" option within the UI
[x] After sending a payment to an address, and later viewing the sent payment, there should be a "add to contacts" option within the UI
Motivation:
Not a lot of wallets support Bolt12 offers yet. Even less support receiving a payment via their own offer. Which means our Contacts functionality is basically limited to just Phoenix users right now.
Additionally, many people will simply prefer lightning addresses. They're a familiar format. And they're human-readable, and human-writable, and human-speakable. And they're modifiable (i.e. If I own/control the address, I can point it at a new wallet. Which gives me wallet independence.)
So this is a nice increase in the functionality of our Contacts feature.
This PR adds support for lightning addresses within the Contacts functionality.
For existing contacts, the UI looks nearly identical:
But it now allows for multiple offers to be added, and multiple lightning addresses too:
When you add/edit an offer, you're now able to (optionally) provide a label:
This is quite helpful because, if a user does have multiple offers, they're probably for different wallets, or different services (in the case of a business). So the label is quite necessary.
Tapping the 3-line button provides a menu with various options:
Technical notes:
There's a new database table called
contact_addresses, which basically uses the same layout as the existingcontact_offers.When you fetch a
ContactInfo, it now looks like this:ContactsManager has been simplified. That is, there used to be various functions like these:
These functions are gone, and in their place is a single function that does everything for you:
Note that even though this function is helpful, the UI cannot call it blindly. We don't support duplicate offers within the system. That is, you can't add offer X to contact Bob if offer X is already associated with contact Alice. Attempting to do so will throw a sqlite error. And the same restriction applies to duplicated addresses. So the UI is responsible for checking, and displaying the proper error message to the user.
contactsList: StateFlow<List<ContactInfo>>), there are a bunch of (non-suspending) functions to fetch the ContactInfo given a:This means you can replace the call to
suspend fun getContactForOffer(offer: OfferTypes.Offer)withfun contactForOffer(offer: OfferTypes.Offer)Todo:
Motivation:
Not a lot of wallets support Bolt12 offers yet. Even less support receiving a payment via their own offer. Which means our Contacts functionality is basically limited to just Phoenix users right now.
Additionally, many people will simply prefer lightning addresses. They're a familiar format. And they're human-readable, and human-writable, and human-speakable. And they're modifiable (i.e. If I own/control the address, I can point it at a new wallet. Which gives me wallet independence.)
So this is a nice increase in the functionality of our Contacts feature.