What proof do you need Ragnar? Proof of Partnerships, myself & Tommy are co-ordinating BNS & Stacks joining the Web 3 Alliance (with the likes of NEAR, Bonfida, PNS & Ontology) that would enable BNS to integrate with up to 165+ partners as part of a ‘wallet resolution service’, which in turn will increase adoption.
Users new to Stacks/BNS need a smooth seamless experience when being onboarded, the less friction there is the lower the barrier to entry. Having 1 name per address causes friction for the average person/crypto user, which includes the creation of said address, transferring STX, claiming/buying name and repeat. It’s illogical imo for the upgrade to not include this as it’s what matters to the end user.
If anyone needs further proof feel free to hop into the BNS DAO, where the users are.
1-1 is simpler and more straightforward,
users doesn’t need make transactions to change primary name,
dApps doesn’t need care/maintain which name to show given an address.
1-1 gives dApps more motivation to create their own namespaces and earn money, which in turn benefits BNS itself.
No other chain name systems have more attraction to dApps than BNS in this way.
1-1 is safer, especially when user store diffrent names with different seed phrases.
With the grow up of Stacks and more and more exposure of BNS, BNS will gain more and more adoption.
In the future, very small percent users will own tens or hundreds names.
With that said, it’s not hard for them to trade their names, because different marketplaces will compete to provide the best user experience.
And BNSx is also a good choice.
I think this discussion went to a much more important issues regarding governance and what structure exists for making such a change. I personally think what BNSx does is a good example of building a new system that might replace or coexist with bns. I’m of the same view as jude here anyone can build a wrapper for bns and use it as the default name resolver and build the infrastructure around it (an indexer or just a just a regular read-only function). If there’s enough incentive to build it will be built. One other thing from jude is that at the time none of the non-CLI wallets used multiple names and that there were no complaints about the new direction; so this is just responding to both the use cases and the passive consent of folks involved in the community and interested in the development of stacks 2.0 at the time. I agree that times have changed and the flexibility might be needed but one form of governance in this matter that can work to break gridlock is to build a different method like BNSx and seeing its adoption vs the current BNS contract which I know isn’t just a contract but also a whole infrastructure with both a resolver within the stacks api and down to the stacks node itself; so I can understand where people pushing for 1:n are coming from since that change would mean a standard resolver in the existing infrastructure making easier to integrate, but that assumes that there is an overwhelming need for that change demonstrated through experiments like BNSx. The adoption arguments do not convince me tbh since if companies did want to come stacks and explore the ecosystem and have a piece of the market share this will not stop them, and new users won’t come to stacks instantly to create new names, and even if that’s the case they would either by speculating adding nothing to the ecosystem or someone who actually likes stacks and doesn’t mind the kinks related to their specific use case.
Regarding: 1:1
Having to click add new account and transfer funds to it in order to manage multiple identities honestly that seems like a small price to pay if you are wanting to manage multiple identities. (This isn’t like asking them to spin and back up an entirely new wallet here so whats with this stance like its a huge barrier)
Regarding: 1:Many
What exactly is the use case that can’t be done ? I mean aside from hodling more names for less fees?
If we are trying to make it easier for people to use sock puppet accounts or perhaps make it cheaper to flip names then I guess this makes sense.
Ultimately this sounds like its about making multiple name management cheaper. I’m not fully against this, but I just think if the market demand for 1:many exists it should be facilitated by deploying a separate contract like @jude eluded too. This would be the best way to let the market decide imo.
@jude … If that were done, could both contracts (existing an this theoretical BNSv2), could they both register .btc names or would .btc be only available on the existing BNSv1 contract?