CIP-0162? | Cardano URIs - DRep Links

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

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

[MadOrkestra]

@rphair @Ryun1 updated authority to drep and changed the title of this PR - renaming the branch unfortunately closes this PR, not sure if we want that?

otherwise this should be good to go as is - I see the only remaining issue, mainnet vs. preprod ids (with no way of determining for the wallet) as non-critical, as the wallet picks the network anyways. A dedicated flag would only make sense for testing and the worst thing that can happen is that the wallet doesn't find the DRep because it is on the wrong network...

[rphair]

@MadOrkestra well done on moving this along ⭐ and I'm glad you figured out that the PR can be reopened after automatic closure from the branch being renamed. I'm not sure that's always been true of GitHub... I know we've had to restart CIP & Dev Portal PR's from scratch because of that "feature" 😬 so I'm glad we're still on track now.

This is set to go on the books with the document title Cardano URIs - DRep Links which I think is better than using the term "authority" as recently renamed in the PR, because of one important consideration that MAY be important:

• authority (though not insisted to be such on the URI Wikipedia article linked from CIP-0013), is assumed by some human agents (and consequently by some platforms) to be a functional "authority" like a name service... and not the string constant that has seemed reasonable to me, @Crypto2099, and other long time advocates for Cardano URIs.
• It could be that some platforms will therefore require something more generally recognised here: with potential problems like the simpler URI strings had when implementing #1058 on mobile devices.
• Therefore I think we should be cautious about using the term "authority" in official titles until we get some really comprehensive guidance about what to call the term in this position: especially when it's a literal term (like a switch value) rather than a "service" to be passed the arguments which follow... though it could be argued that's what we are already doing, and I'd be content to leave it at that.

In any case I think this has been practically ready to go for a while & I'll approve it as soon as we can attend to

• the usual standard of CIP ID's being a CIP- followed by a 4-digit number (like a broken record I must repeat — since there is no other way to persuade people to follow this convention — that CIP numbers either fixed IDs like CIP-0162 (search engine & text searchable) or noun phrases like CIP 162;
• other general formatting issues.

[MadOrkestra]

Hey @rphair, thanks for the layout updates, all committed. Title has been updated to Cardano URIs - DRep Links

[perturbing]

Very nice! Hope this work makes the distribution more flatter 🙏

[Ryun1]

looks good!

thank you for the contribution!