9e393a79d9
* Include LICENCE in the Jekyll build * Replace old licence link with new and improved licence link * Add note to EIP-1 mandating the new link * Maybe this fixes it? * Rename LICENCE so that jekyll picks it up * Add original LICENCE file back * Delete the markdown file * Add Jekyll header Hopefully the tooling still detects it as CC0 * Remove Jekyll header * Maybe this will trick Jekyll and satisfy github? * Remove config changes * Enable incremental build * Will it work if I rename it? * I'll just paste the content of the licence into the file... * Perhaps this will work * Replace the licence file * Fix false positive Co-authored-by: Micah Zoltu <micah@zoltu.net> * Resolve feedback * Perhaps this might work * It didn't work This reverts commit 55116e15168fb20ae57dea97388bb260c0941465. * Will licencee still detect this correctly? * Jekyll Preamble in licence file * Include it? * Licence -> License, get rid of CC0.md * Force wording of copyright waiver * Formatting consistent with the rest of the list * Spelling * Escape * Task failed successfully * Fix two more links * Will this render it? * Perhaps this will work too * .md essential * Fix the issues Micah noted Co-authored-by: Micah Zoltu <micah@zoltu.net>
3.3 KiB
| eip | title | author | discussions-to | status | type | category | created | requires |
|---|---|---|---|---|---|---|---|---|
| 1844 | ENS Interface Discovery | Nick Johnson (@arachnid) | https://ethereum-magicians.org/t/ens-interface-discovery/2924 | Stagnant | Standards Track | ERC | 2019-03-15 | 137, 165 |
Simple Summary
Defines a method of associating contract interfaces with ENS names and addresses, and of discovering those interfaces.
Abstract
This EIP specifies a method for exposing interfaces associated with an ENS name or an address (typically a contract address) and allowing applications to discover those interfaces and interact with them. Interfaces can be implemented either by the target contract (if any) or by any other contract.
Motivation
EIP 165 supports interface discovery - determining if the contract at a given address supports a requested interface. However, in many cases it's useful to be able to discover functionality associated with a name or an address that is implemented by other contracts.
For example, a token contract may not itself provide any kind of 'atomic swap' functionality, but there may be associated contracts that do. With ENS interface discovery, the token contract can expose this metadata, informing applications where they can find that functionality.
Specification
A new profile for ENS resolvers is defined, consisting of the following method:
function interfaceImplementer(bytes32 node, bytes4 interfaceID) external view returns (address);
The EIP-165 interface ID of this interface is 0xb8f2bbb4.
Given an ENS name hash node and an EIP-165 interfaceID, this function returns the address of an appropriate implementer of that interface. If there is no interface matching that interface ID for that node, 0 is returned.
The address returned by interfaceImplementer MUST refer to a smart contract.
The smart contract at the returned address SHOULD implement EIP-165.
Resolvers implementing this interface MAY utilise a fallback strategy: If no matching interface was explicitly provided by the user, query the contract returned by addr(), returning its address if the requested interface is supported by that contract, and 0 otherwise. If they do this, they MUST ensure they return 0, rather than reverting, if the target contract reverts.
This field may be used with both forward resolution and reverse resolution.
Rationale
A naive approach to this problem would involve adding this method directly to the target contract. However, doing this has several shortcomings:
- Each contract must maintain its own list of interface implementations.
- Modifying this list requires access controls, which the contract may not have previously required.
- Support for this must be designed in when the contract is written, and cannot be retrofitted afterwards.
- Only one canonical list of interfaces can be supported.
Using ENS resolvers instead mitigates these shortcomings, making it possible for anyone to associate interfaces with a name, even for contracts not previously built with this in mind.
Backwards Compatibility
There are no backwards compatibility issues.
Test Cases
TBD
Implementation
The PublicResolver in the ensdomains/resolvers repository implements this interface.
Copyright
Copyright and related rights waived via CC0.