Throw if resolver isn't set

ethjs / ethjs-ens

An Ethereum Name Service interface module built on EthJS

34 stars 17 forks source link

Throw if resolver isn't set #6

Closed danfinlay closed 7 years ago

danfinlay commented 7 years ago

Instead of resolving to owner

Per https://github.com/MetaMask/metamask-plugin/issues/1427

Arachnid commented 7 years ago

Resolve to owner instead of owner? If resolver isn't set, this should throw an error.

kumavis commented 7 years ago

@Arachnid no resolve to owner if resolver is not set

kumavis commented 7 years ago

e.g. inspecting juventus.eth via https://etherscan.io/enslookup shows

Resolver: 0x0000000000000000000000000000000000000000
Owner: 0x96eadd1c4becb9710b426587b4eceed8ba8b1d78

here we would resolve to the owner since resolver is not set

danfinlay commented 7 years ago

My typo.

Arachnid commented 7 years ago

@kumavis Please don't do that. The owner record should never be used as the result of resolving.

kumavis commented 7 years ago

@Arachnid why not? seems like a sane default

kumavis commented 7 years ago

100% of users will assume that once they own their ens address, its theirs and they can use it as proxy to themselves (without additional config)

kumavis commented 7 years ago

@Arachnid do you have a resource we can send to our users to instruct them out to configure their ens contract?

tayvano commented 7 years ago

(copied from slack conversation for the public record)

I think that throwing if resolver isn't set (or if resolver == 0x0...) is the right choice, personally. I think the solution to "individual users not having to do add'l configs" is the responsibility of the UI to make it easier for people. Ideally I would like the flow to be this:

reveal your bid
you win
you come back to finalize
you select whether you just want to finalize the auction, finalize + resolve using public resolver (the latter is for majority of "average" users - this also allows for easier expansion as more resolvers become available)

The latter will then producing 3 TXs / calls: finalizeAuction, setResolver on public resolver address, and setAddress as the owner address.

Arachnid commented 7 years ago

I agree with @tayvano, and this is how registrar.ens.domains works too.

My arguments against defaulting to the owner:

It privileges the addr record with a default and different behaviour over all other record types.
A name simply not working is an obvious error, but having it send to the wrong address is not.
Users will be confused about whether they can point the domain elsewhere without transferring ownership entirely.
Setting a resolver will suddenly unset the address mapping, which can result in confusion and outages.
It's not in the spec.

Arachnid commented 7 years ago

RE simple resources, so far the only options are the command line or registrar.ens.domains, which provides a simple interface for setting the public resolver and specifying a record. We're working on a more sophisticated, independent app, however.