Don't incite developers to bake the canister ID in the frontend

[nmattia]

The default webpack.config.js injects the canister ID in the build as an environment variable. This is not ideal for the following reasons:

• It incites users to actually use the canister ID in the frontend build, effectively baking the value in and preventing the module from being deployed in different environments, as it is unlikely the newly created canisters will receive the same canister ID.
• It prevents anyone from building the frontend code with e.g. npm run build before the canisters have been created, since the default config will (try to) load the canister IDs from .dfx/<network>/canister_ids.json (a file and filepath which are, AFAICT, undocumented).

In the internet identity dapp we work around this by

• Not baking in the canister ID, but instead read it from the canister itself
• Only reading the local canister_ids.json file when a local development server is started

I think those are good practices, maybe they could be added to the default generated canisters and examples?

[bitdivine]

I would like to add my voice to this. I have read up and talked to Nicolas and there are a couple of ways this impacts us:

• In the CSP header, according to security best practices, we need to declare which endpoints are are going to be accessing. For any canister with a custom domain name, such as https://nns.ic0.app or https://identity.ic0.app, agent.js does not make calls to the custom name but rather to https://${CANISTER_ID}.ic0.app. I would like to propose that Agent.js should use the custom domain name. Agent.js CAN be used in nodejs in which case the runtime doesn't have an origin, so in this case an Agent can reasonably default to using ${CANISTER_ID} + ${PARENT_DOMAIN} but that is a corner case. The common case is for Agent.js to be used in a a web browser, and there it should be possible to send API calls to the origin.

[bitdivine]

• The second place where agent.js needs the canister ID is in the ingress message itself. There is probably no way of getting around that. However this is a very common requirement so there should be an easy, standard way of giving the Agent the canister ID. What are the options here? Should there be a standard endpoint that yields the canister ID? If an Agent is created with no canister ID, the canister could call the origin and ask for it.
  • Note: I am concerned about adding latency. From the perspective of latency, I would be tempted to have a script tag high up in the index.html that makes a certified query that returns document.MY_CANISTER_ID='XXXXX';. This would set the canister ID as a global that can be used by other code. Prettier suggestions that still minimise latency are welcome.

What do you think, @krpeacock et al?

[bitdivine]

Note regarding serving the canister ID on a common, well known endpoint: If a CSP is provided in index.html, providing the canister ID via another endpoint is too late unless we can also address the issue of the agent calling to the origin, rather than to $CANISTER_ID.$PARENT_DOMAIN.

[krpeacock]

This has assumptions that could become an issue for certain use cases, and can be implementation specific to II. Consider the following situations:

• an app is hosted on the IC, on a different canister than is serving the index.html
• an app makes calls to many canisters
• an app is not hosted on the IC