ICNS x Psychedelic: Our Plans for the Internet Computer’s Naming Service
Roadmap update time! Today we’re talking about our partnership with PsychedelicDAO and laying down our roadmap for the short to medium-term future.
It’s been quite a few crazy weeks for the ICNS team since our genesis launch and we just wanted to take this opportunity to share with our community some exciting updates, outline our plans for the future, and thereby instill confidence in users and builders that the future of ICNS is bright!
As we’re sure you’ve heard, we joined the PsychedelicDAO team! This is a huge milestone for ICNS, the IC ecosystem as a whole, and will surely help to lock-in ICNS as the IC’s naming system of choice.
Today, we’ll dive into this new partnership and why it’s a big deal for the ICNS ecosystem, then we’ll review some of the community’s queries around how ICNS is structured right now, and end off with some of the new features & improvements that are right around the corner!
Joining PsychedelicDAO 👽
Joining the PsychedelicDAO collective was a pretty easy decision — the synergies between ICNS and Psychedelics product suite are plentiful.
On top of this, and arguably more important, ICNS is first and foremost built to be an unstoppable, decentralized open internet service, which mirrors the set of values that Psychedelic has laid out for their products as well.
In addition, we joined Psychedelic for the backing & trust that ICNS gains by being a part of the Psychedelic collective. Psychedelic has, again and again, earned the trust of the ecosystem by investing heavily into creating & delivering on infrastructure products for the IC (like Plug, DAB, CAP, Sonic, etc..).
Creating a naming system is not something proprietary, as we’ve seen there are already multiple on the IC. One of our big differentiators will be the trust the community has in us, not only to deliver but to be a fair and honest controller before we decentralize fully and transition ownership over ICNS to the community.
Lastly, Psychedelic has already set out its intentions to add tokenized governance systems to all of its products and will be a massive help when our time comes to do so as well.
ICNS Roadmap Updates
We’re humbled by the response to our genesis launch.. but we’ve still got a lot of ideas to make ICNS even better. Here’s what our roadmap looks like:
Short Term⚡ ICNS-js, ICNS Shortlink, & Plug Integration
(1) ICNS-js is a javascript library that we will be releasing very shortly to make it easier than ever for applications to interact with the ICNS profiles of their users, as well as the ICNS protocol overall to, for example, surface a name’s metadata and records.
(2) ICNS Shortlink is an application built on top of our open APIs that generates a custom webpage profile for every ICNS address that’s created. You’ll be able to view & share your ICNS profile by going to address.icp.page (replacing ‘address’ with your ICNS address).
(3) Integration with Plug will come very shortly as well. To begin, you’ll be able to send tokens & NFTs to ICNS addresses instead of 50+ character long principal ID.
After this initial update, all principal IDs in Plug that are attached to an ICNS name will be replaced by their human-readable counterpart. ICNS usernames will also show up as NFTs in your wallet’s NFT tab, and you’ll be able to do in-app configurations to set which ICNS username you want to point to your wallet in Plug.
Medium Term 👷 .xyz Replaces .host, Plug Extension Domain Resolving, & ENS Integration
(1) In order to align ourselves further with the crypto community, we’ve acquired icp.xyz and will soon replace .host with .xyz as the gateway between your web3 username and web2 browsers. Instead of accessing your favorite ICP projects from xxxx.icp.host, it’ll be xxxx.icp.xyz ✨
The .xyz top level domain has strong roots in the Ethereum community and has partnerships with ENS (Ethereum’s Name Service). As far as centralized gateways gets, .xyz is the cream of the crop for crypto support.
(2) Resolving ICNS domains through Plug’s extension is a big focus on our roadmap as well. Plug’s extension would effectively intercept any ICNS domain lookup request and would resolve the response directly from the Internet Computer. We consider this the best option as it gets rid of centralized gateways altogether.
We’ve chosen to partner with Plug to do this, but in the spirit of decentralization, we are not planning on making this Plug exclusive. Anyone that wants to create an extension that resolves ICNS domains will be able to do so by building on our open APIs.
(3) ENS integration is also on our roadmap! We just so happened to pick up icp.eth on ENS, and in the future, we will link all ICNS domains to ENS by making them a sub-domain of icp.eth! An initial mirroring that will replicate all records from your .icp name on its ENS counterpart to make them work on that ecosystem!
This integration will be deepened in the future, we don’t see these services as competitors, so we’ll boost their interoperability as much as possible (e.g. natively supporting both extensions across both chains!)
ICNS Q&A ❓
Now, let’s answer some questions. Since genesis, you guys have had a few burning questions regarding ICNS and some of its features… let’s get those suckers answered 💪
Are ICNS names actual domains?
In principle, yes! ICNS domains perform the exact same function that other domains do, they translate a human-readable name into less verbose information. This could be a website, IP address, or even a Principal ID.
However, ICNS is a decentralized naming service built on the Internet Computer which means that for now, the .icp domain is not recognized by modern browsers as a top-level DNS domain (like .com, .ooo, or .xyz) that has the power to resolve websites.
What is the .host / .xyz service?
Until browsers natively integrate resolving of Web3 name providers (ENS, ICNS, HNS, etc…), in order to resolve the content that ICNS domains point to, we’ve made use of an existing TLD: .host.
ICNS owns the icp.host DNS domain (soon to be replaced with icp.xyz) and has configured its subdomains so that if you add .host to your ICNS domain (eg: icns.icp.host), the browser will be able to route to your any underlying resource/content you point it to (for example, a website hosted on the IC!).
Since icp.host & icp.xyz are DNS domains that browsers can nowadays understand, they act as a gateway between your Web3 name, the content it resolves to, and the Web2 browser world! This works in a very similar way to resolving a ENS .eth name using xxxx.eth.link or xxxx.eth.limo. Abackground service built on icp.host handles the resolving that the browser can’t natively do, and directs it to the right content (your xxxx.icp site!).
NOTE: Domain resolution is a feature of ICNS domains, not their whole purpose. Your ICNS domain is meant to be your web3 identity, and can resolve a lot of different info (wallet address, social info, & the location of web content) and a website just happens to be one.
Why use centralized gateways at all?
Unfortunately, unless we’re able to get a browser to add in the ability to fetch directly from ICNS (Brave browser, pls 🙏) when resolving a .icp top-level domain, the only way is to go through existing top-level domains like .host & .xyz, and create subdomains that do the work of fetching and resolving ICNS domain content.
So, as we wait for Brandon Eich’s call back about Brave browser integration, the best we can do to make it super easy to access ICNS domains through any browser is to add a centralized top-level domain.
It’s not perfect, but it’s one of the options we’re including in order to play ball as we build out more decentralized options like resolving domains through Plug (similarly to how the Metamask extension resolves .eth names for you when installed on your browser!).
