Explore human-readable payment addresses #638
Comments
|
I am a big fan of human-readable addresses for bitcoin. Dramatic improvement to usability and mass-market appeal. On the surface, email addresses are appealing (as they have achieved pervasive use & recognizability) but I feel there are two problems with this approach that I'm not sure can be overcome: (1) Email and money-receiving are decidedly different use cases, and thus carry with them different degrees of user expectation with how comfortable one would be with sharing an address publicly, i.e. spam is a consideration for email (I don't want to invite random people to send me garbage communications) whereas spam is not a concern for money-receiving (I would be happy to have anyone send my money, there is no downside) and as such people will be more comfortable sharing a money address more publicly than they would an email address. (2) Until the time where all email addresses can receive money (a long, long time from now) we suffer a cold start problem that adds friction and confusion to the user experience. For instance, I happen to know the email addresses of my N friends but I do not know if their provider / host has configured their address to receive money. So I either have to speculatively try to send and/or ask them outright if I can send them money, which is an annoying hurdle that will result in failures, confusion and friction to adopt. For both these reasons, I think it is better to have a slightly different address scheme that makes it very clear the address is designed for receiving money and will work 100% of the time. I think the UMA protocol that prefaces the address with a "$" is a reasonably good alternative. I'd be curious what other options folks can think of? |
|
A couple of further thoughts:
|
|
We've been throwing around some UI mock-ups for different scenarios in the ux channel in Discord. I'm thinking it might be helpful if we add a page about human-readable addresses in the guide, possibly under contacts. Might help simplify implementation if there are already some well thought-out patterns. This page could cover a general approach to this problem that includes the proposal discussed here, Lightning Address, and others.
|
|
As for the format, I like @matbalez reasoning. |
I'd argue that one benefit of having user-readable names is that they can be remembered and then typed out from memory when needed. If the address introduces characters not available on any ANSI or phone keyboard, this would not be possible. |
|
Totally. Some of the mock-ups above try to address this, like letting users just hit Space to type a ₿. By the way, I mapped |
Yeah, although such split fields can be pretty annoying, especially if they end up breaking copy/pasting etc. (Which they usually do in some way, even if devs try to work around it). IMO, ANSI-keyboard compatible delimiters are much preferable to requiring such workarounds which might work completely differently in each app or website. |
|
As a European, I prefer ISO-compatible keyboards 😉. Just kidding, I get your point about easy typing. Here's a CodePen to test this interaction (Space -> ₿). Just a few lines of code and feels very smooth (at least on my devices). Copy/paste should not really be a thing here due to privacy (not copying this address in the first place) and automated clipboard detection (and automatically suggesting appropriate options). One of the ideas I threw out in Discord was to avoid the |
It's not only about easy typing but also about working the same expected way everywhere. Btw, I'm European, too, but deliberately gave ANSI as an example as it is the most common subset of characters available.
Sure, but how would I type it in my shell? Or in an email not implementing this custom code? Or literally anywhere else?
Yes, it is. Please don't make such assumptions. Password managers use copy/paste or form filling all day long and breaking such automated input methods is a pain.
How would that discern the address from just another subdomain? Also, it would limit usernames to be single words only, i.e., dots would be disallowed? Not sure if that would be the right way to go, but If you're looking for a URI-like scheme, you might want to use |
I believe this was a reference to the discussion in the UX channel describing copy of human-readable names should actually copy the underlying bitcoin: URI. One of the major drawbacks of human-readable addresses is the fact that they move noncustodial wallets distinctly into custodial territory. Thus, non-custodial wallets may want to display a human-readable address, but when the user hits copy it should actually copy the noncustodial version of it. I agree with you on the paste side of things, however. |
Yes, of course, the idea here was for strongly optimizing for in-person communication, likely someone typing into a mobile wallet. If we don't want this to be used otherwise as much because of privacy and security, it might even be good if it's hard to type into a shell or email. Maybe the resolved payment information is more appropriate in those contexts...? I'd also say that everything we do here is forward-looking. Why not speculate a bit on a future where ₿ is easily accessible on keyboards, like other currency symbols? For example, holding down the $ symbol on my iPhone keyboard, I have quick access to 6 additional currency symbols, including the South Korean Won (₩). Not really useful. Maybe ₿ could sneak in there? Maybe having a standard that uses it could help make it happen? It has to start somewhere after all...
Password managers should not be affected by this. They can work as they always do.
Couldn't you just look for the first occurrence of If we forget about all the technical compatibilities that things like URLs and email addresses require, and just think about what works well for verbal communication/memorization, maybe we have more options? Maybe we do, maybe we don't, I'm just trying to see what's in that direction. Thanks for entertaining the train of thought. |
|
Such an interesting thread to read, and then even another thread on another Github page. Read through some of the comments and made a summary of the main ideas:
The people who we build bitcoin products for if we want them to trust bitcoin as a solution then this provides a higher level of trust regardless of which approach is adopted. Reading the other thread there are behind the scenes technical discussions that are had around implementation. I appreciate that those are very real challenges. The main question I would ask is:
The human part of this comes into mind the most. I'd imagine two people having a convo and one would say send me some bitcoin. Sure what's your address? The address of the person is: alicejohn₿walletx.com That feels fairly simple to remember and with the addition of adding that to contacts it would be a simple search and send to pay that person a second time. The more symbols we add in there the more difficult it will be for someone to remember. Challenge: This one also comes up from a convo with the silent payments dev is: What if there are two or 3 Alice Johns in he world? There would need to be some verification that Alice John 1 provides to ensure that its sent to the correct Alice. No real strong opinion on this topic, being the researcher I'd throw out a poll to the ecosystem and ask the people to vote on what they feel would work best. This also put the power back into the hands of the people. Suggest 2 or 3 options to them and have them present us with their fears + questions around both approaches. Their fears + questions would lead to them not adopting the solution based on reasons xyz and would show the mostly likely solution that would be adopted. At the same time the Bitcoin Design Guide is forward thinking and many of the solutions in there are not seen in the wild "yet". And so if the guide did create a solution it could always be modified based on when wallets start adopting it, the real challenges and solutions would emerge. |
|
I've iterated on the Google Doc, with the idea that this turns into a page on the design guide that lays out the general problem to solve, how to think about it, basic technical ideas, proposed options, UX considerations and mocks, etc. I also recorded a video to go over the current draft status and would love to get your feedback on everything. Here's the document and the video. |
|
I just created a pull request for a new page in the guide on this topic. Would love it if you could take a look and share all your fantastic ideas for improvements. |
There's a new proposal for human-readable payment addresses that sparked new conversation around a topic that has been around for a long time. It would be fantastic if we could explore this as a community/ecosystem from a UX perspective and come up with recommendations. See this thread on Discord.
A primary topic of discussion here is the format of these payment addresses. Is it best to go with the established email format that is globally recognized and people know how to read, write, and use? Or is it confusing, the link to email problematic, and better to go with a different solution? What's best for quick adoption vs a desired end state? Let's come up with a good way forward.
The text was updated successfully, but these errors were encountered: