CIP-COSD-MultiPoolStakeURIscheme

[rphair]

This pull request is planned for closure as soon as it is merged with CIPs: PaymentUrls (pull request & discussion) so that a common URI scheme for both payments & stake pools can be considered as a whole and expedited.

Therefore this CIP has been modified to propose only single-pool links (CIP-COSD-SinglePoolStakeURIscheme.md). To view the original proposal for multi-pool links (delegation portfolios), see (CIP-COSD-MultiPoolStakeURIscheme.md). Multi-pool features will again be requested in the merged CIP after it is approved.

For full details see #25 (comment) later in this thread.

[SebastienGllmt]

Probably it makes more sense to adapt https://github.com/Emurgo/EmIPs/blob/master/specs/emip-002.md as a CIP and then submit your proposal as a modification to the CIP instead of making this pool URI scheme its own standalone CIP

[nicarq]

Glad to see a CIP about this! I agree with @SebastienGllmt tho

There are other issues that I think need to be addressed here. Particularly related to mobile, where this wouldn't be applied well. This seems like a specific solution to Chrome (extendable to others) but not a multi-platform solution.

I'm also would like to see what happens when the ratios don't add up to 100%.

It's a really good start, but I think we should work together so we can solve the issue between desktop and mobile at once

[dcoutts]

Are there not limits how how big URIs can be that would be a problem for this format? For each pool in a portfolio you're going to need the pool id, and a floating point number. A pool id in bech32 format is (I think) 57 chars, and lets be generous and assume 5 chars for a float (e.g. "42.03" limited precision), plus a separator char. So that's at least 63 chars per pool. You soon run into huge and unreadable URIs.

[shawnim]

With a practical limit of about 2k chars for URIs that would limit this method to about 30 pools. On Monday, October 5, 2020, 11:39:12 AM PDT, Duncan Coutts <notifications@github.com> wrote: Are there not limits how how big URIs can be that would be a problem for this format? For each pool in a portfolio you're going to need the pool id, and a floating point number. A pool id in bech32 format is (I think) 57 chars, and lets be generous and assume 5 chars for a float (e.g. "42.03" limited precision), plus a separator char. So that's at least 63 chars per pool. You soon run into huge and unreadable URIs. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[rphair]

adapt https://github.com/Emurgo/EmIPs/blob/master/specs/emip-002.md as a CIP and then submit your proposal as a modification to the CIP instead of making this pool URI scheme its own standalone CIP

thanks @SebastienGllmt - I've moved the Prerequities section, adding much more detail, to a development timeline in the Specification section which now includes the EmIP and other prior art. I believe it wil show how the relevant proposals & issues are related as well as establishing order & dependency.

I've stated there that the EmIP is ready to be adapted to a CIP any time— until then, serving immediately as a reference implementation with no requirement to refactor this proposal around it— and also that Daedalus can begin implementing a suitable URI scheme, as proposed long ago, without waiting for anything else to happen first.

I am trying my best to represent the community in this matter according to your feedback from the related Catalyst proposal (URIs for Stake Pools and Portfolios), currently the only reference I know to a development timeline or priorities for multi-pool delegation, let alone our need for of a common language for staking portfolios:

multiple pool delegation is probably at least half a year away if not more so I don't think the multi-pool aspect of this proposal will help anybody anytime soon.

It's extraordinary what a difference it would make for our community, external views of Cardano, and morale if this issue weren't put off indefinitely as such. Regarding stake centralisation, we are still waiting to hear any confirmation by the official developer community of any empathy from the larger Cardano entities towards the smaller ones (edit: while I was writing, the CF posted this which is encouraging in that regard). So far, here and on the Cardano Forum, it's mostly technical nit-picks and it would be nice to see some balance in the discussion between the low-level and high-level issues.

There are other issues that I think need to be addressed here. Particularly related to mobile, where this wouldn't be applied well. This seems like a specific solution to Chrome (extendable to others) but not a multi-platform solution.

@nicarq as a user and designer I have been following tel:, magnet:, mailto: and more specialised protocol links for many years and I've never seen a case where certain browsers categorically blocked them except in the early days of tel:. These integration problems aren't absolute showstoppers anyway, since in the worst case the links could be copy & pasted into Daedalus, as people occasionally have to do for other protocol links. That means development can still begin on single pool URIs immediately, then covered better, by more platforms, as time goes on.

I would like to suggest the low levels of implementation detail be kept outside the scope of this proposal: which is about establishing a standard, not outlining every aspect of development. This CIP already links to the Github issues about relevant implementations on Yoroi and Daedalus and to enumerate them all here would be an extraordinary duplication of effort. As long as it remains within my power & responsibility, I'll happily update this CIP every time development on any of those issues suggests that the standards herein need to be adapted for real world conditions.

I'm also would like to see what happens when the ratios don't add up to 100%.

@nicarq nothing in this CIP says they need to. Your pool choices could indicate a 2 to 1 ratio by specifying 2 and 1: they're not percentages. If you only specified 2 for the heavier pool & left the other one without a proportion, it would assume 1 for the other. Please refer back to the relevant section (Specification > Interpretation of proportion) which explains this in detail. The numbers don't have to add up to anything in particular, nor do any or all of them need to be there. If any parameter lists create impossible portfolios or leave any degree of freedom, your case isn't one of them.

However I did need to add another case in which any of the pool names are invalid, or any of the proportions are non-numeric. These should generate an error or warning condition, with the exact response left to the wallet or exchange and its own semantics. I've updated the proposal accordingly.

A pool id in bech32 format is (I think) 57 chars, and lets be generous and assume 5 chars for a float (e.g. "42.03" limited precision), plus a separator char. So that's at least 63 chars per pool.

@dcoutts @shawnim again I think these critiques have missed an element of the proposal:

For security the hex pool ID should be usable here instead of each stake pool name, although with SMASH currently slated for Daedalus integration this may not be necessary to avoid ambiguity.

Therefore there is no requirement to use the long stake pool name, nor will users want to when hand-crafting portfolio links. As we've seen in videos and colloquial references (like the other issues above, with no text announcements, updates or timetable yet available), SMASH is on the way into Daedalus. Since the issue of stake pool name uniqueness came up long before multi-pool delegation this year, I would assume they will be available in the same order, and therefore by Step 4 of the CIP (support of multi-pool delegation) the pool ticker will serve as a secure, canonical and unique reference to a stake pool.

In the meantime, since Step 3 of the CIP (single pool delegation links) may be implemented as soon as URI support is ready, a single pool reference can be made using the Pool ID with the 63 characters for that pool being far less than the URI character limit.

With a practical limit of about 2k chars for URIs that would limit this method to about 30 pools.

If we assume 5 characters for the pool name, 3 significant figures for an integer ratio, and 2 characters for punctuation, the URI standard would therefore support a coarsely weighted portfolio with 200 pools. Portfolios requiring more scope and precision would have to use the JSON standard, suggested by @disassembler and currently described in the Alternative Designs section.

[SebastienGllmt]

Sorry for the delay, but I've posted what we have currently in Yoroi in this CIP here: #30

[rphair]

No worries @SebastienGllmt about any delay... it's a brilliant and timely step forward. My last commit is relative to the submission of your new CIP, with an updated timeline plus some items on your new proposal that are also relevant to this one.

One thing I can see that is missing from here is a "formal grammar" relevant either to the stake pools or the composite URI scheme of payments + stake pools. I don't want to say how many years it's been since I've written out a formal grammar (only in my academic life, not my engineering one). So when the time comes I hope someone else will express all this as a formal grammar in whatever way is most useful to whomever is implementing that grammar. 😎

[rphair]

added Security Considerations section, in the mood of the related CIP, based on the same general requirements as for payment links (user confirmation & phish proofing).

I began writing an ABNF grammar and then decided to officially defer this to an extension of the ABNF grammar in the related CIP, because it makes more sense to add an authority term (//stake) there than to duplicate the structure of the payment URIs here.

[rphair]

In phone conference about 12 days ago, @SebastienGllmt and I agreed to delay the multi-pool portion of this proposal until a stripped-down CIP, only proposing single pools & with simplified wording, could be merged with #30 and then approved.

Any multi-pool features, along with any separate rationale to support them, will be proposed in a later pull request to add these to the merged CIP. Once Sebastien merges the two proposals I will close this pull request.

The active proposal has been moved to CIP-COSD-SinglePoolStakeURIscheme.md since I have to leave the file CIP-COSD-MultiPoolStakeURIscheme.md as an external source for a Catalyst proposal which will be voted on in about 1 month (it's not possible to update the links in those proposals anymore). I'm less concerned with success in that vote than I am with a bad link causing disorientation, or bad feelings about the CIP process, with the voters.

For those external visitors, we also agreed to put any explanatory comments about the substantial changes to this CIP, along with any links, as an edit to the first item in this discussion (#25 (comment)) where visitors from Catalyst and the Cardano Forum may still be landing long after the multi-pool implementation is being considered elsewhere. I'll update the links there as necessary when the discussion continues in the new pull request.

We agreed on changes 1 and 2 in our call already, and the rest of the changes are for consistency & brevity:

1. Simplifed Motivation
2. Remove multi-pool notation from Specification
3. Removed Development Plan, which will now be implicit when the multi-pool extensions are added & discussed in the merged CIP.
4. Security considerations are nearly identical to the Payments CIP so have been removed.
5. Most of Rationale, being relevant to "delegation portfolios", has been removed (just left most essential benefits for small pool survival & large pool efficiency as decentralisation progresses).
6. Alternate Designs eliminated (integration issues are already covered in the Payments CIP, and JSON support is only needed for multi-pool delegation list, e.g. increased precision or number of pools).
7. Reference implementation is eleminated because the Payments CIP is a direct evolution of that implementation.
8. Removed Ideascale link from CIP metadata, since discussion there has not produced any real consideration of this proposal.

One thing missing from the multi-pool proposal was a discussion of how protocol support for ratio staking would affect the implementation as well as the development timeline. Even if not possible to maintain staking ratios I believe the user community would still appreciate a multi-pool link to set up a one-time multi-pool stake assignment, even though varying rewards would cause the original stake ratios to "drift" ... although I also agree with Sebastien's feeling that explaining the difference to the user could be "messy". I will mention this issue prominently in the second pull request & hope we can debate it thoroughly there.

[rphair]

Just now was referred to discussion from CIP meeting 1 week ago where there was discussion of the stake pool reference format (base58 vs. Bech32): https://github.com/cardano-foundation/CIPs/blob/master/BiweeklyMeetings/12-08-2020.md#cardano-uri-scheme - It sounds like the owner of #30 will be making that change when doing the merge, but if this draft needs a corresponding edit before then please let me know.

Also there was a comment about "not hearing from" the submitter of this PR, i.e. me (unless I'm reading it wrong) although the request above on 16 November to merge the proposals, based on @SebastienGllmt's suggestion, was pretty explicit and I've just been waiting to hear the status from the CIP administrators. If any action has been required on my part, nobody has told me & I haven't heard from anyone about this in a month.

[rphair]

Since #30 has now been merged without any of the material above, even after stripping it down to single pool links as requested by @SebastienGllmt as a precondition for the merging, it appears this proposal has now been bureaucratically cut off from the development process.

An individual decision, or one reached in conclave, to do this might have been acceptable if any rationale were given here. But after a solid endorsement of stake pool links via forums, social networking and Catalyst, all the Cardano community has now is an observation that this proposal has been run into the ground without any accountability. This is especially a shame because of the Cardano Foundation & IOG press releases this week quoting the CIP process as part of Cardano's democratic basis.

The original reason for push-back about this CIP was that URI schemes were fraught with difficulty... so maybe someone will explain how that's a problem for a community generated CIP but not for one coming from the official Cardano agencies. Of course there are other hairy development issues like wallet support for stake pool links, but then the question would be: why wasn't //stake even included in the merged proposal's ABNF grammar?

Since the merged CIP now shows the URI support will be implemented without stake pool links being a part of it, the real development issue may be that stake pool links have been considered uninteresting by the official developers alone: again, in conclave with no reasons given here. If the intention were to do nothing with this proposal, then why @SebastienGllmt did you suggest that I rewrite it for single pools so you could merge our proposals?

I am hoping there are somehow still plans for a merger after the merged CIP's approval... but even if so there would still be the grievance that no such commitment was ever made, nor any information given about such plans or any timeline. It might not be obvious from the ivory tower view but the Cardano community is watching this issue, and there are so many small stake pools depending upon it: a goal consistent with IOG's massive small pool re-delegation planned for this week.

https://cosd.com/cardano

[v-almonacid]

@rphair the CIP that was just merged is still in draft state. It can still be modified or in the worst case, a separate CIP can be submitted to include this work. I don't think anybody is against this, probably the issue here is that the editors don't have enough bandwidth right now to handle everything that's going on in a timely manner. I'm sure there was no deliberate decision to exclude this work in anyway.

[rphair]

thanks @v-almonacid - all those confirmations are mainly what we have been looking for 😎

[rphair]

This material has now been included with #61 relative to the newly created CIP-0013. Anyone following the stake pool link proposal should now follow via #61.