-
Notifications
You must be signed in to change notification settings - Fork 2k
ENS naming for contracts #10605
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ENS naming for contracts #10605
Conversation
This reverts commit 9b88580.
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:
|
…foundry into ens-naming-for-contracts
Hi @conor10, thanks for your reply
In Ethers we maintained an
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 we have an endpoint that fetches an auto generated names. is calling this api fine for you? |
@zerosnacks review please? |
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:
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,
In my opinion this is an issue on the wallet provider's end. Block explorers like
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. |
Motivation
this issue #10604
Solution
PR Checklist