Adds new page about human readable addresses

[GBKS]

This is something we've discussed for a few weeks in the this issue and the UX channel in Discord and turns the findings into a page.

Primary focus of the page is on the DNS-based payment information proposal, with an additional paragraph about Lightning Address and a small note about PayNyms.

The UI mock-ups are more directional than implementation-ready, which I think is fine. But we could flesh this out further in a revision at a later point.

I think there's more work to do in cross-linking this from all the right places. I updated a few spots, but there's probably more. The page is at a point where more review and public feedback would be helpful in identifying missing and incorrect bits.

If you have criticism of the DNS-based payment information proposal, please post it in that PR, and not here. This page is a reflection of the logic described in that PR.

🧐Check the preview🧐

[netlify]

✅ Deploy Preview for bitcoin-design-site ready!

Name	Link
🔨 Latest commit	8734a1e
🔍 Latest deploy log	https://app.netlify.com/sites/bitcoin-design-site/deploys/667439045e61a000070e2806
😎 Deploy Preview	https://deploy-preview-1082--bitcoin-design-site.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[BitcoinErrorLog]

Hi, Chris!

Looks great so far, but I have a few issues:

1. Use of ".btc" as an example, which is a Stacks-oriented tld. Stacks is kind of a scam, and while non-ICANN domains are totally possible, this adds some nuanced confusion, particularly in that there can be many different namespaces with overlapping TLDs.

2. the B prefix is not practical or necessary.

• Domains already have a prefix scheme with dedicated subdomains, ex: [email protected]
• The B symbol is an uncommon impractical, non-keyboard character
• This (nicknames for specific endpoints) is not a Bitcoin-specific problem so shouldnt be isolated as one (why not use a Sat symbol, or $, or Eth symbol, or a common keyboard character, etc?)

3. While I have no special care for/against Paynyms, it seems odd that the text here is so dismissive about it and centralization when all of the other patterns on this page require it too.

4. While it is interesting to show UX for helping users set up their DNS TXT entry and their own self-hosted payment address, this is a very unlikely pattern, particularly in mobile. Most people wouldn't do this and use a trusted provider, and such likelihood and risk are important to focus on.

[GBKS]

Thank you for the super-fast feedback.

Use of ".btc" as an example, which is a Stacks-oriented tld. Stacks is kind of a scam, and while non-ICANN domains are totally possible, this adds some nuanced confusion, particularly in that there can be many different namespaces with overlapping TLDs.

Thanks for pointing that out. I just pushed a commit updating the sample domains. I had checked whether there are official .btc domains, but was not aware of this "other" use.

the B prefix is not practical or necessary.

There was a lot of discussion around the ₿ prefix, and I also asked various people directly. From what I heard, the opinions seem to be really split with no clear majority/consensus. Personally, I agree with the trust argument. The prefix makes it 100% clear that it's a bitcoin address and nothing else. For a casual user, who is not aware of the technical realities of what can and can't go wrong when mixing up emails and bitcoin addresses, this might be an important signal. But I also understand the other way of approaching this argument. Is the better place to discuss this in the original proposal, which this page follows?

Also, did you just mention using a sat symbol? 😉

While I have no special care for/against Paynyms, it seems odd that the text here is so dismissive about it and centralization when all of the other patterns on this page require it too.

True, it is pretty dismissive. But PayNyms is basically a single database, while the other proposals do their best to decentralize, but are bound by the "basic infrastructure of the internet". Ver different ends of the spectrum to me. But if it is too dismissive, then it should be revised.

While it is interesting to show UX for helping users set up their DNS TXT entry and their own self-hosted payment address, this is a very unlikely pattern, particularly in mobile. Most people wouldn't do this and use a trusted provider, and such likelihood and risk are important to focus on.

Agree, this needs more fleshing out. I mention in the page that the UI mocks are conceptual, and I'd like to take more time to discuss and sort this out. I still have some open questions, but also wanted to get this page out.

How do you think this will play out? Dedicated bitcoin address services like we have in Nostr for NIP-05 identifiers?

Thanks again for the feedback.

[BitcoinErrorLog]

With Paynyms, I'm a bit too ignorant, but I'm skeptical they are any more centralized than DNS. All namespaces require an authoritative list to exist somewhere. And anyone can host a new list, or query any existing list they want to. Centralized/decentralized isn't really the correct paradigm for namespaces.

Regarding how I think this will all play out, well, I think it is all moot tbh, and that such things are a fad born of ignorance. No one needs nicknames at a protocol level, they are app-level concerns and thus should be rendered in contact list UX. Domain names are a scam, and thus pay-names follow in kind. This is my, likely unpopular, opinion, so it could also be wrong :)

Think of DNS more like a list of phone numbers. I can either make a list myself, or trust someone else to provide a list (like a phone book/directory), but the difference is all about there being a trusted authority, thus solutions that do not require such an authority are more interesting, or, solutions that aggregate many lists, etc.

If a user wants to pay "Mom" they should be able to just tap on Mom's face, not type in her fake email address into some novel UX.

[johnsBeharry]

PayNyms are perhaps a bit more centralised than a DNS based option solely cause more people host the DNS to HTTP resolvers (1, 2, 3), and such resolvers are open source. With PayNyms only samurai maintain a registry and doesn't look like they have open sourced it.

[sbddesign]

I don't see the value in using the B symbol (which I frankly don't even know how to make with my keyboard). Can somebody educate me on the dangers of mixing up an email address and a bitcoin payment identifier?

[TheBlueMatt]

I don't see the value in using the B symbol (which I frankly don't even know how to make with my keyboard). Can somebody educate me on the dangers of mixing up an email address and a bitcoin payment identifier?

To be clear, the keyboard issue shouldn't be an issue - it should be displayed and in a copy (if wallets allow copying the human-readable names directly, though generally they should prefer to copy the underlying payment instructions for noncustodial wallets), but users shouldn't need to type it.

The reason its there is because payment instructions are a different namespace from email. We've already seen at least one case where a company uses their domain for emails and also to provide users with lnaddresses, with someone having the lnaddress who doesn't work for the company and doesn't have the corresponding email.

@moneyball thought we should have some suggestions to cache name -> (reusable) payment instructions mappings. Sadly, in some protocols (at least DNS) we have pretty tight timeouts for the data itself (eg the domain might expire tomorrow!), so it'd need to be a cache with a notice on changes rather than not doing further lookups. Can happen separately, but something to think about.

[alltheseas]

The "B" symbol is a recipe for frustration, and setting up normies for failure.

but users shouldn't need to type it.

Why limit the design space of what users can, and can't do?

The reason its there is because payment instructions are a different namespace from email. We've already seen at least one case where a company uses their domain for emails and also to provide users with lnaddresses, with someone having the lnaddress who doesn't work for the company and doesn't have the corresponding email.

That's fine - add some other way instead of an impossible to type "B" symbol.

There's "human readable", and there should be, in my view, "human typable". These are the most basic human machine interface requirements.

Normies will not memorize the special character shortcut for "B". We don't have "B" on keyboards today.

Really, anything else on the keyboard, or perhaps even on the more difficult to access emoji keyboard reduces user friction. The designers I'm sure can come up with something better.

Examples: BTC.name@domain
SATSname@
ZAPname@
LNname
🌽name@ (or any other emoji)

[GBKS]

The "B" symbol is a recipe for frustration, and setting up normies for failure.

To keep things a bit orderly, I'd like to ask for criticism of the proposal to be posted on the original proposal pull request. This new page in the guide is a reflection of the logic in that proposal. I'll also add this note to the PR description. Proposal criticism is not really something that can be resolved in comments here.

There's "human readable", and there should be, in my view, "human typable". These are the most basic human machine interface requirements.

Totally. The page mentions "read, memorize, pronounce, understand, and type".

[sbddesign]

Very good page. I'm glad to see this topic covered.

I went through and provided some thoughts: small grammar nits, one visual nit, and some technical commentary. Happy to jump on a call and discuss sometime if you like.

[mouxdesign]

Adding in some birds eye view ideas as well. More on the overarching structure of the content, less about the copy itself.

Reading through the content it forms 4 larger chunks:

• Introduction

• DNS Payment instructions

• Lightning addresses

• Paynyms

• Paynyms is also mentioned as a smaller paragraph right at the end, it would be good to mention it at the beginning in the sentence "On this page, we focus primarily on the DNS Payment Instructions proposal with some information about lightning addresses and Paynyms."

• The introduction has 1) The basic idea and 2) Address format and basics. With the section on security and privacy inbetween. It feels as if the two basics sections could be together here as they both lean into the format topic.

• Lightning addresses: There is the headings address format + how it works in DNS section. The address format is also mentioned right at the beginning of the lightning section so could be a possible heading there.

• Sharing screen design: A question that comes up here is how does a user know that one address is their private address and the other one their public address. If there is a way to make this more obvious on the design to prevent them for mistakenly sharing the wrong one.

[GBKS]

I think I addressed all feedback. There are some points around the UI visuals that I will address in a follow-up in #1083. Please take a look and let me know how it looks know. Now that conference season is over, I'd like to wrap this PR up at a good pace. Thanks in advance.