To be clear, I think this functionality is very much needed but it’s also important to be clear to users of various namespaces what they’re buying. Previously with “subdomains” the operator gated registrations…controlled who could register…but once registered, users had full control and ownership of their names. My understanding is not the case with managers. I understand that this functionality is necessary to support what Orange Domains is trying to do with .locker and what other namespace creators might want to do. It’s also worth thinking about failure conditions for managers…like what happens if the goes bankrupt, gets bored, looses their private key, etc. Does the namespace become useless? Perhaps there are already well thought out answers to questions like this is a document somewhere that could be shared!
I encourage everyone to join the Trust Machines’ X Spaces later today (July 12th) at 11:30 PM HKT / 3:30 PM UTC / 11:30 AM ET.
After a quick glance, I have several recommendations:
The get-namespace-properties should only return properties.
The get-primary-name should be splitted to get-primary-name(return name) and get-primary-id(return id).
The namespace-manager has too much power, it can burn/transfer/list/… anyone’s name. For this reason, few will buy custom namespaces’ names, I think this design is not good at all.
Marketplace related logic should be removed, it increases the attack surface. Core contract should be simple.
Yes, the point of managed namespaces was to open up as much as the default functionality as possible for max customization. The properties that any one specific manager has are explicitly defined.
Hey! So no right now that is not implemented, but the functionality is there, the only difference is that instead of calling the function once, you can call it multiple times, and on every call the lifetime of the namespace will be added to the renewal height
So you mean for custom namespaces, the namespace manager can steal user’s assets casualy by default, unless he restrict himself manually?
This is very dangerous, user’s asset shouldn’t be stolen without his private key or authorization.
So you mean for custom namespaces, the namespace manager can steal user’s assets casualy by default, unless he restrict himself manually?
Yes - BUT there are tons of mechanisms to prevent this for custom managed namespaces that don’t want to have this ability.
Managed namespaces will use a “manager” smart contract, and it’s possible to “freeze” this manager contract in BNS v2. This means that if the manager is frozen, and the manager contract doesn’t expose any way to move a user’s name, a user can be guaranteed that their name can’t be stolen.
This ability for a custom namespace to move a user’s name is important for some use cases. For example, the concept of “you can only have this .dog name if you own this dog NFT”. In that example, if you transfer away your dog NFT, you shouldn’t get to keep that name, and so the manager contract would have a way to handle that.
Hi hank, I think User’s asset shouldn’t be stolen without his private key or authorization
is a holy principal(Except by DAO).
Though namespace manager can deploy a manager contract to self-restrict, nobody can make sure the manager contract is safe forever.
If the manager doesn’t self restrict, or the manager contract has bug, imagine one day the manager’s private key is leaked, attacker can transfer/burn/list all the names.
All in all, I think this feature is too centralized and dangerous.
Besides, I think the situation you mentioned is rare, we shouldn’t support the rare situation by decrease the safety a lot.
Regarding bridged to L1 domains, could it be a simple solution, to add a corresponding STX address in their Gamma account?
For example, like most others I have all my BNS L1 domains under the same Ordinals address. If I could just add a corresponding STX address to that Ordinals address on my Gamma that could be viewable to @hank@setpato and Co. that could be a quick solution!?
Had another thought - does the new contract implement protection around the grace period? Right now the grace period does not stop another user registering a name, thus rendering it useless.
We’re excited to share some big news with you! As part of our ongoing commitment to enhance BNS, we are gearing up for the launch of BNSv2 and hope to have a target date set soon. A major aspect of this upgrade is the creation of a new logo that will represent the refreshed look and feel of the system.
We’ve been working closely with talented designers to create three distinct logo options to start with and hopefully iterate from. Each one captures a different essence of what BNSv2 stands for. Now, we need your input and feedback!
Each logo honors the BNS logo’s original design vibe. We’ve tried to go classic, futuristic, and minimalist options! A second logo is needed to differentiate the BNS V1 asset from the BNS V2 asset inside the users’ wallets.
We’ve created a survey to vote here for (1) Font and (2) Logo!
Please vote and share all your feedback! Survey Link here
Get your votes in by September 2nd!
Thank you for your ongoing support and for helping us shape the future of BNS. We look forward to hearing your thoughts and selecting a logo that will proudly represent BNSv2!
I have no idea who these “talented designers” are, but to be honest, those designs are It looks like a terrible internship job. Even with the worst AI, you can have much better results than that. This is the result of work done without any enthusiasm or creativity.
Please, this is serious stuff for us, the community. We appreciate the effort, but treat this with more respect, please. Do you think the designs are up to par with the project? I really hope you don’t think that.
Hey everyone! I’m happy to share an exciting update on our zonefiles solution.
After a lot of consideration and feedback from engineers and community members, we’ve landed on a hybrid approach that we believe is the best of both worlds: combining on-chain zonefiles with IPFS zonefiles.
Here’s why this approach: We’re introducing a dedicated contract that will manage everything related to zonefiles. This contract is designed to store up to 4,096 bytes directly on-chain, linking the zonefile to the name and namespace, ensuring that smaller zonefiles are instantly accessible and secure. For larger zonefiles, we’ll be leveraging the power of IPFS by requiring an IPFS CID, which will also be securely stored in the contract.
The API will seamlessly handle the resolution process, ensuring that retrieving zonefile information for any given name and namespace is correctly done.
GM BNS Community
We’ve been working closely with talented designers to create three distinct logo options to start with and hopefully iterate from. Each one captures a different essence of what BNSv2 stands for. Now, we need your input and feedback!
Each logo honors the BNS logo’s original design vibe. We’ve tried to go classic, futuristic, and minimalist options! A second logo is needed to differentiate the BNS V1 asset from the BNS V2 asset inside the users’ wallets.
Get your votes in by September 2nd!
It looks like a terrible internship job. Even with the worst AI, you can have much better results than that. This is the result of work done without any enthusiasm or creativity.