Design UX concepts for contact list

[rabbitholiness]

This issue outlines the scope and specs for the contact list feature, which should integrate and replace the address book functionality currently implemented in QT.

Address book in QT

The address book feature in Bitcoin Core QT allows users to:

• save a bitcoin addresses and associate it with a label, before actually using it for a payment.
• add a label to bitcoin addresses that they have already sent a payment to

While this feature can be useful for some cases, the current feature has some drawbacks from a UX perspective:

• It only accounts for send addresses.
• It's based on individual addresses, which means that I have to create two entries with the same label, if I send two payments to the same person.
• The address book is on a per wallet basis. This means that if I switch to from “Spending wallet” to “Savings wallet”, I loose access to the contacts/address book from “Spending wallet”.

Contacts

For the Bitcoin Core App, we would like to rethink the address book and expand it to work in a more human-centered way, based around contacts. Contacts are a useful tool when it comes to social and financial transactions. We primarily think about contacts in terms of people and companies, not addresses and labels.

The contact list should be a global feature throughout the app, not based on individual wallets. So, users should have the option to use contacts across all wallets. One technical question is how and where to store the contact data.

A contact can have the following pieces of information associated:

Contact details

• First name, last name
• Note

Payment information

• Silent payment address(s)
• Bitcoin address(es)
• Maybe also XPUB(s)?

Payment history

• Transactions (incoming & outgoing)
• Payment requests

Basic user flows

There are many different possible entry points for users to create, edit, or access contacts.

Create new contact:

• From scratch: the user starts in the contact list to create a new contact. He manually adds (mostly pastes) an address or an XPUB.
• From an incoming payment: the user clicks on the contacts icon and can create a new contact, if there is no matching contact already in the contact list.
• From an outgoing payment: while sending a payment, the user can associate the payment with an existing contact or create a new one.

Adding to an existing contact

• From an incoming payment: the user clicks on the “contacts” icon to associate a specific payment with a contact.
• From an outgoing payment: users can select the contact
• From an outgoing payment request: when creating an invoice

Edit contact:

• From the contact details

Contact list actions

Users can initiate different workflows directly from the contact details.

• make a payment
• request a payment
• view payment history
• edit/delete contact
• Other actions: share, merge contacts, etc.

Related functionality

Introducing contacts can have impact on other sections of the application. We might need or want to introduce features across different places to increase the usefulness of contacts. These could be:

Activity screen:

• Filter the activity screen by contacts

Payment details screen:

• Display contact
• Let users add or remove a contact from the payment
• Select a different contact

Error handling & special cases

• Incompatible payment information: It is possible that users try to add or import payment information that the Bitcoin Core App does not support (e.g. BOLT12 offers).

[GBKS]

Thanks for the write-up. I see what you describe as a future version of the feature, since it requires changes to the database and such. I think it would be good if we define & design at least two versions of this. The first one with the data we have, and the second one the future vision. We might be able to lay some solid foundations with the existing logic, and breaking things down will make for smoother development and review.

The contacts page in the design guide also has a lot of these interactions well-described. We can borrow from there.

I am curious if this label-only based stuff is due to BIP-329?

[rabbitholiness]

Agree, it's more of a forward looking topic in general. I guess we will come back to it once we're further along with more basic functionality.