# ENS 2019 Workshop Notes

# Re-brand

- Right now ENS does not just serve Ethereum
- There is confusion around the use cases for ENS
- ENS can be used for example for IPFS
- Public resolver supports all traditional DNS records
- While ENS is *built* on Ethereum it's *not just* for Ethereum
- Remember the target audience, People who need to know will understand some tag-line
- one of the few products that actually has Ethereum in it's name
- This gives increased credability
- What is the long term capability of ENS? How will it scale voer time? Is the actual market strategy to continue focusings on Ethereum
- Long term goal is to provide decentralized naming for anything that can use decetrnalized naming
- In the case for Ethereum, specifically for naming a user address.

## Options

- Don't re-brand, lean into the current name.
- Keep ENS, change what the name stands for
- What does the E stand for?
- Benefit of keeping the E is we don't change the letter
- Technical
- Sounds like a protocol
- rolls of the tongue

- Change the name completely
- Triangle name service ([Zuckos triangle](https://en.wikipedia.org/wiki/Zooko%27s_triangle))
- Don't want to conflict with somebody else ZNS? TNS?
- Could just be called triangle
- Could have multiple names/services? Triangle is the system ENS is the product?
- If it doesn't change it doesn't accomplish the branding purpose
- ENS aims to do everything DNS does and more
- As a brand name, is ENS a good name?

## ENS as Login/Identity

- Demo →[http://hadriencroubois.com/enslogin](http://hadriencroubois.com/enslogin)
- Resolves an ENS name to a web3 provider leveraging IPFS
- If nothing is find on the main domain, it will continue on to following entries
- Loads JS snippets off of IPS to connect to provided network
- RIght now, if you use the wrong ENS there's no error
- Could be a major security issue
- 2 cases, one where you only provide the provider, one where you have the provider and the address
- ENS login solves, once you have a wallet you can login to a DAPP
- How do you get users registered who don't already have a wallet.
- DApp could choose which wallet providers they want to use for registration.
- Currently the implementation ahs been very straight forward
- We need mroe wallets registering ENS names on behalf of their users.
- If an application supports ENS login, this will reduce barriers to entry since applications don't need to "back in" specific wallet support
- If user sign is can be simplified by using ENS sub domains this incentivizes wallet providers to issue subdomains
- One of the major blocks to entry is the gas cost for assigning a user a sub-domain
- Signing a transaction is far more palatable from the users since they don't spend gas in doing so
- We need a single standard around login/identity patterns
- Portis/ENSLogin/others?
- How do you make cheap free sub domains Sybil resistant?
- Is there an easy quick mining to pay for addresses?
- POW solution to sybill resistance
- Does there exist a form of Ethereum captcha that generates enough fund to create an address
- Watch an add? Fill out a survey?
- BAT?
- Progressive on-boarding
- Custodial solution that changes into a non-custodial solution once the user starts using the service more
- Similar efforts in terms of progressive on-boarding for other processes
- shipl (meta-transaction service with charges in FIAT)
- Subscription based top-up model
- Next steps for Authereum
- Post the standard on Eth Magicians
- ANother coordinated call
- Cross-post to ENS forum
- Web3connect?
- What's being integrated? ENSLogin? Web3Connect?
- Web3Connect is the default way to integrate ENSLogin
- NEED to avoid having two ENS login ipmlementations with split user login flows
- There's also conversation around standardization for web3 providers, standardization for RPC support
- ENS standard should *stay* different

## Reduce Dependency on the root multisig

- At the very top of the ens Hierarchy we have the root domain
- This domain has essentially admin rights
- This domain is controlled by a multi-sig
- Allows for upgradability
- Can change prices as it has control over the Oracle solution for pricefeeds
- Root contract owns root name, multi-sig owns root contract
- Allows the same control pattern in the future, allows you to connect a new controller for DNS name space integration.
- There is a flag for each top level domain to "lock out" the top level domain
- This switch allows for less top down control to exist over the registrar
- Flipping this today would prevent the multi-sig holders to control anything beyond controllers
- Moving over to a DAO model could prove disaterous if the governance is comrpomised since current multi-sig has high leve of control
- ENS multi-sig approval has high requirements right now and there's a decent amount of coordination cost around this
- There's a time-cost in exercising due-diligence for ENS multi-sig movement
- Link time-lock to the voting period for singing
- Have the duration of time lock directly correlated to the number of approvals
- Being able to tell clients a *maximum* amount of time has a lot of value
- Build a reputation registry around people who have done things on time/well
- Build this reputation over time so that users can become
- If there's already no participation, then they won't be
- ETH register and Root are the same owners
- Are these two components decoupled?
- Can see situations here they have different owners, this would allow for decentralization of registrationfees
- As long as the answer to the question "Who should do this" is a few trusted individuals then it makes esne to mirror them
- In the past it's been clear that the reason ENS names have a fee is to prevent people from claiming all the names and then re-selling them
- Need to prevent squatters → cost
- Prices should be set at the level that makes the system work the best, instead of having the rent dictated by the cost of development
- Is there a level of abstraction about the TLD?
- ROOT key is above ETH
- You could deploy your own registry and
- Is the multi-sig ever going to go away?
- Is it better to have companys control keys on a multi-sig?
- Act as individual capacity or organizational capacity?
- There is liability around having a company have this responsibility
- Is there an ENS company?
- TrueNames limited
- Pays for development of ENS through EF grant
- Multi-sig holders direct funds to companys working on ENS
- How much can you un-bundle the functions of the multi-sig holders?
- For top level domains, the multi-sig should be removed from the TLD process
- Needs basic tooling for reviewing requests
- Currently the multi-sig holder list is a closed list
- This could allow more people to receive the needed information
- As the system becomes more stable, the power of the multi-sig decreases.
- Require there is only one direction of power (once it's relinquished it's not taken back)
- Having audit-ability with the ability to exit(fork)
- Ability to timelock with an emergency mechanism?
- The less the multi-sig can do, the less liability they have
- Is it possible to enumerate the actions that would need to be done for an emergency fix
- For DNS TLD, let traditional DNS always override it
- This doesn't take into account the javasript library may be the most viable attack vector if somebody actually wants to comrpomise the system
- What is the governance proces around the javasript library
- If Infura is hacking you could just return your address for any transfers
- The Current method is to check that 2 providers return the correct address
- Build ENS name resolution directly into web3 provider?
- Querying multiple points will generally be more reliable than providing your own node
- Assume if you are hitting infura, metamask, your own node etc that's the most secure option
- What's the validation process for DNS?
- Process of hierarchical signing
- Root key signs top level and this get's passed down based on key signatures
- Can a negative feedback loop be used to regulate price?
- Duration that people register sites for could be a possible metric
- Could be gamed?
- People may be inelastic in their preferences
- Would potentially need one year to understand whether price regulation works.
- Main take-aways:
- Build in some sort of time-lock → veto process
- Split up the responsibility over different things that need to be done by "power user" class
-Overview of current resolver functionality

- You can build whatever kind of resolver you'd like
- One of the main barriers right now is the inability to right wildcard resolvers (you can't just point a bunch of names at the same resolver automagically)
- For aliases, this could probably be handled in the resolver, it's just a matter of writing a "proxy resolver"
- In order to support wildcard resolution all ENS would need to change
- You could try sequential resolution If not A, B if not B C

# Resolver Innovation

## Wishlist

- Can we just enable a client side solution? Does it make sense to do something special if there's no resolver set
- It's easy to make changes to the client side, but difficult to propagate them
- What might work on this next weeks MetaMask might not work on last weeks
- What's needed to make sure recursion support in the client is backward compatible?
- There's something to be said for how early it is; there are *not* many librarys that need to be changed over
- For wildcard resolution there are two options:
- Change the registry
- Support wildcard resolution in the client
- Is it possible to have a "fallback" registry?
- It's difficult to make the old registry read only, so now you're dealing with two distinct registries
- We could have a proxy that in turn looks up a registry
- System built by using the sum of two public keys having equality to sum of two private keys
- One limitation of the system is that you could in theory send funds to an address that isn't known to have been programatically generated yet - You'd never know to claim those funds
- Use cases:
- Send out sub-domains to users, this allows reservations to happen off-chain so that sub-domains only actually need to be setup after the fact
- Might be able to get exchanges to adopt this, since sub domains can be automatically generated for deposits
- Should this be changed in interfaces?
- What are the compelling use-cases where you need a label?
- Supplying a label for sub-domains means that every standard would need to then take labels
- The resolver would have one additional call like "getRecursiveHash"
- Is this an entirely new resolver? This means the standard doesn't have to be imposed on pre-existing elements
- Is there a security risk if the last step is public derivation?
- This doesn't necesarily solve any questions

### Action Item - Start a conversation around wildcard resolution

- Should the initial resolver be a default value? Can there just be a function param for resolver?
- Can we make it so that when a second level name is registered it defaults to a certain resolver?
- This makes sense since if somebody wants to change it, then they can change it
- Could fund "changing it" the first time based on the payment to reserve a name
- Registering on behalf of other accounts can currently be supported
- Encrypt user input output by default
- Current metamask integration with IPFS for URL passes out a hash, what's required for resolvers to work out of the box with metamask?
- Need an order of precedence around multi-hash, URL etc
- One of the original use cases of ENS was un-censorable DNS
- This works with direct ENS with a plug-in for core-DNS
- This means you can just lookup ENS
- For this to work you need to point your computer to a specified DNS server that supports this plugin
- One of the issues with this right now is the lack of SSL certificates
- Self signed certificates may be more helpful than trusting the NUMBEROUS CA signers right now
- Aiases?
- This can be supported without major changes, first step would be to just check if there is an alias
- Not all cases are necessarily something that can be handled with just a mapping
- What are use cases for ABI lookup?
- For example Ethers.js will support connecting a contract given just an ENS name for that contract
- This can be more difficult do to having to support the whole ABI
- Add two more formats?
- IPFS multi-hash
- human readable ABI
- PKI?
- In the future when web3 is integrated into browsers, you'd expect them to have their own nodes aswell
- Then there arn't any gateways
- What's stored? The hash of the Certificate?
- The main challenge here is getting browsers to accept this as a valid form of certificate signing
- A good thing to check at first is why [DANE](https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities) isn't working correctly
- Standardize some sort of keybase 2 way account epgging?
- Create a 2/3D array for account validation
- Could setup a reverse registry for anything you can actually prove on chain
- Validated text records for the EIP?
- A lot of things start off as text records, then they stay that way or become a validated type later on
- Sometimes things start off as their own resolver type (multi-address)

# Resucrsive resolution/wildcard sub-domains

# Rent/Payments in DAI

- This is largely inspired by the DeFi stuff that's happening. The idea is if you want to put the money up front, you can just put DAI into the contract
- How difficult is it to extend the options for payment to other tokens
- Can this just be done client side
- The front end can just send the value through a Dex, but this picks up fees along the way
- You ould need to add support for these tokens one by one
- In an ideal UX flow the user wouldn't even know they
- *How do you make a rational self-regulating negative feedback loop for registration*?
- There are two main challenges here:
- UX challenge (handle swaps through a DEX?)
- Is it a better UX if there's actually an extra step for DAI
- Volatility challenge
- There are services existing that will just abstract away the users need to interact with ETH
[https://www.encirca.com/](https://www.encirca.com/)
- A third party (or ENS) could just accept visa payments
- How do you then avoid chargeback?
- What sort of premium can you charge for allowing a user to buy ENS domains
- Should there be a meta-transaction fro ENS?

EthDNS Project
[https://medium.com/the-ethereum-name-service/how-to-host-your-dapp-with-ipfs-ens-and-access-it-via-ethdns-c96046059d87](https://medium.com/the-ethereum-name-service/how-to-host-your-dapp-with-ipfs-ens-and-access-it-via-ethdns-c96046059d87)?

ENS vs DNS

- ENS is not trying to *compete* with DNS (not trying to give out overlapping namespaces like google.com)
- ENS is trying to provide alternative infrastructure
- Plenty of projects have failed in an attempt to replace all name spaces
- How does NFT work for DNS registered domains (com)
- Have applied to create an official DNS namespace for ethereum addresses
- ICANN engineers have requested standardization
- Name space systems are simple,
- You just have names→ records
- Currently .ETH is soft-reserved by Ethiopia
- Is there any way to simplify the DNS claiming process?
- There's a standard for service providers setting ENS records
- DNS sec oracle?
- Oracle is almost entirely trustless, when you instantiate it you give it the root keys for ENS
- All validation happens on chain
- he algorithms/digests are configurable by mapping, as long as the owner is set to 0x0 it's trustless

### Future Focuses

- Focus on current development
- Batched Transactions
- Homograph attack?
- Whenever a character is outside of ASCII just highlight it?
- Just default to informing the user if they're interacting with an address for the first time
- Issues around different visual representations of the same name
- ENS Login work
- Bully wallet operators to always have compatibility with ENS
- This is why we need multi-coin support
- Wallet naming in general will probably be winner take all
- Decent wallet
- Trustwallet
- Especially important for wallets to support reverse resolution
- Verify sourcecode on Etherscan
- Add documentation for controller
- More ENS login
- ENS Alliases
- Budget request models
- Default resolver
- Recursive resolution
- More domain names (default resolver)
- Giveaways
- FIO collaboration
- VC funded
- Direct resolution in Brave