Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
RNSIP - Registrar interface #7
A standard interface for Registrars.
The owner of an RNS node can issue new sub-nodes under its domain. These new sub-nodes inherit the Resolver contract of the issuer node. The issuer node may be a smart contract, called Registrar.
The only one who can change the Resolver and TTL values of a node is its owner. In this case it is a contract, that should have this functionality implemented.
A Registrar contract is owner of an RNS node. It should expose the following functions:
Sets the resolver of the node owned by the registrar.
Sets the TTL of the node owned by the registrar.
The Registrar contract may allow changing these values only for certain addresses. This implementation assumes that the previous owner is the one who creates the contract to register, and is the only one who can modify these values.
This is a simple implementation of the Registrar interface.
This is how a Registrar contract should implement this interface.
Copyright and related rights waived via CC0.
Hello. Makoto from ENS.
Can you elaborate more on this? What is RNS doing differently to ENS so that you need new standard to register subdomains?
RNS is not handling new subdomain registration differently to ENS.
This standard applies for any new registrar at any level of the RNS Registry. When a new node is issued, it inherits its parent resolver. As the resolver is the main component of the solution, any new registrar may change its resolver over time.
<< RNS is not handling new subdomain registration differently to ENS.
Then why do you need new standard?
<< When a new node is issued, it inherits its parent resolver.
So this is actually a different. At ENS new node does not have any resolver by default so each user has to set by themselves. Having said that you can change the registrar function of the parent node so that it sets resolver as well as owner. That can be done within the capacity of current protocol so I am still not sure why this proposal is required. Maybe I am missing anything?
This is a standard track, not a change of protocol proposal. When creating a registrar contract (not necessarily the
Hi! Thanks for reaching out to collaborate. We'd be glad to work together on standards.
Like Makoto, though, I'm a little confused at the motivation for standardising this one specific aspect of a registrar. Our approach so far has been to largely treat registrars as having a single large interface with all relevant methods in, rather than trying to standardise individual methods like this. Can you expand on an example use-case where client software would need to use this interface regardless of the specific registrar implementation it's interacting with?
Speaking more generally, I'd suggest that instead of storing a resolver address on the registrar and assigning it to each new subdomain, you could instead take the registrar address as an extra parameter to the function call that registers a new domain. This removes the need for an administrator to update the registrar address each time a new one is deployed, and gives users and client software the flexibility to specify whatever resolver implementation suits them best.
Hi Nick and Makoto, thank you very much for your comments and collaboration spirit with RNS!
We decided, by the time of launch, to extend the functionality and add the default resolver behavior to our implementation. This lead us to this necessity of allowing a registrar to change his default and warn the custom registrar users to have this interface. Otherwise, they will be forced to transfer the ownership from the registrar to a 3rd party who will do the resolver change, and then transfer back the ownership to the previous registrar.
After having some conversations and taking your comments, we agreed that this is not an improvement proposal, but a technical note. Moreover, we are re-organizing the material (IPs, tech notes, etc) as a result of this thread.
We are very grateful with the ENS community and trying to give back, happy to be part of the devcon pre-day conversation, and open to continue collaborating.
Meanwhile I will move this to https://github.com/rnsdomains/rns-artifacts and create a docs section explaining the importance of using an interface for registrar contracts that allow to manage basic functionality.
Thanks everybody for collaborating and being part of the identity of the future.