Welcome back! Live testnet + mainnet simultaneously is a strong differentiator.
Main concern: is resolution dependent on your API or fully on-chain/decentralized?
Will follow this CIP closely.
Thank you for the kind words and for following the proposal!
To answer your question directly, currently resolution goes through our
API at getmyid.today/api/resolve/, but the data itself is fully on-chain.
The API simply queries Blockfrost to find who currently holds the NFT
under our Policy ID and returns that address. No centralized database,
if our API goes down, anyone can independently resolve handles by querying
Blockfrost directly using our Policy ID. The source of truth is always
Cardano itself.
We will also be resubmitting the CIP with a revised suffix, changing
from .id to .did (Decentralized Identifier) if the namespace is free on
Cardano, which aligns much better with the W3C DID standard and avoids
the existing ADA Handle conflicts raised in the GitHub review.
The observation regarding the lack of namespacing is correct and highlights a broader ecosystem challenge. While currently no handle scheme on Cardano supports formal namespacing, our transition to the .did suffix is an intentional step toward alignment with global W3C Decentralized Identifier standards. We believe this gap justifies a future CPS to establish a formal Root Registry on-chain, ensuring that different naming protocols can coexist and resolve correctly without conflict.
Following the feedback received on the GitHub PR, we have made two
significant decisions:
We are changing our handle suffix from .id to .did (Decentralized
Identifier), aligned with the W3C DID specification. This eliminates
all conflicts with existing ADA Handle .id handles. Our platform
getmyid.today is already being updated to issue .did handles.
We have opened a CPS (Cardano Problem Statement) to document the
broader governance problem before proposing the technical solution.
The CPS documents the absence of an open governance framework for
handle namespaces on Cardano and proposes requirements for a solution
— including an on-chain registry of approved namespace providers.
We believe this is the right approach — fix the root problem first,
then build the technical solution on top of a proper governance
framework. We welcome all feedback from the community.
The CPS for Handle Provider Interoperability has been accepted by the CIP editors as CPS-0032. This is a co-authored standard with Jesse Anderson from the ADA Handle team.
The CIP editors have not accepted CPS-0032: in fact there is no CPS-0032 yet. After our last meeting we declared a candidate CPS-0032 which will only be accepted (“merged” on GitHub) if & when peer review meets all challenges to the problem presentation (the method, in case of a CIP) and/or has no substantial challenges from stakeholders reviewing the pull request above.
For all CPS and CIP pull requests, the ? after the CIP/CPS tag (as with the currently titled CPS-0032? shows this “candidate” status: GitHub > cardano-foundation > CIPs > Pull Requests - which you can see is missing on actual CIP & CPS tags (as with updates).
It’s unfortunately misleading that unmerged CIPs are often named without the ? … though this has been both common & productive for more convenient discussion by social media and working groups (as for the long & widely reviewed CIP-1694 [governance] and CIP-0164 [Leios]).
But this is exactly why we need that ? and to emphasise “candidate” on most proposals: the message above erroneously suggests that CIP editors have verified peer review and accepted it into the repository along with the other CIPs and CPSs. This can be especially damaging for CIPs when readers begin implementation of a candidate before it’s finalised.
I used the word “accepted” incorrectly and I want to set the record straight before it misleads anyone.
CPS-0032 is currently a CANDIDATE — not yet accepted. This means the CIP editors have assigned it a candidate number and it has passed initial review, but it has not yet been merged
into the repository. It will only be officially accepted after peer review is complete and all stakeholder challenges have been addressed.
I apologize for the misleading characterization. The correct status is: CPS-0032? (candidate, under peer review).
The pull request is here for anyone who wants to review and provide feedback:
We especially welcome feedback from wallet developers and naming providers on whether the problem statement accurately reflects real-world challenges. Your input at this stage directly shapes the technical solution that will follow.
