BNS Names on L1 - feedback requested

I don’t fully understand the value here to those that want to trade their Ordinal? So you’re proposing that the BNS name and BNS Ordinal co-exist? The initial idea around this was for there to be a bridge between the two providing users with a choice as to whether they want their BNS name on L2 or L1, having both co-exist won’t provide any additional value to BNS holders nor will it be attractive to any buyers on the L1 side. Same goes for .sats. :thinking:

3 Likes

keep building

1 Like

If we don’t make changes 100% will fail

The premise of success is continuous innovation. There is no success once and for all

1 Like

I respect your perspective on this, but I view this differently. Rather than viewing locking names as a factor that breaks apps, I think we can interpret this as an opportunity for apps to evolve and cater to the needs of their users more comprehensively.

Users who opt to transition to L1 are making a deliberate choice. This choice, in turn, represents a requirement that the apps they use should ideally cater to if they wish to meet the needs of all users. Apps in the Bitcoin ecosystem ought to consider integrating both L1 and L2.

Put differently, why would a Bitcoiner not desire to be as near to L1 as is possible? This is a position I certainly resonate with. I’m a strong proponent that L2 solutions should come into play when L1 functionality has been fully exhausted. Apps must adapt and thrive in an environment where both L1s and L2s coexist.

The core function most apps use names for is provenance, which is then employed to authenticate the user to modify their data in the app’s database or an external data store. There’s no reason this process needs to be confined to L2 exclusively.

Lastly, while Trajan is indeed an identity app, it is not the only one in existence as you suggested. Thousands of creators and collectors call Gamma their home, where they build digital asset profiles that embody their digital identities. These assets symbolize their communities, interests, hobbies, friends, and much more. The platform leverages DIDs and does not provide off-chain usernames, but instead uses on-chain BNS names on Stacks. It’s therefore the most popular identity app on Stacks, so we listen strongly to user feedback in this area and make decisions based largely on this feedback.

I believe it’s crucial to foster an environment where both L1 and L2 can coexist and where apps adapt to user needs and preferences rather than confining them to certain layers. After all, technology should serve us, and not the other way around.

3 Likes

We can do all you said without making the fatal mistake of locking names. It’s totally unnecessary, centralizing, complex, and breaks Stacks apps.

The better approach is for Stacks users to simply take a formatted name file and inscribe it.

Janus Names BNS to Ordinals

Any inscription service can perform this action. Using Hank’s proposal, it’s likely Dots will be the only locking and inscribing service. They will have a monopoly and will be a significant bottleneck. Also, with this approach, BNS name holders can continue to use the name across Stacks apps. The address of their name won’t change.

**Edit
I’ll add that Gamma is not a reputation and identity platform for several reasons, such as:

  • Gamma lacks the fundamental tool of users being able to endorse other users using non-transferable NFTs.
  • Gamma doesn’t monitor if BNS names move to a different address and then hide or flag that BNS name to prevent users from selling their BNS name, and thus, identity and reputation.
1 Like

This isn’t a great experience and will cause significant fragmentation of already complex naming protocols. Imagine inscribing an L1 name, then transferring or selling it, and then retaining the L2 name. Now identity is fragmented making both unreliable sources of truth. This undermines the entire protocol on both L1 and L2 and makes the singular purpose of an identity protocol obsolete, so this counter proposal is not at all workable.

I think your point on locking and inscribing monopoly is a good one, but I think it could be easily rectified. @hank would you be open to open sourcing your locking methods and applying an MIT license? That way, anyone can spin up an equivalent service, for example, Trajan could. In terms of inscribing, there can’t possibly be a monopoly because you’re just inscribing text/code at the end of the day.

Second, @hank could you also commit to allow a user to copy/paste/export the final resulting file on Dots should they wish to inscribe with the platform of their choice? I think it’s perfectly fine and reasonable if Dots has the best experience and the default flow is to use the first-party free or paid service, but we could rectify Ragnar’s concern if you can commit to these points.

I don’t wish to get into a dispute on what makes an identity app an identity app. We don’t claim to be a reputation management platform, nor a competitor with you (that’s great, we’re each building a unique and valuable take on identity solutions). I would never claim to know your product better than you. I trust you when you say you’re a reputation management platform leveraging BNS. But we are absolutely an identity platform. We are a web3 social platform, creator launchpad, and marketplace. Feedback is always welcome if we can make our identity features even better, but let’s take that offline as it’s not relevant here.

1 Like

All for it, let’s make it happen!

1 Like

100%. I personally have no interest in building an inscription service before launch - that would just add a ton of extra work. The plan is to support copy/pasting and likely to also integrate with an inscription service API like Gamma’s to provide an easier experience.

In regards to open source: just like with BNSx, I commit to being completely MIT open source and providing JS code for apps that wish to provide this experience.

For me, the whole point of this project is just to add value to BNS users. The only reason I’ll build it into Dots is because it’s the easiest path forward for me. I totally understand the concerns, though - thanks for pointing it out so I could clarify!

3 Likes

Support Hank’s proposal

additional suggest the following points for reference

  1. Add btc as mint bns gas fee
  2. Change all namespaces to never expires
  3. build a professional bns trading market
  4. puny emoji claim uni emoji version
  5. Cancel the council dao mode
  6. Those who have a positive influence and contribution to bns (including devs,investors, holders) @will-at-stacks should be given bonuses and set this bounty
1 Like

In my opinion, this is a matter of life and death for bns. Affecting the entire stacks ecosystem, if bns cannot be well accepted by the market, then few ppl follow attention to the next Nakamoto release and sbtc, all eyes and funds will in ordinals

1 Like

you can’t use name at both layers, ordinals names resolved to BTC address they reside in, with both L1 and L2 co-exist there will be possibility to have different wallet address for 1 name. That’s why the name must be at one layer only at the present time. I prefer my stacks domains to be burned forever for ordinals, btw. And i believe people should decide what they want not you will decide what they do. As I see from the convo 99% agree with @hank proposal, not yours

1 Like

Fully in support of this move Hank.

One question - how do we ensure that the picture provided to inscribe as an ordinal is unique?

For example, what stops a user minting a matching one? I guess first is first logic could stop this… but then what if the legit owner were to transfer back to L2, burning the inscription - does the duplicate inscription then become the first? This could be an issue if the legit owner tries to transfer to L1 again.

Could be solved by unique picture generation at every transfer to L1, for the same name. So you’d need unique pictures each time, but also a way to randomise it, otherwise bad actors could follow a pattern and mint ordinals of each future iteration, to lie in wait.

1 Like

This would depend what the wallets decided to resolve. Inscriptions can look different - like Hank suggested use a picture for BNS ones. Some protocols use an object to tie it to them specifically e.g. {op:“sns”, name:“1.btc”}.

1 Like

.sats names have L1 liquidity because they are on L1 right? They don’t need to be linked.

1 Like

That’s great to hear Hank. Sounds like this resolves the open concerns.

1 Like

Hey Hank, thanks for sharing this initiative! I am supportive of work happening to bridge BNS to BTC L1 ahead of broader BNS upgrades. It seems most urgent and effective path forward for making BNS the full featured Bitcoin Naming System it originally set out to be, and would love to help however possible. Could you share what the UX implications in apps or wallets might be for a locked name?

1 Like

Nick or hank ??
:rocket::full_moon:.btc

1 Like

Probably, the search for a business model of exchange for the domain or subdomains is one aspect, but the original purpose was as a decentralized digital identity with zonefile and profile. Just this original purpose is a high impact in order to help build a new internet, and it is massive as the population of the world.

1 Like

Correct, .sats names have L1 liquidity because they are on L1 right. They don’t need to be linked. It’s a bogus argument that names need to be linked to have liquidity.

1 Like

You argue that, despite how Hank’s proposal negatively impacts Trajan it doesn’t matter since Gamma is a reputation and identity platform, implying Gamma is a competitor. But then you backtrack and say “We don’t claim to be a reputation management platform, nor a competitor with you.” But then you say, “we are absolutely an identity platform.”

So which is it?

Also, Hank’s proposal will negatively affect ALL Stacks apps by locking the name. This includes Console, Sigle, and others, now and into the future.

1 Like