Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RNSIP - Registrar interface #7

Closed
ilanolkies opened this issue Aug 12, 2019 · 9 comments

Comments

@ilanolkies
Copy link
Contributor

commented Aug 12, 2019

Registrar interface

RNSIP XX
Title Registrar interface
Created -
Author IO
Purpose ST
Layer 1st
Complexity 1
Status Draft

Simple Summary

A standard interface for Registrars.

Abstract

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 following standard interface allows implementing Registrar contracts providing them with their basic functionality.

Motivation

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.
The motivation of this standard arises from the fact that the implementation of the TokenRegistrar did not allow updating the Resolver of it's root node.

Specification

Registrar

A Registrar contract is owner of an RNS node. It should expose the following functions:

function setRootResolver (address resolver);

Sets the resolver of the node owned by the registrar.

function setRootTTL (uint64 ttl);

Sets the TTL of the node owned by the registrar.

Rationale

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.

Implementation

This is a simple implementation of the Registrar interface.

Interface

contract RegistrarInterface {
    address owner = msg.sender;
    RNS constant rns = RNS(0xcb868aeabd31e2b66f74e9a55cf064abb31a4ad5);
    bytes32 rootNode;
    
    modifier onlyOwner {
        require(msg.sender == owner);
        _;
    }
    
    constructor (bytes32 _rootNode) public {
        rootNode = _rootNode;
    }
    
    function setRootResolver (address resolver) public onlyOwner {
        rns.setResolver(rootNode, resolver);
    }
    
    function setRootTTL (uint64 ttl) public onlyOwner {
        rns.setTTL(rootNode, ttl);
    }
}

RNS address of RSK Mainnet

Usage

This is how a Registrar contract should implement this interface.

contract Registrar is RegistrarInterface {
    constructor (bytes32 _rootNode) public RegistrarInterface(_rootNode) {}
    
    function register (bytes32 label) public {
        //...
        rns.setSobnodeOwner(rootNode, label, msg.sender);
    }
}

Copyright

Copyright and related rights waived via CC0.

@makoto

This comment has been minimized.

Copy link

commented Aug 27, 2019

Hello. Makoto from ENS.

The motivation of this standard arises from the fact that the implementation of the TokenRegistrar did not allow updating the Resolver of it's root node.

Can you elaborate more on this? What is RNS doing differently to ENS so that you need new standard to register subdomains?

@ilanolkies

This comment has been minimized.

Copy link
Contributor Author

commented Aug 27, 2019

Hi @makoto!

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.

@makoto

This comment has been minimized.

Copy link

commented Aug 27, 2019

<< 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?

@ilanolkies

This comment has been minimized.

Copy link
Contributor Author

commented Aug 28, 2019

This is a standard track, not a change of protocol proposal. When creating a registrar contract (not necessarily the .rsk or .eth), subnodes issued by that registrar do inherit the resolver. Applying to this RNSIP makes the resolver inheritance upgradable.

@makoto

This comment has been minimized.

Copy link

commented Aug 28, 2019

It's irrelevant whether the auction starts or not. this depends on the implementation of registrar and I don't think we have such registrars in ENS world. Can you point me to the standard registrar implementation you guys use? Are you guys still using the old HashRegistrar which we no longer use?

@Arachnid

This comment has been minimized.

Copy link

commented Aug 29, 2019

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.

@alebanzas

This comment has been minimized.

Copy link
Member

commented Sep 9, 2019

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.

@ilanolkies

This comment has been minimized.

Copy link
Contributor Author

commented Sep 12, 2019

Hi everybody.

Moreover, we are re-organizing the material

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.

@ilanolkies

This comment has been minimized.

Copy link
Contributor Author

commented Sep 12, 2019

@ilanolkies ilanolkies closed this Sep 12, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.