Contact page updates to mention new protocols #1173
Conversation
✅ Deploy Preview for bitcoin-design-site ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
| @@ -216,13 +209,24 @@ Let's go over common user interactions around managing contacts. This will illus | |||
|
|
|||
| --- | |||
|
|
|||
| Whether we’re sending emails, physical mail, or following someone on social media, we primarily think in terms of names and faces, and not the respective address or user ID. | |||
|
|
|||
| Addresses, invoices, node IDs and other transaction endpoints in bitcoin and lightning are highly unintuitive. Abstracting them via a contact list can create a much smoother user experience. With the advent & growing popularity of reusable payment request formats such as [silent payments]({{ '/guide/how-it-works/silent-payments' | relative_url }}), [bolt-12]({{ '/guide/how-it-works/payment-request-formats/#offers' | relative_url }}) and [BIP-353]({{ '/guide/how-it-works/human-readable-addresses/#bip-353-dns-payment-instructions' | relative_url }}), bitcoin's interaction model itself can be centred around contacts. There are many [formats]({{ '/guide/how-it-works/payment-request-formats/' | relative_url }}), each with unique properties and varying levels of maturity and adoption, requiring unique design solutions. This page uses the more approachable term "address", along with various UI techniques, to abstract these complexities for users. | |||
There was a problem hiding this comment.
bolt-12 is all lower case here and has a dash, but in the payment request formats it's displayed as BOLT 12. I think it's usually stylized like BOLT 12.
There was a problem hiding this comment.
Not sure about the user of the ampersand in "advent & growing". It stuck out to me as odd. I would look into the suggestions on when to use that instead of and and see if it makes sense.
There was a problem hiding this comment.
Some copilot feedback, feel free to use what you like or just discard it if you don't like the suggestions.
Suggestions for improvement:
- Replace "&" with "and" for formal writing.
- "Centred" is correct in British English, but "centered" is American English (choose based on your audience).
- Consider breaking up the third sentence, as it is quite long.
- Clarify "bitcoin's interaction model itself can be centred around contacts"—it can be reworded for clarity.
- The last sentence is a bit wordy. Consider making it more concise.
Revised version:
Addresses, invoices, node IDs, and other transaction endpoints in Bitcoin and Lightning are highly unintuitive. Abstracting them via a contact list can create a much smoother user experience. With the advent and growing popularity of reusable payment request formats—such as [silent payments]({{ '/guide/how-it-works/silent-payments' | relative_url }}), [BOLT-12]({{ '/guide/how-it-works/payment-request-formats/#offers' | relative_url }}), and [BIP-353]({{ '/guide/how-it-works/human-readable-addresses/#bip-353-dns-payment-instructions' | relative_url }})—Bitcoin’s user interactions are increasingly focused on contacts rather than technical addresses. There are many [payment request formats]({{ '/guide/how-it-works/payment-request-formats/' | relative_url }}), each with unique properties and varying levels of maturity and adoption, requiring specific design solutions. Throughout this page, we use the more approachable term “address” and various UI techniques to help abstract these complexities for users.
| You may choose to require [user verification]({{ '/guide/daily-spending-wallet/security/#preventing-unwanted-access' | relative_url }}) (like PIN entry) when adding or updating contacts. This reduces the risk that contact information is tampered with and payments are sent to wrong addresses. | ||
| {% include tip/tip.html %} | ||
|
|
||
| Consider requiring [user verification]({{ '/guide/daily-spending-wallet/security/#preventing-unwanted-access' | relative_url }}) (like PIN entry) when adding or updating contacts. This reduces the risk that contact information is tampered with and payments are sent to wrong destination, especially with re-usable addresses. |
There was a problem hiding this comment.
I don’t agree with this tip. I actually think it’s a suboptimal UX practice. Introducing PIN verification for adding or updating contacts seems like a very odd convention and adds a lot of unnecessary friction.
If I understand the threat model correctly: someone gains access to your unlocked phone, opens your Bitcoin wallet, and attempts to do something malicious. In that scenario, the most likely threat is that they would simply send the funds to their own wallet. Requiring a PIN to confirm a fund transfer would be a useful security measure. But the idea that an attacker would instead go through the process of editing your contacts so that a future payment gets misdirected seems far less plausible.
I don’t think that attack vector justifies the added friction of requiring a PIN or user verification for adding or updating contacts. Labeling this as a “tip” feels misguided imo.
There was a problem hiding this comment.
hmm if the app entry itself is protected by a PIN or biometrics, this might not be needed at all...but yeah adding/edit contact is a one-time thing but I see your point about friction. pinging @GBKS
There was a problem hiding this comment.
I agree with the criticism in the context of the daily spending wallet. This may be relevant in a treasury setup or so where there are huge amounts at stake. Editing a contact there may be the simpler route to cause mischief, than figuring out how to do a multi-sig approval.
Fixes #1152
🖥️ Preview