Change Format

[mistermoe]

Summary

Changed the DAP format to:

Rationale

@moneyball highlighted an interesting observation that a handful of paytag projects have all snapped to an email-like format (e.g. BIP353, UMA, Lightning Addresses). Many of the concerns surfaced in #9 were raised and discussed at length within the communities working on these projects. In one way or another, all of them landed on the same general format. Given that this format has effectively become established, straying from it introduces the risk of "backwards incompatibility".

By compatibility, I mean if someone has established handle@domain as their “universal money address” be it via a Lightning Address-based product or a BIP353-based product, it’d be nice if if later begin using a DAP-based product, that they don’t need 2 different universal money addresses they share with friends, family, or the world. They’d just continue to use handle@domain.

One of the first and foremost motivations behind DAPs is making it easier to pay others. Introducing the potential for individuals to remember drastically different paytag formats puts simplicity at risk.

The concept of sending payments to someone's email address has been around for several years now dating back to the very beginning of paypal and x.com which means the act of paying an email-like handle has likely become familiar for many people. This makes an email-like format appealing and challenging at the same time.

An explicitly distinct format was chosen for DAP in order to reduce the likelihood of introducing incompatibilities or complicated UI/UX to decipher between an overloaded format for apps that already support sending payments to email addresses.

This PR attempts to strike a balance between competing factors by proposing a format that remains nearly identical to email addresses with the addition of a + at the beginning in order to allow for programmatic and visual differentiation.

We're effectively binary searching our way to the sweet spot. we started with: handle@domain then moved to @handle/domain and have now landed somewhere in between at +handle@domain.

hats-off to @cwmyers and @moneyball for surfacing all of these considerations.

[millyrowboat]

I know it's pedantic, but was @handle@domain.com considered? Users are more familiar with the @handle tagger due to social media

[decentralgabe]

it's still a valid email address, if we're trying to avoid that conflict. certainly some domain providers (like google, fast mail) allow for + to create 'sub-emails'.

https://security.stackexchange.com/questions/65244/what-are-the-security-reasons-for-disallowing-the-plus-sign-in-email-addresses

if DAPs are to be distinguished from emails and be their own thing, while still being associated with a domain, then they should have a different structure. there is also the thought of associating a DAP with multiple domains, but then we get into problems of conflicts (i.e. person A has a DAP registered with sites a.com and b.com and person B has a DAP registered with c.com and d.com).

I'd recommend something like:

dap:handle:domain.com to avoid all conflicts

this does not prohibit nicer abstractions in certain platforms. if cashapp adopts DAPs then $handle could expand to dap:handle:domain.com

[jiyoonie9]

we could do $handle@domain.com since having $ in the local part would make it an invalid email address, but also signals that it's a money-related-thing?

probably not the most global money friendly way to represent daps though, since other symbols ₩ or ¥ exist

also hard to spell out?

[cwmyers]

@jiyoontbd as far as I know $ are valid email addresses. I know I see things through a cash app lens but $ is part of the cashtag which complicates our UX considerably. The UMA crew have also gone with a leading $ which again adds to the confusion.

[jiyoonie9]

oh! i was thinking of gmail that allows + but doesn't allow other special characters, but they're more restrictive than the spec.

TIL the spec for local part of the email address seems to be quite forgiving, so maybe it's difficult for us to come up with something that looks and feels "intuitive" like email but won't validate as a real email address.

[mistermoe]

I know it's pedantic, but was @handle@domain.com considered? Users are more familiar with the @handle tagger due to social media

i don't think it's pedantic at all @millyrowboat! it's a great point. totally open to it as well if others are. i was basically looking for any character that has a very low likelihood of being the first character in an actual email address.

interestingly enough, for different reasons, i came across the same exact post @decentralgabe linked (for different reasons) and then tried to use + myself when trying to create an email address with 3 different providers (none allowed it). i imagine the same is likely true for @. the other reason + came to mind is because + made me think: "the person who's getting paid will have more money aka +"

also considered: >moegrammer@didpay.me with the > acting as an arrow / direction of payment

[mistermoe]

it's still a valid email address, if we're trying to avoid that conflict. certainly some domain providers (like google, fast mail) allow for + to create 'sub-emails'.

https://security.stackexchange.com/questions/65244/what-are-the-security-reasons-for-disallowing-the-plus-sign-in-email-addresses

if DAPs are to be distinguished from emails and be their own thing, while still being associated with a domain, then they should have a different structure. there is also the thought of associating a DAP with multiple domains, but then we get into problems of conflicts (i.e. person A has a DAP registered with sites a.com and b.com and person B has a DAP registered with c.com and d.com).

I'd recommend something like:

dap:handle:domain.com to avoid all conflicts

this does not prohibit nicer abstractions in certain platforms. if cashapp adopts DAPs then $handle could expand to dap:handle:domain.com

@decentralgabe parts your comment are very similar to the rationale @cwmyers surfaced awhile back and consequently what motivated the initial change from handle@domain to @handle/domain

Concretely, the primary concern with using an email-like format can be seen in apps that already support sending payments to email addresses e.g. zelle, cashapp, paypal, venmo

Additionally, certain countries have adopted email-like paytags (e.g. India's UPI VPA).

what sort of challenges will apps like the ones show above run into if they were to adopt DAPs? ideally, the format would be distinct enough so that an app wouldn't have to waterfall hit test (aka make network request to resolve) your way through overloaded email formats in some presumed order and just use the first one that works. This challenge can be avoided entirely if the DAP format is guaranteed not an email address as you suggest.

On the contrary, would a non-email format be a non-starter for some apps to even consider adopting or embracing DAPs? siting reasons like "2 distinct formats introduces cognitive overhead and confusion for individuals." Honestly, it's hard to say without empirical evidence. it could really go either way

@moneyball claims that a non-email format would make DAPs an absolute non-starter for Bitcoin only wallets given that the pre-existing paytag efforts in the Bitcoin community are all email formats. Candidly, even with email formats, a point was made that Bitcoin-only wallets would likely only adopt DAPs if their hands were forced via broad adoption in multi-currency wallets.

it's worth mentioning that DAPs are not a BTC-only solution, and further, aren't attempting to compete with existing efforts given that DAPs can easily support BIP353, lightning addresses, UMA etc. as money addresses. An argument could therefore be made that what a single community thinks needn't impact the format chosen for DAPs.

Personally, i'd like to see DAPs work or be considered in Bitcoin-only wallets because i genuinely hope i can provide people with a single paytag to receive all of the currencies I use, BTC being one of them.

Back to the concrete issue at hand, an email-like format with the first character decreasing the likelihood of a DAP being considered an actual email address does put us in a place where multiple formats can be supported with a single input without making an outbound network request. consider an app attempting to support sending to the following formats:

• $moegrammer: cashtag
• +moegrammer@didpay.me: dap
• $moegrammer@uma.me: uma
• ₿moegrammer@dnssec4lyfe.info: bip353
• moegrammer@aol.com: email
• Moe Jangda: name / contact

For all formats that match an email regex, the first character can be used to distinguish what kind of paytag you're dealing with, leaving actual email as the last case (note: ln addr would collide with actual email because there is no special first character for ln addresses)

Unfortunately, we don't get a deterministic guarantee that collisions won't occur, we're relying on probability.

Ultimately, if DAPs are worth consideration, i'd heavily value the opinion of the first large multi-currency app that decides to run with them should the opportunity arise given actual empirical evidence outweighs everything else IMO.

[decentralgabe]

thanks for the additional helpful context @mistermoe

@moneyball claims that a non-email format would make DAPs an absolute non-starter for Bitcoin only wallets given that the pre-existing paytag efforts in the Bitcoin community are all email formats. Candidly, even with email formats, a point was made that Bitcoin-only wallets would likely only adopt DAPs if their hands were forced via broad adoption in multi-currency wallets.

If DAPs are worth it, they'll adjust. If our success hinges on near-term BTC adoption, we must adjust. My gut instinct is that supporting email formats for this bet alone is not sufficient to make it a clear choice.

Having an email-like format doesn't address the underlying need for a distinct, versatile identifier....and they also come with their own baggage of expectations and limitations, which could constrain the potential of DAPs in the long run...like:

• (as discussed above) the use of special characters like '+' or '.' in email addresses can lead to parsing issues, especially when trying to differentiate between various types of identifiers.
• potential security risks...as the security model of DAPs is not the same as email, which could cause confusion or at worst security errors.
• email addresses are often tied to a person's identity, which might conflict with desires for pseudonymity in some payment scenarios (this is a general argument I make against tying DIDs to payment mechanisms, my identity and my financial life do overlap but should be distinct and treated with different privacy/security measures)
• the domain part of an email address implies a centralized authority ... which is how DAPs operate today, but could preclude a more decentralized approach in the future if we're reliant on domains
• having an email-like format might lead users to conflate DAPs with actual email addresses, causing confusion about their purpose and functionality
• many services already use email-like identifiers for various purposes, potentially leading to conflicts or confusion when introducing DAPs into the same space--this is a question of how unique and human friendly we want to be

For all formats that match an email regex, the first character can be used to distinguish what kind of paytag you're dealing with, leaving actual email as the last case (note: ln addr would collide with actual email because there is no special first character for ln addresses)

This is true, but seems to have a few potential issues (as you note):

• There is no guarantee that the first character is unique to a specific pay tag -- we already see overlaps with emails -- and venmo/paypal address both start with @ even if they expand to globally unique identifiers
• First characters, or making a distinguishing identifier as part of the name itself could be confusing, since users normally choose their identifier ... could also result in platform specific conflicts as mentioned w/gmail, etc.

We can take the spirit of what you're suggesting but separate it out to reduce these risks with a structure like dap:$:abcd or something similar. A more unique syntax. It's unambiguously parsable by software, reducing the risk of confusion with other formats. It also clearly signals to users that they're dealing with a DAP, not an email address or another type of identifier. This clarity could lead to smoother user experiences and fewer errors in payment routing.

Backing up for a second -- I am viewing DAPs as something not in the same category as cashtags, uma, bip353, but a layer above them. They should be able to point to many payment identifiers. That also warrants a new syntax because they're at a higher level. A DAP pointing to a BTC address, an ETH address, a Cashtag, and a traditional bank account should be clearly distinct from a single purpose identifier like a UMA or BIP353.

Long story short, I support a non-email-like syntax for DAPs. It seems to be the most future-proof, versatile, and unambiguous approach, even if it may require some user education.

[wilsonianb]

DAPs are reminiscent of Interledger's payment pointers, which involved similar formatting considerations: https://github.com/interledger/rfcs/pull/367#discussion_r161389438 https://github.com/interledger/rfcs/pull/367#issuecomment-358276527