Would this implementation be a new library, or a PR to an existing library like stacks.js?
Or, some other solution entirely i’m not thinking of?
This was actually brought up in a SIP call last week i think (i had been seeing the same requests in the community for a feature like this), and, like you, i see this as very possible today - but it’d be great to get ahead and standardize how it’s done.
The approaches you’re referring to seem good to me, but i’ll dig in a little deeper to see if i can find any issues with what’s being proposed. overall, it’s very similar to what i was thinking of as a potential SIP - but offloading this work to a library or something makes more sense.
Thank you for drafting and sharing this Larry! I think this is so important for BNS and Stacks. Would love to hear from others in the ecosystem. Xverse is definitely interested in implementing this standard.
Question - does this need to be a SIP or should BNS have it’s own improvement proposal process BNSIP?
Since it is applicable to more than just the BNS/bitcoin ecosystem, my first instinct would be to make a new library. Something that akes a zone file as an input, has some functions to manipulate (add/remove/update) the addresses the name points at and then outputs the zone file. Library developers could choose to integrate this functionality into their libraries if they want but wouldn’t have as long as it gives developers access to the “raw” zone file.
We need more like this! Thank you for the write-up.
For this standard to get wider adoption, I think we need to solve the uniqueness of top level domains that users and wallets need to know when they want to resolve a name. Which blockchain/resolver service should they use for friedger.btc, friedger.bitcoin, friedger.fren, friedger.eth, friedger.de, friedger.id, blog.friedger? This is probably out of scope of the standard, but it should be mentioned that a mechanism should be established. Maybe https://chainagnostic.org/ is a place for that. web3domainalliance tries to create at least no overlaps between their members (like ICANN?).
Then once, the wallet managed to find the zone file which is the correct ticker that the user wants to use and that the recipient intended to publish?
In section 3.1 “Resource Record Namespace” the definition is left out.
coin’s ticker symbol name
Which ticker should be used here? ISO proposal “XBT” or commonly used “BTC”. What happens if a project/exchange decides to change a ticker. Do all users need to change their zone files?
Some more stories about changing token tickers, e.g. at
Probably, similar results can be achieved with the use of did:web specification. The W3C (https://www.w3.org) published a recommendation in July 2022 to integrate into the DID a web reference in order to use the trust that users have in the Internet DNS, calling it did:web, to speed up DID’s adoption.
Specifically, while other parties might be used to help enable the discovery of information related to a DID, the design enables the controller of a DID to prove control over it without requiring permission from any other party. DIDs are URIs that associate a DID subject with a DID document allowing trustable interactions associated with that subject. Some of this has been addressed here GitHub - paradigma-cl/dappprofile: Stacks dapp public profile
Then having trustable interactions the DID addresses can be used to transfer funds to domain names.
Thanks for sharing Larry, this is great. The Hiro Wallet will of course implement the standard.
Questions:
Are wallets expected to support DNS hosted names in addition to DNS names? Is there the possibility of naming collisions between BNS & DNS names?
Is it within the remit of the spec to discuss potential scope for abuse? Is DNS spoofing a concern?
Using a single address to receive funds has privacy implications. Would it be the responsibility of wallets to educate users of this? Are there any best practices to minimise divulging financial information? Should users frequently update their listed addresses, or is this futile as all addresses have at some point been public?
If we have a mapping from a name to a DID, then here is a proposal to use a DID document for specifying how to receive btc payments (using various methods with or without privacy protections) :
Agree it’s problematic and we’ve been punting on this for a while.
I personally think we should make BNS names look obviously not like ICANN DNS names…but that’s a discussion for another day (or at least another thread).
I think it’s just by convention. BTC refers to whatever there’s consensus around. Yes, all users would have to change their zone files. This increases the cost of changing - which is a good thing.
It sounds like this would require running a web server separate to and in addition to a stacks node or a DNS server? I might be reading it wrong?
Some of good suggestions re privacy here. Can we use DID documents without running something in addition to a stacks node (for BNS) or a DNS server (for ICANN DNS)?
I wouldn’t expect stacks wallets to support DNS names.
This is one reason I wouldn’t expect stacks wallets to support DNS. This isn’t an issue with BNS.
@light shared some suggestions on twitter to improve privacy which we can further investigate and perhaps add as either recommendations or requirements.
There was early support for DID in stacks-node some time ago. However, I don’t see any proposal to make use of the already developed did:stacks method. It is there ready to be used!
Yes, dapps could provide the service of displaying a DNS profile using the did:web spec. Example: in a matching did with DNS name, like did:web:phillip.xck.app could serve providing did.json and profile.json files using a web calls Profile Crosscheck and Profile Crosscheck Also web presence if necessary as https://phillip.xck.app
Additionally, if did does not match a DNS name, like did:stacks:phillip.stx could be served as Profile Crosscheck so the did:web will did:web:my.xck.app/phillip.stx having the possibility to retrieve both files as Profile Crosscheck and Profile Crosscheck and web presence as Profile Crosscheck
