foundry-rs
ENS naming for contracts
Motivation
this issue #10604
Solution
PR Checklist
- [x] Added Tests
- [x] Added Documentation
- [ ] Breaking changes
Hi @abhijeetbhagat thanks for your PR,
In my opinion, as a principle Foundry does not directly integrate third party services to remain a neutral actor. I am against recording metrics from users and collecting possibly identifying data such as IP addresses.
Thanks for your comment @zerosnacks, we have two motivations for connecting to the service:
- To provide the necessary ENS contract configuration for the various networks we support. Otherwise this will need to be provided by the user, or stored in Foundry. This would impact UX for users, as there's a number of contract addresses that are required, and they may change. Hence users may misconfigure the contracts, also Foundry could end up with out of date configuration as contract addresses can change.
- To capture which contract ENS names are being registered by the service. This is so we can measure adoption. We are not trying to capture any information that doesn't end up onchain. If we can't measure adoption of the service, its much harder for us as a team to demonstrate traction and impact.
Hi @conor10, thanks for your reply
To provide the necessary ENS contract configuration for the various networks we support. Otherwise this will need to be provided by the user, or stored in Foundry. This would impact UX for users, as there's a number of contract addresses that are required, and they may change. Hence users may misconfigure the contracts, also Foundry could end up with out of date configuration as contract addresses can change.
In Ethers we maintained an address-book that held commonly used smart contract addresses. We are exploring a new address-book implementation for Alloy and would like your input. We already have equivalent packages like chains and hardforks to aggregate this kind of data. In my opinion this would be a suitable place to create a registry for programmatic access, available to all. We do not want to rely on external APIs of third party services in Foundry but a scripted solution could possible pull from your API into the address-book on a frequent basis. We work with alloy-chains in a similar manner where external contributors often contribute changes.
To capture which contract ENS names are being registered by the service. This is so we can measure adoption. We are not trying to capture any information that doesn't end up onchain. If we can't measure adoption of the service, its much harder for us as a team to demonstrate traction and impact.
In Foundry we have at multiple occasions discussed the role of metrics to better evaluate how our users are using Foundry. In the spirit of open source and being conscious of our user's privacy we have arrived at the position that we do not collect data on our users, anonymised or not. This makes evaluating demand for features and measuring adoption challenging but I believe this is the right decision.
I would recommend finding an alternative (technical) solution to measure adoption.
@zerosnacks alright, we'll make the changes accordingly. we'll add the chain config related stuff in chains & remove the api calls to fetch config hosted on our side as well as recording any metrics.
we have an endpoint that fetches an auto generated names. is calling this api fine for you?
After an internal check with @gakonst and a discussion amongst other core contributors we've decided to not move ahead with this proposal to integrate. Foundry does not distribute or provide access to (commercial) third party software with rare exceptions due to high popularity (block explorers) or common security enhancements (popular hardware wallets).
For the future I would recommend to first open a detailed feature request to receive feedback on the idea rather than immediately open a PR with an implementation. This saves time and effort for all parties involved. Open public channels of communication are preferred.
Hi @zerosnacks and @gakonst, I’d be grateful if we could have a discussion on this. It’s disappointing to see this proposal suddenly shut down.
Our goal with this PR is to get developers to name their smart contracts with ENS names. I presume this is something you are supportive of in Foundry?
In terms of our approach, we wanted to make it as simple as possible for Foundry users to name their contracts.
Following @zerosnacks initial feedback that you didn’t want us to include any API interactions, we removed them (the API calls were to track ENS naming activity with the plugin for future grant applications). Following our updates, the PR allows developers to:
- Name their contracts using an ENS name they own
- Name their contracts even if they don’t have an ENS name
The first of these pieces of functionality utilises ENS contracts on Ethereum, Linea and Base mainnets and testsnets. The second utilised an Enscribe smart contract on these networks.
Enscribe is not a commercial third-party service, it's fully, open source and permissively licensed. Is the resistance here that you are not keen on us using any part of Enscribe?
If so, we could simply remove the functionality for naming contracts if you don’t have an ENS name already. Then all the PR is providing is an integration for Foundry where it allows developers to create ENS names when they deploy their smart contracts on Ethereum, Linea and Base.
At Enscribe, we want to see developers naming their smart contracts. If it has to be a direct ENS integration, that’s fine, we can easily adapt it accordingly.
What matters to us is seeing smart contracts being named with ENS names, so end-users stop seeing hex contract addresses which is just plain wrong.
Hi @conor10 / @abhijeetbhagat,
What matters to us is seeing smart contracts being named with ENS names, so end-users stop seeing hex contract addresses which is just plain wrong.
Then all the PR is providing is an integration for Foundry where it allows developers to create ENS names when they deploy their smart contracts on Ethereum, Linea and Base.
In my opinion this is an issue on the wallet provider's end. Block explorers like Etherscan and Sourcify (https://verifieralliance.org/) and initiatives like https://www.openlabelsinitiative.org/ already do a great job in labeling addresses. If developers do want to associate an ENS name with subdomains it is already easily managed using the ENS interface. I am currently not convinced that there is much use to this for developers given that labels cost nothing, do not expire and can be updated easily at no cost. ENS names can also easily expire, be visually impersonated using zero space width characters, etc.
Enscribe is not a commercial third-party service, it's fully, open source and permissively licensed. Is the resistance here that you are not keen on us using any part of Enscribe?
This is not clear from your website, FAQ and proposals. To me - ENS, being a revenue generating product with a token and a perpetual lease cost, does not make sense to tightly integrate with Foundry.
Currently we have some degree of integration with ENS, making it possible to resolve ENS names to addresses. I think this is reasonable as it is useful and comes to no cost to users. I am open to discuss small and concrete proposals to explore other quality of life improvements to make the experience of using ENS with Foundry better.
Regarding the use of any custom contracts: when we integrate anything in Foundry we need to consider its security profile and whether the benefits outweigh the cost and how maintenance of any feature added would work. As it currently stands this is not the case to me. If the integration is only limited to using audited ENS contracts I would be more open to it.