Adds new page about human readable addresses #1082
Conversation
This is something we've discussed for a few weeks in the UX channel in Discord and turns the findings into a page. 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 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.
GBKS
added
Copy
✅ Deploy Preview for bitcoin-design-site ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
|
Hi, Chris! Looks great so far, but I have a few issues:
|
Co-authored-by: Johns Beharry <[email protected]>
|
Thank you for the super-fast feedback.
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.
There was a lot of discussion around the Also, did you just mention using a sat symbol? 😉
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.
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. |
|
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. |
|
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? |
Co-authored-by: Johns Beharry <[email protected]>
Co-authored-by: Johns Beharry <[email protected]>
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. |
|
The "B" symbol is a recipe for frustration, and setting up normies for failure.
Why limit the design space of what users can, and can't do?
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 |
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.
Totally. The page mentions "read, memorize, pronounce, understand, and type". |
- Added note about the DNS proposal still being in discussion - Updated general how it works image to use [prefix] instead of ₿ - Added note about PayNym directory not being open-source, and removed note about not using it due to centralization (should be clear from reading the text whether to use it or not)
assets/images/guide/how-it-works/human-readable-addresses/[email protected]
Outdated
Show resolved
Hide resolved
assets/images/guide/how-it-works/human-readable-addresses/setup.png
Outdated
Show resolved
Hide resolved
assets/images/guide/how-it-works/human-readable-addresses/[email protected]
Outdated
Show resolved
Hide resolved
|
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:
|
Co-authored-by: Stephen DeLorme <[email protected]>
- The proposal has been assigned a BIP number in the mean time, so I updated the URL - Clarified the use of the term custody as it relates to addresses - Removed an incorrect sentence about caching - Clarified that the proposal supports two formats, due to the optional ₿ prefix - Added note how single-use addresses can be used, as long as there's a rotation mechanism in place - Simplified note about responsibility to be more general, rather than mentioning legal and financial aspects. Lightened up that sentence generally - Added note about informing user of changed payment info at time of initiating a payment - Minor copy tweak in lightning address intro paragraph
|
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. |
|
Strike now supports BOLT12 and DNS-based human readable addresses, along with Zeus, Phoenix and others (full list on bolt12.org). Posting this here, due to the editorial question about proposals with little or no adoption. More adoption over time speaks in favor of this content. |
Concur with Phoenix and Strike support, BIP-353, has decent adoption now. I'd go further and say Proton Wallet's "Bitcoin via email" is the biggest step thus far in the direction of human-readable addresses and should be added to this page as an example. |
|
Selfie Records extends BIP353 with additional data types. Another sign of adoption. Nonetheless by Synonym, so it sounds like @BitcoinErrorLog may have embraced it as well.
@yashrajd, this seems like an internal solution by a private company, and not an open standard, right? Not sure that really belongs on the page, unless there's more to their way of doing things. |
|
fwiw we are not currently pro- or anti-Selfie Records. The project was made by a motivated team member and we thought it was a good way to express capabilities DNS always had, to frame the design space clearly. All namespaces that want to enforce uniqueness (squatting) require a central authority, but that does not negate that some people find it useful and are willing to take that risk to solve what they consider to be problems, despite its censorability and difficulty for individuals to self-manage. Our actual love letter to decentralized identity, routing & payment coordination is PKARR (and Paykit, but R&D for that is paused til January) https://github.com/pubky/pkarr -- All of the public keys and endpoint records people want to be putting in DNS or relays or such should be put into Mainline DHT with PKARR. Because it is objectively the most decentralized and resilient network on the internet afaik. Projects like Iroh and Web5 are already using this setup, but Bitcoiners typically prefer bitcoin/LN-dedicated solutions. PKARR doesnt need blockchains or bitcoin keys. We still arent sure whether/how we might support Selfies in our own products, but we have a bookmark on approaching the "nickname" problem ideally/holistically someday if it seems needed. Sorry for shilling, but we wouldn't be building these things if we didn't think they were the best solutions :) |
|
The self-hosted/DIY path will add a lot of friction, and I don't think many people own personal domains. It may be something more suited to people running businesses/merchants/freelancers etc. Feedback from the Phoneix implementation suggests users are having a few issues https://x.com/methobit/status/1811496354549760022 |
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🧐