Conversation
There was a problem hiding this comment.
Should this be part of this PR?
There was a problem hiding this comment.
Oh I see, adding IDataResolver to DNSTXTResolver
| import {IResolverSetters} from "./IResolverSetters.sol"; | ||
|
|
||
| /// @dev The complete interface selector: `0xff38f248` | ||
| bytes4 constant RECORD_RESOLVER_INTERFACE_ID = type(IResolverSetters).interfaceId ^ |
There was a problem hiding this comment.
Isn't this accessible via type(IRecordResolver).interfaceId?
There was a problem hiding this comment.
I added those because the inherited interfaces don't contain the inherited functions.
Possibly, we need this "complete interface" logic in other places in ENSv2. ENSv1 didn't use any? inherited interfaces.
| /// @dev Mapping from `recordId` to `version`. | ||
| mapping(uint256 recordId => uint256 version) internal _versions; |
There was a problem hiding this comment.
I thought part of the idea was that we eliminate the need for versions altogether? When we want to reset a record, we can just rm it, and create a new one with a fresh inode; no need for a versions mapping.
There was a problem hiding this comment.
I thought that too, but the problem I ran into was unlink() vs clear()
link(name, 0)disassociates from inode from just nameclear(name)clears the inode, but it doesn't know how to update all of the other pointers- eg.
inode["a"] = 1, inode["b"] = 1, clear("a"), inode["a"] = 2— how do I update "b"?
- eg.
So a separate level of indirection (version again) solves this.
Co-authored-by: Nick Johnson <arachnid@notdot.net>
DNSTXTResolverIDataResolver(ENSIP-24) supportIRecordResolverIResolverSettersIPermissionedResolverIExtendedResolverIDataResolver(ENSIP-24) supportlink(name, node), andgetRecordId(node)grantNamedRoles()withgrantRecordRoles(name, roles, account)grantNamed{Text|Addr}Roles()withgrantSetterRoles(setter, account)IAddressResolver,ITextResolver,IDataResolver,IABIResolver, andIInterfaceResolverresolutions.tswritetowriteV1writeV2