# 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