Proposal for Enhancing BNS Zonefile Configuration

BNS
#1

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

  1. 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.

  2. 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:

    "social": [
    { "name": "x", "user": "@example" },
    { "name": "nostr", "user": "hash" },
    { "name": "facebook", "user": "name" }
]

  3. 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.

Eriq.btc

Stacks Roadmap and Product Vision Update
#2

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:

"pfp": "ipfs/https url",
"name": "Foo Bar"
"social": [
    { "name": "x", "user": "@example" },
    { "name": "nostr", "user": "hash" },
    { "name": "facebook", "user": "name" }
],
"addresses": [
   {
     "network": "bitcoin",
     "address": "bc1....",
     "type": "ordinal"  // type is optional
   },
  {
    "network": "bitcoin",
    "address": "bc1....",
    "type": "payment" // type is optional
  },
  {
    "network": "stacks",
    "address": "SP",
  },
  {
    "network": "ethereum",
    "address": "0x...",
  },
  {
    "network": "solana",
    "address": "..."
  },
  {
    "network": "foo",
    "address": "bar"
  }
]

The other thing to consider is that with the current regime, every update to a profile/zonefile requires a network payment.

5 Likes
#3

Is there a standardization process for BNS that is distinct from the SIP process?

#4

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.

2 Likes
#5

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

1 Like
#6

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.

1 Like
#7

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.