If a downgrade to BNS does not have overwhelming consensus, it should not be adopted. This forum thread and others prove the downgrade lacks consensus.
1 Like
Then we should revert the original downgrade. Did you know it was a unilateral change by one individual against the wishes of the entire builder community when it was made 1:1? The change was tyrannical. It must be undone if that’s the only argument that has merit.
1 Like
Two wrongs don’t make a right. And there are many valid arguments besides the lack of consensus.
Disagree with alot but some good points
There needs to be a way at smart contact level to separate the expiration to make them separate and therefore they would be transferable nfts but have to link back to the ecosystem for utility and usability in the stack BTC ecosystem
Overall I’m for this change.
The main benefit to BNS outside of easier sending of assets is the identity/reputation piece. In a pseudonymous economy, these features become increasingly important.
With that in mind, I’d say the fact you can trade BNS already breaks a lot of the value as a deep level.
The way that Reddit doesn’t allow name changes or transfer of Karma is one design philosophy that allows a reputation system to emerge on that platform.
The way BNS is currently constructed tries to find a balance of both but it doesn’t do it well. Because it fails at truly saving reputation/identity (because it can be traded in the first place). It’s not the ideal solution.
Allowing multiple names removes some friction from current use cases. I.e pointing assets to a specific wallet address, and domain squatting. One name one wallet makes the first case much more annoying and the second only slightly less user friendly.
Not worth the downsides IMO but open to hearing opinions.
@RagnarLifthrasir on the topic of Trajan. Is there a technical reason you can’t restructure the app to work in the bounds of multiple names with a “primary name”
2 Likes
Reminder: there’s nothing special about the BNS contract. Nothing stops y’all from making your own BNS contracts that back-reference BNS state with (at-block ...). You don’t have to agree on the design to make progress – just deploy your own BNSv2 and see if the market likes it.
4 Likes
It was removed because at the time, exactly zero of the non-CLI BNS name management wallets out there were able to correctly handle multiple names per address (e.g. if the user registered two names to one address, all existing wallets besides the CLI just showed one name). Moreover, all the wallets took steps to create the illusion of 1:1 name/address correspondence. The current BNS assumed this responsibility in order to help these wallets maintain this property.
Also, Stacks 2.0 was developed in public and had multiple public testnets available for about 10 months prior to launch. There were exactly zero complaints about the BNS design until well after the fact.
1 Like
Nay
There was an extremely thoughtful discussion on this issue that you unilaterally shut down given an extreme bar that makes no sense in the real world.
Please re-open only if you are able to come up with a plausible app that is truly impossible to create without it.
I guess “truly impossible to create without [1:many]” is the bar we should set as an ecosystem.
This is the reason it’s difficult to do anything with BNS. Because the bar set is “not truly impossible.”
1 Like
I support making this change. The actual behavior of the market, with so many people creating multiple wallets so they can buy multiple addresses, clearly indicates that the many to one functionality is what the market wants.
2 Likes
Well I’m afraid those that agree with the 1 name 1 address system are in the minority.
The people that are actively using BNS are those in the community and most of them reside in BNS DAO, around 1800 of us. We’ve been discussing this topic in the Discord over the last 24hrs and the majority favour the multiple names per wallet. Again only a small number (including Ragnar) are in favour.
I use a multitude of different blockchain names systems and having more than 1 name per address is essential imo. I’ve managed with Stacks as I know my way around the wallet/system etc but for the average person in crypto having 1 name per address is a significant barrier to entry. Users want an intuitive, seamless and uncomplicated experience - that’s first and foremost all they want! Let users have 4-5 addresses with 100 names, don’t overcomplicate it by making them create 100 addresses for 100 names.
We need to think about this logically from the users perspective because at the end of the day they are the ones that are going to be using the plethora of dapps on the Stack blockchain. They contribute to the growth and adoption of BNS & Stacks.
When launching a TLD you will always have “squatters” (I’d say investors) holding multiple names regardless of the time and cost involved, as we have today - people have spent hours claiming them! But think about the average user experience, they want simplicity and convenience.
If this still continues to be a contentious topic, it should most definitely go to a community vote in the BNS DAO, not be dictated by a handful of people.
@larry @Deloon @ThomasButcher @hank @nickgamma @RagnarLifthrasir @jude
2 Likes
BNS DAO doesn’t determine Stacks code by voting. Stacks is not a democracy. Bitcoin is not a democracy. I’m not the minority, just one speaking up.
I’ve been in BItcoin since 2011 and have experienced and participated in evolving protocol versions. So I’ll share the basic principles of code changes in decentralized systems, ESPECIALLY BITCOIN:
- For any hard fork, (code that is not backward compatible) should only be done under two circumstances:
A) Clear, overwhelming, objective consensus after months, if not years, of debate, testing, documenting, etc.
B) An extreme emergency - Changes should usually be a soft fork, that is, backwards compatible.
Let’s apply this to BNS.
- Downgrading to more than one name per address lacks clear, overwhelming, objective consensus after months, if not years, of debate, testing, documenting, etc. And the proposed changes to BNS is not an emergency.
- As I understand it, the proposed downgrade is not backwards compatible.
Hank has proposed several changes to the BNS contract that have clear, consensus. Let’s adopt those. The change to more than one name per address does not, so let’s shelve it.
But it doesn’t though Ragnar, only a handful of people (you included) want to to remain with a 1 name per address system. Through consensus it’s pretty clear that the majority want to multiple names in one address.
The proposed changes don’t need to be seen as “an emergency” it’s about improving on the existing contract to prepare BNS for mass adoption and use. Continuing with existing barriers (in this case) will only stifle future adoption for BNS & Stacks.
2 Likes
So the downgrade implementation to 1:1 broke your quoted long-standing rules of decentralized development, but that’s ok because it’s the outcome you want to see?
Regarding an example brought up earlier. Does BNS/Stacks have an executed agreement with Bluesky stating that they are partnering with BNS exclusively and that the partnership is contingent on a 1:1 naming system? Because if they partner with any other popular Web3 naming systems/domains it won’t be 1:1. Binance, polygon, hi, all seemed to be able to partner with multiple domains per address and were still able to sell a hell of a lot of their own domains with their individual TLDs.
Do you know the executives to secure this partnership before another more aggressive project with a team ready to go and integrate steps in? And has Bluesky specifically told Stacks/BNS that 1:1 is mandatory?
Or are these maybe, we think, etc??? Speculation.
I’m asking because of all the reasons given, partnerships are the only one that holds some weight with me, but I’ve seen the exact opposite in the industry. So I’m not sure where this data is coming from outside of a few, very vocal individuals that seem to be speculating based on their own belief of how something should work.
When an industry leader managed to close > thousand of partnerships with multiple domains on a single address. That tells me that this 1:1 doesn’t seem to be all that mandatory and isn’t a sticking point.
Why don’t we look at it the other way? Is it “truly impossible to create with [1:many]”
Do any of you have experience securing partnerships?
Generally, the first question is. How many users will this bring us, or what exposure will this gain us? Second is typically, how easy will it be for our users to use the system? Right now the answer to number 2 seems to be it will be difficult, but friction is good for adoption.
Right now we have thousands of requests for multiple domains from the current user base. All are being ignored because a handful of people are standing on some strange principle.
BNS has been around for a long time. Ask the average user if they have heard of them. The answer is no. They know Unstoppable, and they know ENS, because they are easy to use and fit their needs. You’re trying to manage user behavior through code. That doesn’t work and only makes growth difficult. Friction is not good for growth/adoption.
- Unstoppable has registered about 3.5 million domains, and their Twitter channel has over 325k followers
- ENS has registered about 3 million domains, and their Twitter channel has about 250k followers
- BNS has about 300k - 350k domains registered, and its Twitter channel has about 1.5k followers
And BNS has been around longer than anyone else in the Web3 namespace.
At some point, you have to look at the data and say maybe, just maybe we’re doing something wrong. We’re making it harder to bring on new users and grow the project. Buy hey, there COULD BE this big partnership, maybe, I think…
Name the specific “Big Partnerships” you claim to bring to BNS.
Provide proof that those Big Partnerships will not proceed unless the contract changes.
Provide proof that those Big Partnerships will proceed if the contract changes.
Explain in detail what these partnerships do.
Address the risks of corporate capture of BNS by these partnerships.
MOST IMPORTANTLY
Do you want to change a fundamental function of Stacks? Write the code and docs and circulate widely for testing and feedback and consensus. Nothing is stopping you. Why haven’t you done this already? You don’t anyone’s permission.
You know what? This is pointless. Multiple people on here have provided you with actual data. You don’t answer any questions, or provide any data back in return, just more pointless arguments presenting yourself as the end all be all of the final decision. Ignore the market and the users, and we’ll check back in a year from now and see how much progress has been made on adoption.
You’ve repeatedly made big claims, yet you can’t or won’t provide proof. Therefore, your arguments are void.
What problem does 1:n names solve for the user?
I am user and own more than 1 name. 1 even own 2 names on the same account (check app.sigle.io / friedger.id and app.sigle.io / friedger.id.stx), but different addresses.
It would be easy for the Hiro Wallet to show all names owned by a user for the same secret key. And add a button to register a new one. If Hiro doesn’t want to do it. Fork it!
More investment in gaia or other dstorage, in wallet Integration, in partnerships, etc would benefit BNS much more than the discussion about 1:1 or 1:n which is on a technical level that users do not care about.
With account abstraction, users expect a different kind of wallets than managing assets on a public key level
2 Likes
Where have I made a claim that “I” would deliver X? I’ll wait…
I’m showing industry data that is publically available to anyone that actually cares. I know you don’t. I’m sharing marketplace and user data that was shared with us directly from our only marketplace. I know you don’t care about that either. I presented a use case showing the difficulty an average user/business (not a Web3 expert) will have given our current 1:1 system. Don’t care.
I proposed a compromise where one can allow for a Primary Domain. And I know you don’t care about that.
As I said, keep ignoring users and the industry and we’ll see how much progress Stacks/BNS has made in a year. Good luck with Trajan, I honestly hope you hit mass adoption and have hundreds of thousands of users flooding into BNS. I’ll check in on Trajan periodically to see how adoption is coming along.
1 Like
Yes 