CIP-0196? | Handle Provider Registry & Resolver - #1229
Conversation
rphair
left a comment
rphair
left a comment
There was a problem hiding this comment.
@kingslavcho (cc @papag00se) I have a feeling we will be able to get through any presentation & format issues in the next week so I feel safe marking this for Triage at the next meeting: https://hackmd.io/@cip-editors/139
I do hope ASAP in the meantime we can come up with a CIP title that is not the same as the CPS title... which would falsely suggest we are only interested in hearing one solution for each problem (and which I think we went to some lengths to avoid confinement as such in the CPS): we can discuss & confirm a title in the point below.
To fix the common format problems, please follow along with the CIP validator running in the GitHub workflow at the bottom of the PR page:
- There are some basic differences between this document and the standard CIP format & template; the validator (cc @Ryun1) should identify them clearly.
- If in doubt on any validator point just post and we'll work on it together.
- I'll review the proposal as usual for pre-meeting
Triageafter we can see that it passes validation.
|
@kingslavcho (cc @papag00se) please also consider my strong suggestion to remove all numbering from the headings in your outlined specification. I post on this topic in this repo repeatedly: but rather than link to those earlier explanations please TL;DR consider that deep links to your spec section headings — which will break if & when they're renumbered, which will happen — are much more important than being able to refer to sections conversationally by their number. This is an operational document and a work in progress: not a thesis. |
rphair
added
Category: Tools
rphair
changed the title
Co-authored-by: Robert Phair <rphair@cosd.com>
|
Thank you @rphair for the triage confirmation and the detailed feedback. I will fix all validation errors immediately:
Regarding the title, I like your suggestion. A title focused on the registry and resolver is more precise and leaves room for alternative solutions as you pointed out. Happy to go with whatever the editors and @papag00se agree on. @papag00se what is your preference on the title? |
There was a problem hiding this comment.
@kingslavcho it looks like all of my own issues have been fixed in the last commit 29e22d8 and so I think the main question for Triage next week — assuming it's confirmed as a candidate, which I would support — will be how to address this for review to:
- others working in the "Handle space" specifically (cc @papag00se for ideas on this in the meantime);
- wallet & any other tooling providers expected to implement the new specification.
|
Thank you @rphair — glad the main issues are resolved. I will address the remaining points:
@papag00se do you have experience with JSON schema validation from the ADA Handle side? And do you have suggestions on who in the handle space we should be reaching out to for review? |
|
@rphair @Ryun1 regarding registry validation, I have added registry.schema.json to the CIP folder defining the exact structure each provider entry must follow including:
For automated validation on registry.json PRs, I would propose a GitHub Actions workflow similar to CIP-0010's approach that runs ajv (a JSON schema validator) against registry.schema.json on every PR that touches registry.json. The workflow would look something like this if possible (i am not sure but AI proposed this might work)
This would give CIP editors automatic validation so they only need to review content and criteria, not format. @papag00se @Ryun1 would you be willing to help set up this workflow or advise on the best approach given the existing CIPs repo tooling? |
rphair
left a comment
rphair
left a comment
There was a problem hiding this comment.
Continued from #1229 (comment):
Co-authored-by: Robert Phair <rphair@cosd.com>
|
Thank you for putting together the initial technical proposal. I support the underlying goal and remain committed to co-authoring a useful interoperability standard. Before reviewing the individual sections, I want to clarify the scope of my support and the principles I am applying to this review. My co-authorship of CPS-0032 represents support for the problem statement: wallets and dApps need safer provider-aware resolution, explicit provider context, collision handling, abuse resistance, and backward compatibility. It should not be interpreted as blanket approval of every implementation proposed in this initial CIP draft. My support during the CPS discussion was specifically for moving away from namespace governance and toward provider-neutral interoperability. I do not think the resulting technical standard should inadvertently recreate governance or market allocation through registry ordering, automatic wallet enablement, or default resolution behavior. I think the CIP should preserve these distinctions:
I will place some comments in-line in the files area. |
|
@papag00se thank you for the detailed review. Let me respond to each point directly. Point 1 - Discovery is not trust I partially disagree here. The entire purpose of this CIP is to reduce friction for wallet integration. If wallets can still arbitrarily ignore compliant registry entries, we have not solved the problem CPS-0032 documented. The standard should define that wallets implementing this CIP MUST support resolution for all active registry entries that meet the defined criteria. Wallets that choose not to implement the standard at all are free to do so - but a wallet that claims CIP compliance must resolve all compliant providers equally. Otherwise this CIP just creates a prettier version of the existing situation where wallet teams decide who gets integration based on private relationships. Point 2 - Registration is not endorsement Agreed completely. The registry is neutral. Inclusion means technical compliance, nothing more. Point 3 - Merge order is not resolution priority I disagree and want to be direct about why. CPS-0032 identified that wallets currently default to whichever provider they have a private relationship with. That is the problem. My proposed solution replaces a private opaque default with a public transparent one. You are right that merge timing does not represent quality or legitimacy. But some default must exist when multiple providers resolve the same visible handle. The question is not WHETHER there is a default - it is WHO DECIDES the default. Right now wallet teams decide privately. I am proposing the community decides publicly through the CIP registration process. If you have a better mechanism for determining the default when collision exists, I am genuinely open to hearing it. But removing default resolution entirely means wallets either always ask the user (which is poor UX for the common case) or fall back to private relationships (which is the problem we started with). Point 4 - Interoperability does not replace due diligence I respectfully disagree. If a provider has a working live platform, a publicly documented Policy ID with real minted assets on-chain, a functioning resolver API returning the standard format, and has passed CIP editor review - what specific technical risk justifies a wallet refusing to resolve their handles? Handle resolution is simple: query an API, get an address, show it to the user. The user signs the transaction. Nothing about this requires the level of trust you would extend to a wallet infrastructure partner. If the resolved address is wrong, the user sees it on the confirmation screen before sending. The same risk exists with ADA Handle today. Wallets retaining discretion to exclude compliant providers means this CIP cannot achieve its stated goal of giving new providers a fair path to integration based on technical merit. That is the core problem I am trying to solve. Point 5 - Existing users must not regress Fully agreed. Nothing in this CIP touches existing handles or existing integrations. ADA Handle users are completely unaffected. I would add that ALL providers in the registry should eventually be listed, including ADA Handle so their users benefit from the standard as well. I would actively encourage ADA Handle to submit a registry entry. Point 6 - Standard must support multiple architectures The current registry format already accommodates this. The If there are specific fields or constraints in the current draft that would prevent ADA Handle or another provider from registering without changing their architecture, please point them out specifically so i can have a look at them and find a proper solution. The bottom line is this: a standard that leaves wallet integration to private discretion after technical compliance is demonstrated is not a standard, it is a suggestion. I want to build something that actually solves the problem. |
|
@kingslavcho - I think we are still talking past each other on two foundational distinctions:
Those distinctions need to be explicit in the CIP. Registry inclusion cannot require wallet trustYou ask:
A provider can satisfy every technical requirement in this proposal and still be a provider that a wallet has valid reasons not to trust or interact with.
Technical conformance does not resolve those concerns. I don't believe there is a CIP today that requires dApps to put their reputation on the line or forfeit their own judgement by forcing support of "compliant" applications. A common standard does not require one ownership architectureThe current on-chain resolution section defines one specific method:
That is a valid resolution method. It is also substantially the ADA Handle model. To be explicit: this method is favorable to ADA Handle’s existing architecture. I still do not think it should become the only compliant architecture. As a co-author, I want the standard to remain neutral even where a narrower standard could benefit ADA Handle. Other valid architectures may use:
The purpose of an interoperability standard should be to define how wallets understand and verify these architectures, not to require every architecture to become the same architecture. ADA Handles own Virtual SubHandles (which are supported by all the major wallets on Cardano) deviate from the "resolve an NFT where it resides" mechanism. |
|
@papag00se I want to engage with these points directly and honestly because I think we have a genuine philosophical disagreement on some of them, not just a technical one. On bad actors and wallet discretion: You raise the concern that technically compliant providers could be bad actors. But consider: on a public blockchain, ANYONE can mint a token today. Nothing stops a bad actor from minting handles right now under any policy ID. The resolution standard does not create this risk - it exists already and independently of this CIP. More importantly: how does a wallet know who is a bad actor BEFORE it happens? You cannot. A provider that is legitimate today can turn malicious tomorrow. A provider that looks suspicious today might be completely legitimate. This uncertainty exists for every provider including ADA Handle, it is not a property unique to new entrants. The real question is: who should make the judgment call? Your answer is wallet teams based on their own discretion and relationships. My answer is the community through a transparent public process with defined technical criteria. Wallet teams retaining private discretion to refuse compliant providers IS centralization. It means whoever has the best relationships with Eternl and Lace wins - regardless of technical quality or community support. That is literally the problem CPS-0032 documented and the reason I started this process. I do not think there is a CIP today that forces wallets to support all compliant applications, you are right about that. But I would argue that is a gap in the ecosystem, not a feature. A blockchain ecosystem that claims to be decentralized should have open, transparent, criteria-based processes for infrastructure integration, not private gatekeeping by wallet teams. On resolution architectures: You are right that the current on-chain resolution section describes one specific method and I will broaden it. But I want to clarify my actual position: The CIP should define what providers MUST document about their resolution method, not prescribe which method they Regarding the specific architectures you listed - CIP-67/68, Plutus contract, delegated subhandles etc - all of these can comply with this CIP by documenting their resolution method in the registry entry. The CIP does not require every provider to use NFT holder resolution. It requires every provider to DOCUMENT their resolution method so wallets can implement it. If ADA Handle's Virtual SubHandles use a different resolution model, document it in the registry entry. That is exactly what the On the core disagreement - default resolution: I maintain that some default must exist when multiple providers resolve the same visible handle string. The current situation, wallet teams decide privately is not neutral. It advantages incumbents with relationships. Registration order in a public CIP process is more transparent and accessible than private relationships. I accept that registration order does not confer trust, endorsement, or legitimacy. It is purely a display ordering default and users can always override it. If you have a specific alternative mechanism for determining display order when collision exists, I am genuinely open to hearing it. But "let wallets decide privately" is not a neutral answer, it is the status quo that CPS-0032 identified as the problem. |
|
@kingslavcho - I believe we are trying to push the CIP into a direction that a CIP cannot fulfill in the first place. The bottom line is, there is no mechanism to enforce compliance. But I will address your points first:
This proves my point more than disproves it. Your plan would force a wallet to accept a bad actor. The "ANYONE" you mention above is auto-accepted as a funds router as long as they comply with this CIP. Even if they are a bad actor.
Again, this proves my point more than disproves it. Under your plan, a wallet does not have the choice to drop the newly bad actor - they must resolve them anyway since you are denying wallet discretion.
"the community" is an unclear entity. Who exactly makes that decision? The best I can tell, your plan leaves it to the CIP editors - making the CIP a form of governance - which by CIP-0001 definition, it cannot be.
Decentralization doesn't mean take away individual discretion. That is what decentralization fights against. Individuals (and the apps they run) should not be forced by a central entity to "do a thing". I'd argue that your plan to force wallets to resolve whoever is in the registry is a stronger step towards centralization than allowing them their own discretion. Several wallets independently choosing different provider sets is decentralized pluralism. One registry determining which providers every conforming wallet must query is a substantially more centralized trust model.
Thank you.
Forcing compliance is not neutrality. There is no mechanism of enforcementMost of our argument side steps the reality and becomes moot because there is no entity that can police any of this anyway. If a wallet uses the registry to discover handle providers but decides not to implement them all - who do you petition? The CIP process has no mechanism to force implementation. Which is the crux of the point. CIPs can standardize interoperable behavior. They cannot confer an enforceable right to integration or compel independent wallets to trust a provider. |
|
@papag00se I want to address the bad actor argument directly because I think it has a fundamental flaw. How does a wallet know who is a bad actor BEFORE they act badly? The answer is: they cannot. You cannot identify a bad actor from a technical submission. You can only identify them AFTER something goes wrong. And by that point the damage is already done -regardless of whether the CIP exists or not. This means the "bad actor" argument is not actually an argument against this CIP. It is an argument that exists independently of this CIP. Bad actors can and do operate on Cardano today without any registry or standard. The registry does not make this worse — it makes bad actors MORE visible by requiring them to publicly document their Policy ID, resolver endpoint, website, and security contact. A bad actor operating outside the registry is LESS visible than one inside it. On wallet discretion to exclude providers: I accept that wallets must retain discretion to exclude providers for genuine safety reasons. I propose the following compromise: Wallets implementing this CIP SHOULD resolve all active registry entries meeting the technical criteria. Wallets MAY exclude a provider but MUST publicly document the reason for exclusion. Valid documented reasons include confirmed security incidents, confirmed fraud, or regulatory requirements in the wallet's jurisdiction. What wallets MUST NOT do is exclude providers based on undisclosed private criteria or commercial relationships - because that is indistinguishable from the status quo that CPS-0032 documented as the problem. If a wallet excludes a provider and refuses to document why - that wallet is not compliant with this CIP. Users can see that and choose a different wallet. That is the enforcement mechanism. Not a legal body. Not the CIP editors. The market. You say several wallets independently choosing different provider sets is decentralized pluralism. I say it is fragmentation that punishes users. A user who mints $slavcho.did and then discovers it only resolves in two out of five wallets because three wallet teams had undisclosed reasons to exclude their provider - that user was misled. They bought something that does not work everywhere. That is not pluralism. That is a broken ecosystem. On enforcement: You are right that no entity can force compliance. But that is true of EVERY CIP. CIP-30 cannot be enforced either. Wallets implement it because users demand it. The same will apply here. The CIP defines expected behavior. Wallets that deviate from expected behavior without public justification will face user scrutiny. That is sufficient and it is more accountability than the current situation provides. I will update the CIP with the compromise language above. But I want to be clear: a standard that allows wallets to exclude compliant providers for undisclosed private reasons is not a standard. It is a suggestion that protects incumbents. I will not accept that framing as the final position of this CIP. |
Co-authored-by: Ryan <ryan.williams@intersectmbo.org>
There was a problem hiding this comment.
At the CIP meeting today we had both parties in the above debate (@kingslavcho @papag00se) present and were able to air both points of view before a cross section of the developer community.
A short summary of broad consensus would be that this CIP itself needs to make it clear — beyond the general Cardano principle that "decentralisation is better" and worth pursuing no matter what the cost — that the likely heavy burden placed on wallet providers will be worth the expected benefits to handle subscribers.
So far, a reading of the proposal by editors and reviewers doesn't convey that impression. I have to apologise again for oversimplification due to space considerations, but the main motivation conveyed so far is the principle of "fairness" with an impression that the CIP is about establishing that: regardless of the cost.
Drawing the line in the middle (neither accepting nor rejecting this) the editors chose to refrain from declaring this a candidate until it's clear the solution here provides its own incentives.
We may someday (soon, or much later) declare that "fairness" is enough of an incentive: if so, this would be established in further review & then perhaps the CIP could encompass those arguments.
In any case this CIP will have to remain Unconfirmed until either:
- establishing that the total benefit of this method would indeed be worth the cost; or
- agreeing to merge this as a potential solution despite not having a community consensus about the benefits of doing this (perhaps with an appropriate disclaimer).
Points raised at the meeting
@colll78 made the argument that could be brutally summarised as "If we have a commercial provider that does everything, then we don't have a problem that needs to be solved."
@perturbing and others made the counter-argument (also oversimplified) that "If we have an expensive solution that provides the 'fairness' the current system lacks, it's a valid CIP even if no rational person feels compelled to implement it."
We observed that our assessments of this CIP (and likely any counter-CIP) have the same quality as governance discussions, and so @kenerik suggested bringing this up with the Civics committee.
I supported the latter idea — and, when the time is right, involving governance advocates in this discussion (cc @thenic95) — since expectations of "fairness" in the Cardano community are likely a regular topic of Civics & other governance circles.
- i.e. Rather than make our own assumptions, reviewers should become better informed about relevant community expectations of "fairness" in general & particularly in the handle space.
@colll78's point above was based on an assessment that implementation of a handle resolver mechanism as described here would be nightmarishly expensive and difficult: measured out to the endpoints of wallet implementations. I don't disagree with this statement, but in the interest of a complete discussion invited him to please spell out the details of that assessment here: even if it reads like a worst-case scenario.
@papag00se commented in the chat suggesting (to me at least) that we might also have a CIP opening up an ADA Handle standard: effectively a "competing" CIP (if not compatible with this one) and a separate solution to CPS-0032.
- It might also be that two such distinct CIPs in this space could both be implemented: but only time & cooperation would be able to tell about that.
I can imagine that an open standardisation of ADA Handle would be cleaner and less error-prone than a resolving mechanism to practically level the playing field. Providing a truly open participation in ADA Handle should well be able to maintain interoperability & keep costs to a minimum: and hopefully in a way that provides the "fairness" to new participants which motivated both this CIP and the parent CPS.
rphair
removed
the
State: Triage
|
@rphair thank you for putting this on the meeting agenda and for the encouraging assessment of the namespace characterisation. Regarding @colll78's concern about excessive difficulty and cost, I want to address this directly before the meeting so editors and reviewers have the technical detail they need. The implementation of this CIP in a wallet reduces to:
The only additional complexity compared to the current ADA Handle integration is steps 1 and 2 - loading a registry file and running string matching. Both are trivial engineering tasks. A competent wallet developer could implement the full standard in a day or two. I say this not as speculation but from direct experience, I am involved in wallet development so i know it is not that hard to implement.. I will attend next week's meeting and i hope i will have also technical document and an active implementation of a json http call and show how it can be implemented. I do not have much time but i will try to have it Looking forward to the meeting. |
|
@rphair @colll78 I have built a live reference implementation to demonstrate that the complexity concern can be addressed concretely. The demo is live at: It implements the complete CIP flow:
The algorithm trace is visible in real time so anyone can verify exactly what the implementation does at each step. The complete resolver logic is ~60 lines of JavaScript shown directly on the page. I tested against real preprod handles minted on getmyid.today. Type any .did handle and it resolves live. This should answer @colll78's concern about implementation cost, the full implementation fits in a lunch break for any competent wallet developer. |
|
|
||
| When multiple registered providers support the same visible | ||
| namespace format, wallets SHOULD default to the provider with | ||
| the lowest serial number for that format while always providing |
There was a problem hiding this comment.
I feel that ordering should just be at a wallet's discretion
Im not sure the benefit of prescribing this
There was a problem hiding this comment.
if we let the wallets choose the ordering someone who already has the connections or is a friend with the wallet provider will always be ordered first (as the default)
Anyway the word SHOULD does not mandate the wallet provider to order according the lowest serial number but it is a recommendation.
For exp me as a small provider that does not have the connections will always be listed second after ada handle if we use the same handle.
Co-authored-by: Ryan <dev.ryan.williams@gmail.com>
| registry entry documentation | ||
|
|
||
| Providers using architectures not listed here MUST | ||
| document their resolution method sufficiently for wallet |
There was a problem hiding this comment.
perhaps these other on-chain options should be documented within later versions of this CIP?
There was a problem hiding this comment.
yeah i agree on this one
| "preprod": "112233445566778899001122334455667788990011223344556677889900" | ||
| }, | ||
| "resolver": { | ||
| "api": "https://example-a.com/api/resolve/", |
There was a problem hiding this comment.
suggestion based on @colll78 in today's CIP editors call
api field is removed as resolver option for wallets, instead the on-chain resolution should be prioritised, with api offered as optional for non-critical cases.
There was a problem hiding this comment.
i agree on this. the website can be hacked, dns poisoned and than with the api call ada can be stolen. Thanks for noting this! but as @colll78 said about the rpc poisoning that is much of a bigger problem if the resolver is on chain queried. i would say i have a solution but i think it will be beyond the scope of this CIP
rphair
left a comment
rphair
left a comment
There was a problem hiding this comment.
Thanks @kingslavcho for bringing this to community review at the CIP meeting today. Our goal there was first to update the community about the presence of two potential means of "opening" the Cardano handle namespace: including this one.
- The editors also appreciated in advance of the meeting your quick provisioning of a proof-of-concept utility as linked above.
Our main reason for not confirming this was serious concern that the presence of an API as an option in the resolver protocol would allow "poisoning" or injection unless we had a system in which everybody could be trusted... it seems a single malicious resolving entity (or someone hacking their web site / DNS address) would be able to commandeer the whole resolution process.
As @Ryun1 summarised in #1229 (comment), wherever payments are concerned there has to be an entirely on-chain resolution of destination addresses. In @colll78's elaboration of the problem we noted that APIs are acceptable when information-gathering... but not for financial asset transfer (even the simple case of hijacking a DNS address could lead to massive redirection of funds).
Please take your time to adjust your solution accordingly and we will try to review the particulars online; we'll attempt to confirm this again when we have an entirely on-chain approach that looks promising.
|
@rphair @Ryun1 @colll78 the demo has been updated to on-chain only resolution: So in this way the provider is never contacted and the resolution is made now with koios directly: GET preprod.koios.rest/api/v1/asset_addresses The demo works on preprod and in fact the nft holder address is the resolved address where the nft resides. And as i stated the implementation is 50 line code and i have also shown the code on the page where i made the working resolution. Thank you again @colll78 for deeply evaluating the solution from a cyber security perspective! I am also an engineer for cyber security but sometimes you can not think of everything! But i came up of something that concerns me. The dns poisoning of the web page now is gone with the rpc resolution but what is going to happen if rpc poisoning happens.. i mean that is not a problem just for the nft resolution into an address but for the whole ecosystem. i do not think this in the scope of this CIP but think of it for a while. If blockfrost or koios rpc is poisoned you have a really big problem. everything that goes through that rpc can be stolen, redirected and believe me many cardano apps use one rpc especially blockfrost. I have a solution for that to use multiple quorum rpc providers but that option is not that cheap. Also some providers can use their full nodes or light nodes via mithril for state proofs to resolve the nft owner address and implement it alongside blockfrost or koios. Not to drag things out I have also updated the CIP to make on-chain resolution the mandatory method for transaction address population, own node option documented alongside third party RPC, api resolution not to be used for financial transactions, alternative on chain methods removed from this version - noted as future CIP versions, i rewrote the security section and updated the schema. |
There was a problem hiding this comment.
@kingslavcho after your last comment and reading the latest specification, I no longer see any off-chain API components to the handle resolution or API assistance in choice of a provider.
- This should not be taken as confirmation because I personally don't have enough wallet implementation experience to know when a piece of missing information might someday suggest or require an API similar to the one that was just removed.
- In any case review by wallet implementors is going to be important in settling these questions, and also to ensure that the specification has no ambiguity from their point of view (I can also see that there is flexibility in their own display of resolver choices, but this flexibility appears documented clearly).
@perturbing @Ryun1 - therefore, although it was just on the agenda last week, unless someone can point out a problem that requires substantial re-working of this CIP, we have to give the author another chance to make their case for CIP candidacy and for others to claim that critical faults aren't fixed yet — so I've put it on the agenda again: https://hackmd.io/@cip-editors/141
@kingslavcho (this may be a new issue) I can also see that URI payment links have been scoped into this CIP — with a proposed URI syntax (something that requires a CIP itself) — without my noticing or it coming up in the meeting yet.
- "Payment links" (and most Cardano URIs) are a substantial effort in Cardano wallet standardisation that is still inconclusive and so it would be improper for this CIP to address it, let alone imply that payment URIs are a solved problem: we can follow this in threaded discussion below.
@colll78 @papag00se in light of your prior concerns about any & all of the content here please post any remaining objections after the last reorganisation. It will likely save us time if any substantial problems can be pointed out this week & if necessary we can postpone the meeting review until tentative agreement (or at least "no contest") is reached here on GitHub.
| Any provider may submit a pull request to add themselves to the | ||
| registry provided they meet the minimum criteria defined in | ||
| section 4 of this CIP. Entries are assigned a serial number by | ||
| CIP editors in order of pull request merge date. Serial numbers | ||
| are sequential integers starting from 1 and incrementing by 1 | ||
| for each new entry. |
There was a problem hiding this comment.
To avoid an implication that CIP editors are establishing a priority — even if only assigning a sequential number during the PR review process — I think it will make for a better decentralised process if the array index (which guarantees ordering) were used rather than this explicitly assigned discrete serial). The documented process would then require that new provider entries are added in a CIP repository pull request at the end of the existing array.
Given any community or provider objections that could be presented if & when such "priorities" were implemented (even cosmetically, only affecting presentation order), I wouldn't want anyone to believe their business presence has been, or could be, adversely affected by writing an arbitrary value into the CIP repository (or benefited by re-using a lower number, etc.).
I would like to cover any such perceptions in the review process because even if array index were used instead of serial number, there still might be such concerns about adding the array entries out of order: not that it would happen, but that it might happen.
I don't think this is a big issue especially since the CIP text itself makes it clear this ordering is only used "cosmetically" in displaying lists. I would just like to confirm with other CIP editors (who would share any stigma) and with all other reviewers that this would not be seen as an opportunity to gain undue influence. cc @perturbing @Ryun1
| ### Payment URI Integration | ||
|
|
||
| Payment URIs that include handle resolution SHOULD use the | ||
| following parameter format to specify provider context | ||
| explicitly: | ||
|
|
||
| ``` | ||
| cardano:{address}?handle={handle}&handle-provider={provider-name} | ||
| ``` | ||
|
|
||
| Example: | ||
| ``` | ||
| cardano:addr1qx...?handle=john.smith.did&handle-provider=GetMyID | ||
| ``` |
There was a problem hiding this comment.
@kingslavcho unfortunately we have nothing like this on Cardano (yet) and the suggestion of a payment link scheme is not as easy as you imply: we have been working for years on trying to define & confirm adoption for these, to no avail.
Contributors to Cardano's URI scheme CIPs (cc @Crypto2099 @MadOrkestra) especially in a proposed general solution for payment links have not been able to get confirmation from wallet providers that any support for a standard format has been implemented, or even will be.
- There was a suggestion from @AlexDochioiu (VESPR) that they had something under way, but the last news we ever got was that it was postponed indefinitely: CIP-0013: Current state of integration and further advancements #836 (comment)
Relying on any form of "payment links" would be dubious at this point because its CIP candidate hasn't even been merged, and is currently abandoned:
I would suggest, at minimum, removing any suggestion of Payment URIs from this CIP since the basic syntax about how to specify ada, tokens, and addresses themselves (let alone handles) hasn't been agreed upon yet.
- If & when there is a general way to specify a handle resolver then I supposed it could be added to a/the CIP on payment links: but we would never be able to agree upon that now.
Note also that our "protocol" for these URIs would be web+cardano: because cardano: itself is not registered (see CIP-0013 > Choice of URI scheme name) (cc @realdecimalist).
Maybe standardisation of "handles" by any means (cc @papag00se) would finally provide the impetus to standardise payment links. FYI we have an issue (also stalled due to abandonment) for community pressure on wallet providers to more uniformly support Cardano URIs; you can also advocate for this issue & maybe exert some influence with the wallet devs over it:
|
@rphair, thank you for inviting remaining objections after the latest revision. @kingslavcho, I appreciate the changes. Removing provider APIs from financial resolution, recognizing wallet discretion, and clarifying my withdrawal as co-author are meaningful improvements. Several substantive issues remain, and at this point I feel like I am parroting the same points I have made previously. As I believe the intention of this CIP is to become more of an authority than a registry, I cannot keep making these suggestions in vain and will not anymore after this post. Registry inclusion still triggers wallet behaviorThe proposal says registry inclusion is not endorsement, but still requires wallets to:
That contradicts wallet discretion. Registry inclusion should establish technical discoverability only. Not dictate wallet inclusion. The registry is still treated as an authorityThe proposal calls the registry authoritative and prohibits unregistered Policy IDs from being resolved under the standard. The registry should be authoritative only for the claims inside its own entries. It should not define every valid handle system on Cardano or prevent wallets from supporting providers through another standard, direct integration, or local configuration. The resolver remains NFT-specificThe schema currently supports only That is not a general handle-provider standard. Either:
A free-text method name is not enough; each profile needs deterministic lookup, verification, failure rules, and test vectors. Namespace matching remains incompleteAn input such as: could match a prefix provider, suffix provider, and bare provider. The proposal does not fully define matching precedence or transformation for each candidate. Bare providers also should not automatically receive lower priority. Prefix, suffix, and bare are syntax choices—not quality rankings. Registry order should have no market semanticsSerial number or array position should not determine default selection or presentation priority.
Payment URI syntax should be removedI agree with @rphair that Cardano payment URI standardization is a separate unresolved issue. This CIP can require explicit provider context without inventing a new URI format here. Registry admission, verification, and removal remain undefinedI also do not understand who actually governs this registry. The proposal says any provider may apply if it meets the technical criteria, and that CIP editors review submissions for compliance. It then relies on providers to mark themselves deprecated or inactive. But it does not define:
These are not minor administrative details. If registry entries affect wallet resolution behavior, then admission and removal decisions become part of the security model. There are two coherent approaches:
The current proposal appears to give the registry authoritative consequences without defining the governance required to exercise that authority safely. My preference remains the first model:
|
|
@rphair @papag00se @Ryun1 changes committed:
On serial number display ordering, I am keeping the SHOULD language. Removing it entirely means wallets default to whatever their existing commercial relationships dictate, which is the problem CPS-0032 documented. SHOULD means |
There was a problem hiding this comment.
thanks again @kingslavcho for the update; it seems we have enough updated material that a review at the next CIP meeting would be progressive: so I'm leaving it on Review for https://hackmd.io/@cip-editors/141.
@Ryun1 @perturbing & reviewers: I think the headings from @papag00se in his final #1229 (comment) would serve well as a checklist for editor / reviewer consensus in either declaring this a CIP candidate or declaring that any unresolved issues should still block this CIP's candidacy.
- Personally I agree with enough of the points in that comment that they would serve us better than an attempt by a CIP editor to draft an entirely new list.
- Even if they have been "fixed" by recent commits they should be confirmed in open review.
- Hopefully we will have enough time to bring up these points one by one, to get a view from the community about whether they consider each particular challenge to be as serious as presumed and/or perhaps worth some effort in persisting even with known imperfections.
I still think it's a good plan to wait until this can be confirmed a CIP candidate — i.e. with any emphatic reservations addressed — before explicitly tagging any wallet reps to review this proposal.
Co-authored-by: Robert Phair <rphair@cosd.com>
|
@rphair thank you for keeping this on the meeting agenda and for the structured approach of using @papag00se's checklist as the review framework. I think that is fair and I welcome it. I have renamed Registry Governance to Registry Process as suggested in your inline comment. I will attend the meeting prepared to address each point on the checklist directly and concisely. For any points that the community considers still unresolved I am committed to making further adjustments rather than defending the current text for its own sake. Looking forward to the discussion. |
rphair
changed the title
There was a problem hiding this comment.
All those with a declared interest in standardisation of Handle resolution were present at the CIP meeting today, where this was confirmed as a candidate with the observations & resolutions below.
- @kingslavcho please rename the containing directory to
CIP-0196and update the "rendered latest proposal" link in your OP. 🎉
Any concern the CIP editors may have had about undue influence appears settled by the paragraph added here, in the (recently renamed) "Governance" section: 72c80d8
It was also confirmed at the meeting that one of the most serious reservations from opposition review — that registry ordering would be applied to wallet behaviour — was also alleviated: with reviewers accepting my summary that this ordering is only a default in the list (providing a "conditioning" for otherwise unsortable data) but not mandating a "default" in the wallet itself.
Assuming this condition is generally understood & implemented, there were only 3 more reservations mentioned by @papag00se that we agreed are accepted to the point where wallet implementations can now fairly review this proposal:
1 - The CIP language is heavily geared toward NFT & policies vs. other means of resolving addresses... a better solution would invite "agnosticism" in addition to the policy-specific language: since some resolvers might not use tokens or policies at all for this (e.g. an asset-imitating data structure like #1200 as I mentioned).
2 - There will be some requirement to "police" the registry beyond what we have seen so far with other CIP registries. I pointed out that these solutions must always be adaptive: for instance the CIP-0010 registry isn't considered insecure just because anyone can post disruptive metadata to a project's designated label. It's understood that wallets will likewise have to choose their own measures to screen any disruptive elements in this registry.
- @kingslavcho please commit to observing any CIP implementations to see if any common countermeasures emerge: since these should also be standardised in this CIP if possible.
3 - Collision avoidance: still a concern, though this also would have been noted at the outset of any treatment of this problem. We noted for example that 1) very few ADA Handles end in .did but also that both users and wallets would find their own ways of working their way around this... and this CIP in any case leaves each wallet free to take its own approach about how the collision would be presented and resolved in its UI.
Now as planned we have to turn this over to the wallet developers to see what they can offer to confirm or dispute the proposed improvement: which will be far more important than CIP editors' opinions from this point onward. I am hoping some wallet representatives (@AlexDochioiu @francisluz @MarcelKlammer @zuzunker & please tag others) will agree with me that:
- some standardisation eventually needs to happen in the "Handles" field, and
- whatever wallet(s) address this issue, either though this CIP or any other solution to CPS-0032, might broaden their user base accordingly.
rphair
added
State: Confirmed
|
@rphair thank you for the detailed meeting summary and for confirming CIP-0196 as a candidate. On Point 1 NFT/policy agnosticism: The CIP already accommodates this through the onchain_method field which is defined as extensible. The policy_asset_holder method is the first defined method, not the only possible one. Future methods for Plutus contract registries, datum-based systems, or asset-imitating data structures like Token-Owned Addresses can be added as the CIP evolves without breaking existing implementations. On Point 2 Registry policing: The current defenses are:
I commit to monitoring wallet implementations as they emerge and documenting any common countermeasures in the CIP. If wallets converge on common approaches to screening - blocklists, verification badges, trust scores - these can be proposed as additions to the Registry Process section. On Point 3 Collision handling demo: I have updated the reference implementation at getmyid.today/cip_demo_collision.html to demonstrate a live collision scenario with two real Policy IDs both having slavcho.did minted on preprod testnet. The collision picker UI is now demonstrable in practice rather than theory. To wallet developers, the demo shows exactly what a wallet implementing CIP-0196 would need to build. The complete implementation including collision handling is approximately 60 lines of JavaScript. I welcome your technical feedback on whether the specification is clear enough to implement and whether anything needs adjustment from a wallet perspective. |
|
@kingslavcho (cc @papag00se for any similar work), perhaps relevant to the problem at hand & taking some of the heavy lifting (expected for wallets) out of the overall resolution framework: |
4 participants
This CIP provides the technical solution to the problems
documented in CPS-0032 (Handle Provider Interoperability).
It defines:
the same visible handle string
and policy ID verification
Solves: CPS-0032 (discussion)
(early discussion)
Note: @papag00se participated as co-author during the CPS-0032 phase and early CIP review. He has since withdrawn as co-author due to philosophical differences on the trust model. His contributions to the discussion are acknowledged and preserved in the comment history. A competing proposal from ADA Handle is expected and will be referenced in this CIP's Discussions field when submitted.
(directory with rendered latest proposal)