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 And the end user doesn’t care how that feature is used.
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.)
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.
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.
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.
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?
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?
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.
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.