ENS naming for contracts

[abhijeetbhagat]

Motivation

this issue #10604

Solution

PR Checklist

• Added Tests
• Added Documentation
• Breaking changes

[zerosnacks]

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.

[conor10]

Thanks for your comment @zerosnacks, we have two motivations for connecting to the service:

1. 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.
2. 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.

[zerosnacks]

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.

[abhijeetbhagat]

@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?