ERC 882: ENS Custom Protocols

[rumkin]

  EIP: 882
  Title: ENS Custom Protocols
  Status: Active
  Type: ERC
  Author: Rumkin <[email protected]>
  Created: 2018-02-13

ENS Layers is DNS replacement with new kind of resolvers which acts like custom protocols and provide any protocol support. For example today email has no it's own resolver and it's using DNS TXT record to provide mail server addresses. Another technology is TLS: we can replace SSL certificate with resolver record with server's RSA public key.

Each ENS name could be a protocol in the same time to provide extension mechanism. Thus everyone could create it's own protocol to make it controllable with contract, receive payments or make data accessible with another contracts.

Valid URL example:

voice-calls.eth://[email protected]

Examples

Cross protocols example

We can add custom resolver for each protocol with it's own smart contract. How could it work:

http.eth - http protocol resolver
email.eth - email protocol resolver
mail-client.eth - email web client

contract EmailProtocolResolver {
    mapping(bytes32 => EmailRecord) hosts;
    
    struct EmailRecord {
        uint version;
        bytes4 ip;
    }
    
    function getMailServerIp(bytes32 _host) public constant returns(bytes4)
    {
        return hosts[_host].ip;
    }
    
    function getVersion(bytes32 _host) public constant returns(uint)
    {
        return hosts[_host].version;
    }
}

contract HttpProtocolResolver {
    mapping(bytes32 => HttpRecord) hosts;
    
    struct HttpRecord {
        bytes4 ip;
    }
    
    function getHttpServerIp(bytes32 _host) public constant returns(bytes4)
    {
        return hosts[_host].ip;
    }
}

Now if we want to write email to [email protected] from web client at mail-client.eth we need to do:

1. Get http.eth resolver address from ENS.
2. Get mail-client.eth HTTP server IP calling getHttpServerIp(namehash('http.eth')) of http.eth resolver contract.
3. Download mail-client.eth HTML-client from server IP (with browser).
4. Write email for [email protected].
5. Get email.eth resolver from ENS.
6. Get http.eth mail server IP calling getMailServerIp(namehash('http.eth')) of email.eth resolver contract.

If we want to open email.eth we need to ask http.eth does email.eth has http server and request HTML page from it.

Example of current existing protocols provided by ENS Protocols.

ENS Name/Protocol	Description
http.eth	Describes HTTP protocol as set of web server IP, port default (80) and protocol version.
mail.eth	Describes mail protocol as set of mail server IP, port, protocol and public key (to sign messages).
tls.eth	Describes TLS protocol as list of server encryption public keys (which should be used for each port).

[VoR0220]

@Arachnid thoughts?

[Arachnid]

Sorry, I missed this the first time around.

ENS Layers is DNS replacement with new kind of resolvers which acts like custom protocols and provide any protocol support. For example today email has no it's own resolver and it's using DNS TXT record to provide mail server addresses.

Email already has a dedicated DNS record type, MX. TXT isn't used for email servers.

Another technology is TLS: we can replace SSL certificate with resolver record with server's RSA public key.

I would definitely like to see a solution using self-signed SSL certificates anchored to ENS to replace the current certificate hierarchy.

Each ENS name could be a protocol in the same time to provide extension mechanism. Thus everyone could create it's own protocol to make it controllable with contract, receive payments or make data accessible with another contracts.

Protocols and resource records are for the most part orthogonal; an 'A' record does not specify what protocol to use to talk to that IP with.

I think this proposal confuses matters by making protocols into ENS names, and since it appears that each protcol can specify it's own interface, clients would already have to know what interface to expect at the resolver responsible for that interface. Doing this also eliminates the main advantage of the indirection provided by resolvers, namely that they can be improved by any user without any kind of system-wide upgrade.

It seems like it would be much simpler and more robust to define these resources as additional resolver profiles rather than inventing a new mechanism.

[rumkin]

@Arachnid

Email already has a dedicated DNS record type, MX. TXT isn't used for email servers.

It uses TXT records for SPF and DKIM for sender authorization and signature purposes.

I would definitely like to see a solution using self-signed SSL certificates anchored to ENS to replace the current certificate hierarchy.

I will show some code at the end of the March. It is the most obvious and useful opportunity of this ERC for today. But I think that ENS could totally describe any host in the Network with any role and all it's configuration.

Protocols and resource records are for the most part orthogonal; an 'A' record does not specify what protocol to use to talk to that IP with.

Yes. But this is limitation of DNS itself. It was designed in early 80s in unix paradigm (everything is a text). It's just one of many hostname-based configuration management system and I don't see a reason to reimplement this technology without enhancement. At least we have new Ethereum paradigm (everything is a contract). If ENS became a replacement for DNS we need to make it usable for 20-40 years.

[Arachnid]

Protocols and resource records are for the most part orthogonal; an 'A' record does not specify what protocol to use to talk to that IP with.

Yes. But this is limitation of DNS itself. It was designed in early 80s in unix paradigm (everything is a text). It's just one of many hostname-based configuration management system and I don't see a reason to reimplement this technology without enhancement. At least we have new Ethereum paradigm (everything is a contract). If ENS became a replacement for DNS we need to make it usable for 20-40 years.

It's not a limitation of DNS - protocols existed when DNS was designed, and it was a conscious choice to make name resolution and protocol specifications orthogonal concerns.

My main concern, though, is one you haven't addressed - that trying to specify protocols like this reduces each one to a single implementation, removing the whole point of ENS's indirection via the registry. It makes a lot more sense to specify new resolver profiles than a whole new system.

[rumkin]

It's not a limitation of DNS - protocols existed when DNS was designed, and it was a conscious choice to make name resolution and protocol specifications orthogonal concerns.

DNS is a protocol with hostname-based configuration which resolves names into IPs and nothing more. It was designed to solve exact problem it was not designed as extensible that what I mean as limitation. But today we have much more hostname-based configuration for protocols like SSL and Email. Email has no it's own configuration mechanism and thus it's using DNS as I shown earlier.

Such system can provide specified configuration for any protocol that we have today and will have in the future. Main idea is to allow developers to provide new protocols in predictable way and make all protocols equal.

It makes a lot more sense to specify new resolver profiles than a whole new system.

There is no reason to replace ENS and resolvers are enough. This ERC is about to receive a feedback and to know in which way I should to move on to make it officially supported. Without community support it will be harden to promote and to make browsers use self signed SSL certificates from ENS.

[Arachnid]

It's not a limitation of DNS - protocols existed when DNS was designed, and it was a conscious choice to make name resolution and protocol specifications orthogonal concerns.

DNS is a protocol with hostname-based configuration which resolves names into IPs and nothing more. It was designed to solve exact problem it was not designed as extensible that what I mean as limitation. But today we have much more hostname-based configuration for protocols like SSL and Email. Email has no it's own configuration mechanism and thus it's using DNS as I shown earlier.

That's not the case; right from day 1, DNS has been used for a variety of types of resolution. RFC1035 included MX, in addition to A, CNAME, PTR and TXT.

Further, that doesn't address my point - that resolving a name to a resource, and determining how to talk to that resource, are two orthogonal problems, and it's a bad idea to conflate them.

There is no reason to replace ENS and resolvers are enough. This ERC is about to receive a feedback and to know in which way I should to move on to make it officially supported. Without community support it will be harden to promote and to make browsers use self signed SSL certificates from ENS.

Then you need to explain concretely what the advantages are of this approach over simply defining new resolver standards for ENS.

[github-actions]

There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[github-actions]

This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.