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

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

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