Next Gen Name System Prototype

#1

Hey everyone,

I wanted to share a new prototype for a next-generation name system. The proposal is based my experience with .btc and my years in the ecosystem. The idea was first formulated when I was working on Clarity Lab but never saw the light of day.

My prototype takes a crypto-first approach when compared to the traditional ones modelled after DNS or “blockchain name system” approaches.

Instead of a one-level name system like BNS or DNS where the only second-level names (below TLDs) like example.com or marvin.btc are registrable and tradable, it is a multi-level, recursive NFT name system where each NFT is a name that can have zero or more sub names. It has the following properties:

  • All names are SIP009 compliant NFTs.
  • Each name has an owner.
  • Each name has a manager (can be same as owner).
  • Owners can change name properties like the zone file.
  • Owners can transfer and trade names like any other NFT.
  • Managers can register sub-names and change token URI and so on.
  • Managers can transfer management to another manager or relinquish it to the owner of the name.
  • Managers can freeze the manager setting to ensure management stability.
  • Sub-names themselves are names, so all the above applies.

You can check out the concept code on my Github and try it out locally on your computer:

It’s important to note that this isn’t a ready-to-ship BNS upgrade (or anything like that), but instead a functioning prototype to show how the core concept works. There’s additional work that needs to be done to make this production ready along with decisions that would need to be made regarding what the upgrade path to this would be.

I’m very interested to hear your thoughts and feedback about my approach. Is it something that interests you? Is this a path that would make sense for a name system on Stacks? And finally, would you be willing to help?

6 Likes
#3

For those that don’t know @marvin.id, he used to work at Hiro, the Stacks foundation, Trust Machine and Opensea. While working in Stacks, he built btc.us and the .btc namespace and wrote the book on the Clarity smart contract language (literally!). He’s currently co-founder and CTO at Ryder where they figured out how to build the first managed community identity system on BNS with Ryder community names.

When Marvin first shared this with me after meeting up for hotpot a few weeks ago, I was immediately struck at how elegant the design was. A recursive, multi-level name system where all names are NFTs opens numerous possibilities for future applications and new business models for BNS. This is also bullish for existing holders of names as well as their assets gain functionality and the possibility of future income streams.

I’m very excited that Marvin decided to share his prototype name system publicly so we can get more feedback and gauge community interest.

Since the beginning of DNS and throughout the history of BNS, we’ve had single level, two-dimensional systems. Marvin’s system bumps this up to a three-dimensional multi-level system that is much better placed to model the types of relationships we see both on and offline.

In my view, Marvin’s approach is a substantial improvement over both existing BNS and proposals on the table to upgrade it. I think it really has the potential to move the needle by re-invigorating the BNS ecosystem and delivering an industry leading name system for the bitcoin ecosystem.

The path forward

As most of you know, we have a BNSv2 proposal built by Trust Machines largely based on a set of specifications generated by the community through our BNS Working Ground discussions with the addition of a managed namespace feature added on to support their desire to integrate with the ICANN top-level domain that they own.

One option is to go forward with the TM proposal and build Marvin’s proposal as a future upgrade to BNS. The TM proposal is largely ready to go while Marvin’s proposal will require an investment of engineering effort to get to the same point.

Another option is to hold off on the TM proposal and build out Marvin’s proposal as BNSv2. This would take a more time in the short-term, but would avoid the additional coordination cost to the community of multiple hard forks.

These obviously aren’t the only paths forward, but I’ll leave it to bring up other approaches they think make sense!

I’m really excited to hear what everyone thinks of Marvin’s prototype!

7 Likes
#5

Hey Marvin - thanks for doing this - first pass looks great!

I think from a community perspective of this vs the current TM trust machines v2 proposal, it would be super useful to see a side by side comparison on functionality. Is that something that could be pulled together, perhaps with help from @setpato on the TM v2 side?

Also a potential timeline would be great. If this pushes out a v2 release by 2-3 weeks vs 2-3 months would be good to know.

I’d be up for helping where I can, but i’m pretty time constrained right now…

3 Likes
#6

(Non technical POV) This approach sounds very practical in an organisational context, for delegation and brand licencing. I’m excited about BN2 as well but would love to see this rolling out in tandem. Thumbs up.

2 Likes
#7

It’s a very interesting approach. Love the way you can create subdomains but I would like to focus on the tokenid generation. As you know namehash is a common tool on EVM domains system like ens. I believe this approach to generate unique tokenid could be applied to BNS too. It will be nice to have a general discussion about the project on a public space.

Great job. Keep building. :muscle:

1 Like
#8

How would a namehash improve the token ID generation in the concept? In Clarity we can use any data type as a map index. Is your reasoning that it would allow you to calculate the token ID offline based on just the name?

1 Like
#9

I believe namehash could solve some “misunderstanding” that could be generated by a classic token-id mapping.
This behavior can be well explained when you use digits sld, example 1.btc will get a random token id, depending from the mint order let’s say 123.
A logical human analysis will expect to have 1.btc at token id 1… like classic nft collection.
I know this concept can be a little weird, but using namehash as token id you bring the focus on the the name only. And you won’t “downgrade” some grails in the digits category assigning different token ids (or better not assigning the grail token id to another name)

Imagine this scenario:
420.btc tokenid 23675
avh4dt.btc tokenid 420

Another discussion could be about names normalization. Special characters and emoji imo are confusing a lot. I will prefer a classic approach: Latin characters, all lowercase, underscore or hyphen allowed (but not a double consecutive hyphen to avoid punycode) Other web3 providers are adopting this solution to prevent scams, but also bc keyboards are not supporting these characters rn.

About subdomains (I’m not an huge fan, or better not in the way someone is spamming other providers with nonsense subdomains) I would like to better understand how will they be handled when the main sld will expire. Subdomains will expire too, or will be independent? IMO same expiration date should be the standard always to maintain consensus on the primary name.

1 Like
#10

Put together this quick and dirty comparison of TM’s name system proposal versus @marvin.id prototype.

Screenshot 2024-08-18 at 12.24.41 PM

5 Likes
#11

Love these insights mate

2 Likes