[FOLLOW UP ON ITEM] New canisters will only be accessible through the icp0.io domain. Existing canisters will be accessible both through ic0.app and icp0.io

Developers
21

@jwendling and @raymondk I understand your points. Please understand mine: it just needs to be as good as the last domain. If I change it and within an hour a dozen people DM about seeing a site error while trying to access it… that is truly bad. This is exactly what happened last time I changed the domain over to icp0.io.

The ic0.app domain never had a user report to us… (1+ years of use).

Scams sites are basically, almost always blocked by Dfinity at this point. I know this because we index all of the sites on the IC and have worked with your team on this in the past.

icme.io: deploys apps for users. We do not control their domains, they can set them up if they want to, but by default they are the standard domain provided by the IC.

kinic.io: indexes FE on the IC… It does not gather or map custom domain names.

"Just use a custom domain for your dApp… " is not a good answer in our case. Thank you!

1 Like
22

It’s OpenDNS not cisco. Here is the page it redirects me to https://phish.opendns.com/main?url=raw.icp0.io&server=chi3&prefs=&tagging=&nref

1 Like
23

Update:

Based on all feedback from the community, this change is being postponed for a month (target: end of April, most likely April 20,2023), with the intent to give folks more time to:

  • Make whatever changes they need for their dapps
  • Make more noise about the change so more people see it
  • Engage & iterate with the community more about the situation surrounding domains
3 Likes
24

@apotheosis
I completely understand your point of view and it is also important to us that icp0.io has a good reputation and we actively address every blocklist entry. Unfortunately, we cannot guarantee any reputation.

The fact that we had the Google Safe Browsling listing on the day of your conversion was really unfortunate and it is understandable that this causes uncertainty.

"Just use a custom domain for your dApp… " is not a good answer in our case. Thank you!

Sorry, this was not meant to be directed at you directly, but a general recommendation. I understand that in your case it is not simply done with a custom domain.

Could it be an option for icme.io dApps to register a custom domain under a domain that you control instead of using the default domain? E.g. dapp-name.sites.icme.io

@BHare1985 AFAIK Cisco acquired OpenDNS a few years ago. But no matter who maintains or manages it now, we will file a request to have icp0.io removed.

3 Likes
25

Started to look into subdomains today! :slight_smile:

2 Likes
26

Just a reminder, this change will happen on April 20th, 2023! (3 days from now).

27

Is it possible to know the precise timeframe and timezone it will happen?

28

sure let me ping team. Not sure how precise it can be, but maybe a helpful range.

out of curiosity: would you mind elaborating on the intent behind your question so we can best address it? Are you asking because you want a bit more time before the switch? or something else? I am asking in case the answer is a 12-hour range, would that be helpful? thank you

29

Hi @Zane It will be done around 5pm UTC

2 Likes
30

I’ve asked cause I’ll present at an ICP workshop on the 20th and one of the canister I’m planning to show participants how to deploy assumes its URL on mainnet ends with “.raw.ic0.app”

1 Like
31

I see, thanks for the info.

1 Like
32

FYI - you can already use .raw.icp0.io and it might make sense to do that in your workshop.

1 Like
33

Hello!

The Boundary Node team deployed this change today. Any new canisters created will not be available on ic0.app anymore. As usual, they will be available on icp0.io.

The following should illustrate the behavior change:

internetcomputer.org (old canister) => oa7fk-maaaa-aaaam-abgka-cai

Works on ic0.app => curl -sLv https://oa7fk-maaaa-aaaam-abgka-cai.ic0.app
Works on icp0.io => curl -sLv https://oa7fk-maaaa-aaaam-abgka-cai.icp0.io

5perb-kiaaa-aaaag-abkaq-cai (new canister)

Blocked on ic0.app => curl -sLv https://5perb-kiaaa-aaaag-abkaq-cai.ic0.app
Works on icp0.io => curl -sLv https://5perb-kiaaa-aaaag-abkaq-cai.icp0.io

4 Likes
34

As a uni student, when connecting to eduroam across different UK universities 0 canisters are currently working.

Either prompted with Failed to fetch response: TypeError: Failed to fetch

Or “Your connection is not private NET::ERR_CERT_COMMON_NAME_INVALID”

1 Like
35

Thanks for letting us know, let me escalate this.

36

Hi @LowFreeKey, can you give us more detail please?

This looks like a certificate error - are you behind a university firewall or VPN?

  • what is an example of a URL are you using?
  • what is the output of the following commands:
curl -sLvv https://5perb-kiaaa-aaaag-abkaq-cai.icp0.io
curl -sLvv https://5perb-kiaaa-aaaag-abkaq-cai.ic0.app
37

If we’re managing multiple canisters from the same project, is there a recommended approach to how we should handle setting our provider(s) in our dfx.json after this change?

Do I list multiple providers in my dfx.json as follows:

{ 
  ...
  "networks": {
    "ic": {
      "providers": [
        "https://ic0.app",
        "https://icp0.io"
      ],
      "controllers": {},
      "type": "persistent"
    }
}

If I do the above, is dfx smart enough to determine which canisters are managed behind which provider?

Are there any drawbacks to managing existing canisters through the old domain, or is that preferred?

38

I would recommend you use only icp0.io as the only provider in dfx.json. The provider handling code is ‘not as nice as I’d like it to be’ and only picks the first one in the list :frowning_face:

1 Like
39

Thanks for the update :slight_smile: will follow that pattern. Any known pitfalls of managing older canisters on the newer domain?

40

The only two pitfalls that I’m aware of are:

  • asset canister CSP: Your asset canister(s) may have a content security policy set for it to only accept assets from the old domain. Check in your .ic-assets.json files (if present)
  • Internet Identity login produces different IDs when logging in through a different domain. This is a limitation/feature of how WebAuth works
1 Like