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]

(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]

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).

[MadOrkestra]

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).

Any objections to this from anyone? I am fine with //drep otherwise.

(apologies for the long delay, I forgot...)

[rphair]

@MadOrkestra your attention is appreciated in any case and I'm happy to hear that our URL object (on principle, a noun) can be referred to by a noun instead of by a verb! 😅 I thought you might see my lightweight response to your comment above but perhaps not... so please feel free to change //delegate to //drep here and then the community & editors will re-review (personally I think that's been the only thing lacking so would provide my own endorsement after that & see if we can then progress towards Last Check).

[MadOrkestra]

Hey @rphair - yeah, on it... I have had a few further discussions about this and I don't think wallets will ever implement the profile/card functionality which probably should be the drep default function to make sense. Then again, with the proposed browse authority in #1058 this isn't needed anyways, because this enables wallets to directly open a DRep-Id from lets say tempo.vote or gov.tools and have the same functionality.

I fully understand why delegate is confusing, but I revisited the other proposed CIP13 advancements linked in #836 which propose pay and browse - so yeah, I think we should discuss all those enhancements together to at least try to have consistency over all the CIP13 advancements?

@Crypto2099 I know you're busy, but maybe you can drop your thoughts on this too real quick.

[MadOrkestra]

The other thing that maybe needs adding: Cardano dropped the ball on DRep-Ids all together and now there is no way for anyone to determine if a given DRep-Id belongs to mainnet or testnet, so maybe this authority also needs a testnet flag, so the wallet knows where to actually look up the given DRep-Id (or at least prompt the user for having their wallet on the wrong network)?

[rphair]

@MadOrkestra for the record, pay and browse can also be nouns 😅 But if I were a DRep, I'd eventually want to send a DRep URL even to parties that I knew wouldn't be delegating to me... site indexes, DRep directories, competing DReps, DRep "collectives" and other political parties... far more than just "cards" in wallets, which should be considered over Cardano's potentially perpetual lifecycle instead of just wallet plans on the hear horizon.

So I would keep campaigning for this point although we don't have enough of a forum here to properly debate the alternatives so I suppose your own preference would be the tiebreaker. Or, alternatively: we could follow the well-known URL length economy and use the shorter term (4 chars for drep vs. 8 for delegate).

maybe this authority also needs a testnet flag

This is a good point to add to the topics to review next (making 2: including the // authority term) and so we should focus on clarifying these before final review & hopefully @Ryun1 @Crypto2099 can feed back about it & invite some wallet/dApp devs to consider the ideas on general principles (not just their own wallet plans).