This proposal aims to enhance the current BNS zonefile configuration by integrating additional fields that provide a more comprehensive and versatile approach to defining digital identity on the blockchain. These updates will empower users with greater flexibility and interoperability while maintaining the integrity and simplicity of the BNS system.
Key Enhancements
Standardization of Profile Picture (PFP)
A dedicated pfp field should be standardized, allowing users to store an image URL or other supported formats. This field will enable seamless usage across all applications that integrate with BNS, ensuring a consistent representation of users’ digital identities.
Social Media Profiles as an Array
To improve scalability and usability, the current fields for platforms like Twitter and Nostr should be consolidated into a single social field. This field will consist of an array of objects, allowing users to include additional profiles from major platforms such as Facebook, LinkedIn, and others. For example:
Cross-Chain Address Support
To drive broader adoption of BNS, the ability to store cross-chain addresses should be integrated into the zonefile. This would include support for:
BRC20 and SRC20 addresses (already supported by wallets like Leather and Xverse).
EVM-compatible addresses to enable interoperability with Ethereum-based chains.
Solana addresses, reflecting potential collaborations like the sBTC bridge initiative mentioned by Muneeb.
By offering a cross-chain approach, BNS will align with the needs of users who interact with multiple blockchains daily, making it a more inclusive and future-proof solution. This multichain capability would also position BNS as an ideal candidate for integration into widely-used wallets like Phantom, which caters to Solana and Ethereum ecosystems, and platforms such as Magic Eden, a leading multichain NFT marketplace. These integrations would further expand the reach and utility of BNS, allowing users to seamlessly manage their identities and assets across diverse blockchain networks within a single, unified experience.
The proposed updates reflect the growing complexity and diversity of users’ blockchain interactions. A well-defined digital identity must cater to multi-chain needs, support mainstream social platforms, and standardize critical elements like profile pictures. These changes will not only improve the usability of BNS but also position it as a leading identity solution in the broader blockchain ecosystem.
I want to extend my heartfelt thanks to all the core developers and contributors who have tirelessly supported the BNS community. Your dedication and innovation continue to drive BNS forward, creating a stronger and more inclusive platform for everyone.
Thank you for considering this proposal, and I look forward to seeing BNS reach new heights.
BRC20/SRC20 addresses can be represented in the way the current WBIPS standard proposes (‘payment’, ‘ordinals’), but we should also keep the standard open to new networks… maybe something like:
the model proposed by @dant it’s simply perfect. it fits with wallets requirements and enhance actual zonefile.
the question now is how we should proceed. On the technical side the contract is ready to receive the upgraded model (it’s a buff of a json file) but we need to find an agreement on the model itself.
Don’t think a SIP is required, bc current BNS v2 is a normal contract, but IMO it will be better to have a SIP vote to certify the consensus on this new approach. So i would like to hear more opinions if we need a SIP or not.
Yeah i’m in favor of a SIP for something like this so that apps across the ecosystem can ensure that profiles will work in the same way.
In terms of proceeding, I think we need more feedback … at minimum, I think we want setzeus and/or setpato to chime in on any issues or limitations first
I asked to Setzeus. The problem is not changing the json output of the zonefile, but we both want a shared decision, a SIP or what best fits this request.
with BNSv1 zonefiles used to be RPC complaint, which allowed storing DNS data in them, used by the webbridge on btc.us for example. Simple redirects are still possible but solutions that require more sophisticated DNS record changes are not supported at the moment (such as A and CNAME records to allow for https://non-fungible.btc.us ). This felt like a step back to me. Would the standard suggested here address this limitation?
That RPC compliance was dropped with BNSv2 although it could still be added again, perhaps an alternative is even better? I believe Phillip.xck.app was surprised by this too and I understood from the Tintash team that although there is no standard for zonefiles at the moment there are provisions to establish such a standard and adopt it in the future.
I am in favor of establishing BNSv2 in a SIP (even if after the fact of deploying and some adoption) as well as a SIP for zonefiles for BNS(v2) names. Having a sip for the latter can also solidify future BNS upgrades keep adhering to it for backward compatibility.
This is a summary of my findings and my suggestions about the topic.
The decentralized digital identity space has been evolving very fast.
The development of digital identity registration in the Blockchain by Blockstack (now Stacks) was a pioneer in this space. The original purpose was to resemble the Internet Name System (DNS) more specifically as a Fully Qualified Domain Name (FQDN), in a real decentralized way. The DNS hierarchy was defined with five levels. The DNS hierarchy originates with a Root level, resembling it in the Bitcoin Name Service (BNS) as the smart contract and its owner.
Situated just below the Root level, are the Top-Level Domains (TLDs) resembling in the BNS as namespaces. Directly beneath top-level domains, second-level domains form the subsequent layer, resembling the BNS Domains. All the names registered using the BNS assure the immutability of the name. Only the owners or managers of a namespace, or domain name could change the properties in a Blockchain transaction.
Within the structure of Second Level Domains, the DNS hierarchy further extends to the Sub-Domains. It is a kind of categorizing content or users. Also, used to identify a particular device. In the BNS, the subdomain’s or host definition was considered to be defined off-chain. Originally in BNSv1, a list of the subdomain names associated with a domain name and zone file was maintained on-chain, but the adding, updating, or any changes were made by the domain name owner.
The experience of using the Decentralized names evolved the creation of the Decentralized Identifier Document (DID) and was considered by w3.org.
Stacks included it with the registration of a zone file associating it to name created, and its reference to the DID called https://…/1xxxx/profile.json
The zone file referenced by a decentralized name has a similar purpose as the DNS zone file, assuring that the decentralized name points to the hostnames, servers, etc. Assuring immutability and ownership.
The BNSv1 and associated services and API are still an excellent solution, but this version probably would have scalability issues when the number of users grows over time.
A new version was developed called BNSv2, mainly adding a better namespace management system, the possibility to exchange names easily, and the facility of creating a name exchange market.
This version discontinued the registration of a zone file associated when creating a name, its reference to the DID, and the registration of the subdomain names.
Nowadays there are many new solutions, but still, there is space to provide a leading solution based on the Stacks ecosystem.
The strategy is that we use the immutability of the names identifiers that brings BNSv2 in the same function as the Internet Domain Registrars.
Suggested next steps
Produce a SIP to define a common base to develop the possible applications:
Consider BNSv2 as it is, covering the function of a Decentralized Identifier.
For applications or users that need to extend the functionality of the decentralized identifier as a Verifiable Identity, to be able to create a DID referencing it in a zone file. This has to be on-chain and off-chain.
For applications or users that need to create personal profile data with its decentralized identifiers and DID in a decentralized web node. This has to be on-chain and off-chain.
For applications or users that need to extend the use of a domain name with subdomains, and each subdomain with its associated identifiers, DID, and zone file. This has to be on-chain and off-chain.
my proposal was mainly related to the DID specs of the BNS-V2 names, allowing users to add more addresses/information to their profile. Actually you can still configure sub domain, but with the same pattern used for sld. Adding DNS records would be great too, the current redirect only works with traditional domains, but doesn’t allow to build a website on top of your .btc
Personally I think that now we have to chance to shape the future of BNS, what we need is more adoption, and first step imo is opening to the resolution of other blockchain too (not only btc addresses but at least evm, sol).
But we need an advanced configuration with DNS records too (would be nice to have .locker registering DNS records onchain !!) to offer an advanced product with web2 compatibility. But we have to consider that 2 BNS namespace (app, id) are colliding with the ICAAN respective tld, and that on btc namespace there are a ton of IP infringements. Until these names remains only onchain i don’t see as a big problem, but when they go online as a subdomain of btc.us they could bring further actions against the owner of the domain, that could lead to a suspension of the main site making all the subdomains unreachable. I think this is the main problem that let TM invest on a clean tld, instead that trying to register .btc at next ICAAN round for gTLDs
DIDs were born from decentralized names (or identifiers). It is evolving rapidly, even though we can participate in its development and massification. One key component I proposed several years ago is the DID:Web resolver. This means that through a DID, the WEB address (a URL) indicates where to get the DID associated with the user. The objective of this resolver is to address a DID from any decentralized identifier from any chain.
Example: did:web:support.xck.app means (w3.org spec) you can get the DID from https://support.xck.app/.well-known/did.json In this case the TLD domain name xck.app matches the decentralized name xck.app, we did it in purpose to do that.
Example: did:web:my.xck.app/phillip.stx means you can get the DID from https://my.xck.app/phillip.stx/.well-known/did.json In this case the TLD name is my.xck.app passing the decentralized domain name phillip.stx that .stx does not exist as an Internet name.
In both cases there is a did:web Resolver service.
That was the idea that Orangedomains (I imagine) did with the .locker TLD, to have control over both TLD and decentralized names. Easy to implement. It is a matter now if you like the name.
W3.org also proposes to use DNS records to secure the DIDs, assuring that they represent the right identifier. They introduce the tag _did preceding the location of the DID associated with the account. The zonefile used in BNSv1 has the same purpose. DNS records are a well-known format. I think that we should keep it to express what is linked to your decentralized identifier, and also including the _did tag. It is more explicit.
Hey guys! Thank for having this conversation, it is definitely needed.
@dant posted and issue directly in the Github Repo, and it would be really helpful if we can move the conversation there, so that when we agree upon something I can make a PR and work on it, and have everyones eyes on it