CIP-0162? | Cardano URIs - Delegate Authority

[MadOrkestra]

This CIP seeks to define the delegate authority for web+cardano URIs with the intention of enabling user-friendly and error-prone DRep delegation by deep-linking within the CIP-13 syntax to bring this missing piece of ecosystem interactions to browser extensions and mobile wallets. The use cases range from One-Click-Buttons on DRep platforms and tools to providing DRep-Ids as QR-Codes for instant delegation at in-person events without the need of using lengthy DRep-Ids or dedicated governance websites.

Rendered View

The UX looks like this:

• Click a button/link on desktop browsers or scan a QR-Code with your mobile device
• The preferred user wallet opens and validates the given DRep-Id
• The user signs and submits a DRep delegation transaction

This CIP is in line with the currently work in progress CIPs CIP-0157 (Enhanced Payments) and CIP-0158 (Deep-Linking for URLs), so wallets can hopefully implement all of these in one go and greatly improve the Cardano user experience on desktop and mobile.

[MadOrkestra]

Just FYI: I already got initial feedback from @francisluz (beginWallet) signaling support for this.

A question to discuss is support for the deprecated #CIP-0105 DRep-Ids. While we have tried hard to phase these out everywhere to be replaced with the updated #CIP-0129 Ids, backwards compatibility might still be needed? From an implementation POV it really doesn't matter that much IMO, because you'd either have to implement feedback about the outdated format or just do the conversion?

Not sure what the "official" CIP-way of doing this is?

[rphair]

thanks @MadOrkestra & ready to usher this one in to sit with the other Cardano URIs - proposals by introducing (Triage) at next week's meeting, where I would hope observing or participating developers will also chew on some of the more complicated URI syntaxes (though this use case & syntax seem invulnerably straightforward): https://hackmd.io/@cip-editors/117

[rphair]

I hope (and will plan at the meeting) to do some brainstorming about whether & how the authority //delegate could be disambiguated from the act of stake pool reference through a URI: which is also a delegation.

CIP-0013's choice of //stake to be usable for asset delegation was in fact primarily as a stake pool reference rather than signifying the verb "to stake" & the act of staking.

When documenting that extension I made the argument (seen in the CIP-0013 Discussion: links) that these links could be used not only for the act of delegating to a stake pool but also to reference stake pools, portfolios, proportions, hypothetical stake distributions between pools, and other reference & analytical purposes.

Likewise this CIP's URLs more generally refer, not to an act of delegation, but to a DRep. After considering every possibliity for how stake pool URIs would be interpreted and used for stake pools (as a "noun" [object] rather than a "verb") — and recognising that DRep references have similar use cases — the logical conclusion would be that this authority should be //drep rather than //delegate (cc @Crypto2099).

[MadOrkestra]

Another lovely case of Can-we-please-stop-calling-two-different-things-the-same-name IMHO lol - but yeah, I can see the point. The question is if there actually is another use case for stake besides delegating, because "staking" as in "send stuff to a smart contract" will be covered by the new payment authority as it is technically a normal transaction?

AFAIK no wallet has implemented stake yet anyways as of now anyways.

[rphair]

Suggested change

	Leveraging existing connections within the ecosystem; we will find willing partners to integrate this new standard and deploy a proof of concept integration.
	Leveraging existing connections within the ecosystem; the author(s) will find willing partners to integrate this proposal and deploy a proof of concept integration.

This will hold place for who "we" would be unless it can be made even more specific.

Note this is not really a "standard" while still Proposed and that we have to remove the word "new" since the proposal will no longer be that way in the future... SOP for all CIPs, not just this one 🤓

[rphair]

(re: @MadOrkestra #1069 (comment)) Not sure what the "official" CIP-way of doing this is?

As we've seen added to the newer URI CIP's in the /version pathname component, the usual best-practice way to would be to add a mandatory URI pathname component before the DRep ID of either /cip105 or /cip129 (or some more concise equivalents). Alternatives like adding these as query variables — or an optional pathname component for the lesser-used, deprecated syntax — have been frowned upon in previous CIP discussions as subject to error & parsing difficulties.

Therefore since it's @Crypto2099 who's maintaining the parser for these I would defer (with the reservations above) to his judgement on the currently best & most future-proof way of handling this in the syntax.

[MadOrkestra]

(re: @MadOrkestra #1069 (comment)) Not sure what the "official" CIP-way of doing this is?

As we've seen added to the newer URI CIP's in the /version pathname component, the usual best-practice way to would be to add a mandatory URI pathname component before the DRep ID of either /cip105 or /cip129 (or some more concise equivalents). Alternatives like adding these as query variables — or an optional pathname component for the lesser-used, deprecated syntax — have been frowned upon in previous CIP discussions as subject to error & parsing difficulties.

Therefore since it's @Crypto2099 who's maintaining the parser for these I would defer (with the reservations above) to his judgement on the currently best & most future-proof way of handling this in the syntax.

If thats the same parser we use at Ekklesia, you can just throw anything at it and it will check if it is a valid 105 or 129 Id and if 105 convert it to CIP129 (which is a neat way to phase out 105), so the /version wouldn't be needed here, but I'll let @Crypto2099 rant about 105 for himself :)

[rphair]

That would be personally fine with me. When I suggested a few years ago for CIP-0013 that pool tickers and hashes (in the same place in the URI string) should be distinguishable by string length, the folks at Emurgo bristled about parsing difficulty. If today the key versions are considered distinguishable by a much smaller difference in byte length — without requiring an unsightly extra term in the URI pathname — then @MadOrkestra @Crypto2099 I'd be happy to hear it. 😎

[rphair]

Following up from #1069 (comment) - to ensure this CIP has the most meaningful title even if uncertainty from use of the term //delegate persists (pending a retitle of this PR to follow the CIP which is needed in any case now):

[rphair]

Suggested change

	Title: Cardano URIs - DRrep Delegation
	Title: Cardano URIs - DRrep Links

As already detailed in #1069 (comment) we face less uncertainty from link users if we call these linked objects what they are rather than trying to anticipate what people should do with them... i.e. there are plenty of things people can and will likely do with these DRep links beyond delegating to that DRep.

[Ryun1]

Suggested change

	Title: Cardano URIs - DRrep Delegation
	Title: Cardano URIs - DRep Links

typo!

[rphair]

FYI @MadOrkestra the CIP meeting # 117 referred to above — where this is on the agenda for Triage — has been postponed 2 weeks (due to Rare Evo).

[MadOrkestra]

Thanks for heads up, everyone is indeed really busy rn with Rare prep.

[rphair]

@MadOrkestra this was confirmed as candidate at today's CIP meeting... please rename the directory to CIP-0162 and update the "Rendered View" link in your OP 🎉

The meeting re-emphasised the utility of this proposal especially in a context of a "business card" that provides a safe channel for delegation in social context without transcription problems or impersonation leading to errors or hijacking.

But by the same token a "business card" refers to the entity rather than any imperative of working together... which suggests a full consideration of the idea I already presented above that the authority here should be //drep (or some noun) rather than //delegate (or other verb).