Idea: II combined with Name Service / NFT

Right now It’s fairly cumbersome to remember the long II anchor number. Reminds of ICQ days lol.

What if instead I could associate an anchor with a domain-like or email-like NS NFT? e.g. tommy.icp, or mac@tommy.icp? the email-style anchor opens up possibility for a specific II identity for diff. DAO clubs, e.g. tommy@BAYC.eth.

Of course it should be user optional to decide if want exposing the NFT identity to the actual canister. Some DAO clubs may decide to authenticate & only allow e.g. @BAYC.eth II users, or a BAYC jpg holder, to use the service.

Is there any reason not to do this technically? Anyone working on that?


hey @toysrtommy, that’s a great idea!

We have some related items “somewhere” on the roadmap, although they’re not high priority at the moment (the team is really small).

We were talking about allowing “nicknames” that map to anchors but didn’t get very far with the design. One of the issue is the storage space in the II canister. Right now it’s extremely limited and we wouldn’t be able to store mappings between e.g. nicknames and anchors.

One alternative would be to use pseudo-randomly generated “nicknames” (like: “intrigued-whale”) based on the anchor; then we wouldn’t have to store the mapping.

That being said, I think custom nicknames or even NS NFTs are much, much better. I love some of the suggestions you make:

That being said, currently II is explicitly designed to make sure a Dapp cannot figure out the anchor ID of the user authenticating, but only sees a pseudonym; that would need to change.

Now regarding the storage: very soon we’ll be making significant architectural changes to make II scalable and ensure we can add data as we go (roadmap update post coming soon). Also, we’ll soon look into how we can integrate with 3rd party services; in this case, another Dapp could e.g. provide a mapping between a “nickname” and an anchor.

Final note on the “NFT” nickname; I think Identity Labs is trying to work out how to prove ownership of an NFT without disclosing the anchor ID. Maybe this could be extended to prove that the anchor’s nickname belong to some namespace, like @BAYC.eth? @dostro


@toysrtommy I’ll echo @nmattia in saying there’s no technical reason this can’t happen but rather the concern is privacy.

Soon you’ll be able to use your email address, phone number, or .icp domain to send and receive ICP in NFID.


sounds great, these will bring the IC closer to Web2 users. they will gradually use the cool things that can only develop on the IC without knowing that they are in the Web3 world. :heart_eyes:


One alternative would be to use pseudo-randomly generated “nicknames” (like: “intrigued-whale”)

That would kinda defeat the purpose, there must be a way to remember many anchors easily, the way I see it could be be done in 2 ways:

  1. Email like system for names.
  2. A “keyring” identity where you can store all your ancors in the same place.
1 Like