Custom domains for ic0.app [Community Consideration]

Summary

Currently, URLs for the Internet Computer are derived solely from Canister IDs which are… difficult for humans to remember. Discuss implementations and plans for custom domains, and DNS to canisters.

Status
Community Consideration

What you can do

  • Ask questions
  • Propose ideas

Documentation:

Key people involved
John Plevyak (@jplevyak )

Relevant Background:

10 Likes

What I am really hoping for here is for the vision in this Tweet by Dominic to be achieved: https://twitter.com/dominic_w/status/1393268099109965826?s=20

He mentions that the IC will be a giant DNS server. I really think that vision is compelling, and the IC could become possibly the most secure DNS server ever to exist.

Perhaps there are multiple iterations to enabling custom domain names, but I do not think we should compromise on the eventual direct integration of DNS with the IC.

10 Likes

Instead of calling these vanity URLs, I would suggest naming this improvement “custom domains”.

7 Likes

Great idea. @Jan @samuelburri what do you guys think?

2 Likes

I’m not sure why this isn’t a priority. In my opinion it should be the next thing on the the to do list. Calling it vanity URLs is really odd and dismissive of how important it will be for adoption.

6 Likes

Given that much of our civilization is built on vanity (think of early long distrance trade that was mostly fueled by vain demand for odd spices and ornaments), “vanity URL” doesn’t sound bad to me :smiley: And the end user doesn’t care how that feature is used.

Strawman proposal:

  • Build a simple “name registry canister” that stores “vanity name, controlling princpal, current destination” triples
  • Provide a query interface to get the current value, and include a certificate that proves that the returned value is correct (or that the requested name is not registered.)
  • HTTP Gateway / service worker use that query to look up (and cache) the canister to talk to.
  • The controlling principal can change the destination, and also change the controller to someone/something else
  • Scaling beyond 4GB is done via extending the stable memory; query throughput scaling is handled by the subnet. This way this can be stay one canister for a long time, which is simple, reliable and robust.

That’s the easy part. Tricky parts are, probably:

  • If registration is first-come-first-service and free or cheap, will there be bad name grabbing?
  • Do we need a NNS proposal to transfer ownership, e.g. if someone got a trade name?
  • Do we need configurable caching policies, like in DNS?
  • Do we need a bridge into real DNS? (I don’t think we need that with the current architecture with Gateway nodes.)
7 Likes

I certainly think this should be a top priority. Hard to build truly decentralized projects if we’re relying on Google or Amazon for edge nodes to route traffic from custom domains.

I second the idea that we need to refer to them as “custom domains” and not vanity URLs.

Bypassing traditional DNS seems important for true decentralization. I’d love to see Don’s full vision of the chain acting as a DNS.

6 Likes

I’m not sure why this isn’t a priority. In my opinion it should be the next thing on the to-do list. Calling it vanity URLs is really odd and dismissive of how important it will be for adoption.

Fwiw, I did not name this, but “dismissive” was not the intent when I heard this. So if that is how it is landed with people, then maybe renaming it “custom domains” (as @lastmjs recommended) makes more sense.

5 Likes

I get that IC is “bleeding edge” and that the current URLs is one of the sharp edges. However, it’s the first impression we are making to those not familiar with the IC yet. As others have mentioned, custom URLs are key to wider adoption by those that don’t care as much about the tech, but are just coming for the apps/services.

8 Likes

Follow up: Based on feedback on this thread, we changed the name of the project from “Vanity URLs” to “Custom Domains” to better reflect its intent. We are still discussing how to staff and better engage on this thread, but you should know we (including the lead @jplevyak ) are monitoring the thread.

5 Likes

Speaking as a web developer who is planning to move everything away from the legacy cloud and onto the IC, this is of crucial importance.

I saw Dominic say that the current canister derived domains are good because they let people see that the website or service is hosted on the IC rather than AWS. I think this is a mistake.

Custom domains and SSL are key for those of us who actually want to start moving client websites onto the IC.

Once we have this working we can turn our attention to building new canister based static site generators and content management systems.

12 Likes

As an ex corporate digital strategist I also agree that this and the web assembly OS are extremely important.
I would like to see this being made a top priority.

Fleek is a great first step but let’s take it all the way :partying_face:

5 Likes

IC Novice here.

Based on the conversation it seems like the assumption is that ic0.app is intuitive - have to be honest here - I don’t even know how to pronounce ic0, and I don’t know what the “0” represents. Anyone who has never used the internet computer is going to have at least some lever of discomfort with the ic0.app.

I agree the custom sub domain names are an improvement, but seems like it would be easy to improve on the domain. Can the community petition ICANN for a new gTLD such as .ICP?

1 Like

Good question. I will ask team

I was under the assumption that this feature was meant to support completely custom domains (like demergence.org, stoicwallet.com). Has that been changed? Are we only shooting for custom subdomains on ic0.app?

2 Likes

I have the same impression as you, Jordan… but when I wrote above I realized that I had always assumed it, I didn’t actually ever asked anyone explicitly it.

I pinged folks who know more than me to get an idea of the theoretical state of the world to make sure I’m on same page with what’s possible snd/or reasonable.

3 Likes

Are we going to get the chance to vote on this? What would it take to get a formal proposal submitted to the NNS?

1 Like

Annoying as it sounds it is very unlikely any new TLD such as .ICP will be allowed by ICANN as a one-off. It will have to be applied for (along with many other hundreds and possibly thousands of applications) in the second round of new TLDs. Applications for the first round of new TLDs (like .APP and .BIKE etc) were opened early 2012 and the first approved new TLD went live for general use in Feb 2014, 2 years after applying. Applications for the second round won’t go ahead until ICANN has given the go ahead to the process, which it hasn’t yet. According to reports the ICANN board will not approve the second round until Q2 2022 at the earliest. With improvements to the application process and assuming Dfinity gets the string (they will be competing against other applicants) it is unlikely .ICP will be available for actual use until Q3/Q4 2023. Even then this is a very optimistic timeline, ICANN is notoriously slow and bureacratic.

Custom sub-domains (subdomains*.ic0.app) could be the way to forward in the meantime. Perhaps with a process for Dfinity approved custom sub-domain holders having rights to the matching .icp when it is live (to give some continuity in naming).

Other considerations include whether .ICP would be the right string to apply for and also whether ic0.app is the right root domain for the custom sub-domains (removing any barriers to adoption should be the key).

Note: The domain ic.app is already registered (Jan 2021) and it’s unclear whether this is owned by Dfinity. Not criticising the choice of ic0 but ic would have been ideal as the root for sub-domains (avoiding the 0). Although I don’t know enough about IC’s structure how big a change this would be. Or whether ic.app (or some other IC root) could be run in parallel to ic0.app.

5 Likes

I need to be able to use any GTLD that I choose, just like I can with AWS etc.

This is a major stumbling block for me and more importantly, my clients.

3 Likes

I am trying to remember why you can’t simply set a CNAME from your domain to <canisterid>.ic0.app, and the relevant components (boundary node and certifying service worker) will query DNS to read the CNAME to get the canister id to resolve to…

Ah, there is TLS. The boundary node would have to aquire a certificate for that domain on the fly. But is that a problem these days, with letsencrypt being a thing?

And then there is the problem that top level domains can’t be CNAMEs. How about a TXT entry then?

Of course, NIH’ing some completely new system, nicely on chain with governance and everything would be fun. But to move the IC forward and make it usable with arbitrary domains, just matching what, say, GitHub Pages has been supporting for a long while, maybe be prudent? And it only affects the two boundary components.

4 Likes