Proposal for Enhancing BNS Zonefile Configuration

BNS
20

Hey .btc name fans!

Great to see such excitement around this and thanks to @HeroGamer for bringing my attention to it.

I definitely have some thoughts around this.

Some high level thoughts:

  • It’s important not to be too prescriptive - standards should evolve from successful products and not the other way around.
  • It should be relatively easy for new apps to add additional information to a zonefile without permission or a complicated standards process.
  • Unlike the previous iteration, the zonefile can be stored on chain, but space is limited…minimizing space usage and maximizing flexibility is key.

I ran into the similar problems to @dant and @eriq re the current zonefile format being lacking and spent some time over the holidays and the beginning of the year developing a new format and a library to read and write it. Unfortunately (for BNS), I’ve paused work on it at the moment to focus on the bitcoin addresses for stacks initiative, but I’m happy to share some of what I came up with. I’m not proposing this instead of what @dant proposed in the github thread mentioned above, but just sharing it in case the community finds it useful.

Technical thoughts

For those that don’t know, BNSv2 is essentially a key-value store and the “zonefile” is the value stored by key (the name). In the case of BNSv2 the resolver contract stores any arbitrary clarity buffer. In the bnsv2-sdk library, a string-based json schema is used, but there’s no reason that zonefiles need to be json or string-based. In fact, given that people will probably want to store stuff on chain including possibly binary info, json is probably not the best decision as we saw from the complains with ordinals.

In my research, I came across CBOR - RFC8949 which seems to be a good solution for onchain storage in that it basically functions like JSON from a developer point of view but takes up a lot less space and also supports binary data (so that you don’t have to do space-wasting BASE64-encoding of binary data)

I also looked at adding compression to further reduce the on-chain space and ultimately settled on brotli as a good option.

Here’s an example of how data could be structured:

{
    "v": "1",
    "default": "id",
    "id": {
        "v": "1"
        "name": "Satoshi",
        "pfp": "res://avatar",
        "site": "https://example.com",
        "loc": "Tokyo, Japan",
        "disp": "satoshi.btc",
        "desc": "Bitcoin enthusiast",
        "srvs": {
            "github": "johndoe",
            "twitter": "@johndoe"
        }
    },
    "resources": {
        "v": "1",
        "avatar": {
            "val": "<binary_data_here>",
            "mime": "image/png"
        }
    },
    "wallets": {
        "v": "1",
        "0": "bc1qxxx...",           // Bitcoin (SLIP44 ID: 0)
        "60": "0x123...",            // Ethereum (SLIP44 ID: 60)
        "501": "DxPv2QMA...",        // Solana (SLIP44 ID: 501)
        "5757": "SP2JXKMSH...",      // Stacks (SLIP44 ID: 5757)
        "lightning": "[email protected]"
    },
    "dns": "<legacy dns zonefile here. encoding format tbd>"
}

In this example:

  • The v key is the version key and indicates the version of schema.
  • The id key contains information related to identity.
  • The wallet key is a hashmap of wallets the name owner wants to associate with the name.
  • The dns key is a serialized representation of the ICANN dns zone contents (or information such as an NS record of where to find it).
  • The resources key is a hashmap that provides for named storage of arbitrary binary and text encoded data and the associated mimetype. To store the actual profile pic for example.

What I tried to do here was move have a few top-level keys that reflect currently known use cases of names. The idea is that instead of prescribing a fixed zonefile schema at the outset which then restricts future applications or causes users and developers to have to include a bunch of useless (to them) boilerplate just to get their app working or have to go through a community political process.

You can take a look at how I went about implementing an early version of this in the nil-zonefile rust crate:

Political thoughts

Politically, I’d suggest that a process separate from the SIP process be established. I dont think anything particularly formal is needed now but it would be nice to have a few spec documents that people can point to. For example, taking the structure above, you could have a series of BNSIPs defining it.

BNSIP-1 Zonefile structure

  • encoding format
  • compression format
  • focused only only top-level keys
  • required keys (v)
  • optional keys (id, resources, wallets, dns and where they’re defined…BNSIP-2, 3 etc)

BNSIP-2 id key structure

  • define the required and optional keys in the id key here

BNSIP-3 wallets key structure

and so on and so forth.

Closing thoughts

I’m really excited to see so many people care about BNS and building on it and very much look forward to seeing and trying out what you come up with!

4 Likes