-
Notifications
You must be signed in to change notification settings - Fork 318
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CIP-0072? | DApp Registration & Discovery #355
CIP-0072? | DApp Registration & Discovery #355
Conversation
|
@ehanoc would love to chat about this. We managed to iterate over domain model for dApps at: https://github.com/Cardano-Fans/crfa-offchain-data-registry, while this is probably richer than what you wanted to achieve there could be some valueable learnings there for this CIP. |
@matiwinnetou Thanks!
But i've set this to draft because i believe it's important to describe the problem first before coming up with the solution. In order with the new guideliens, i've open a draft CPS for this purpose. I think if we nail the problem first in a concise way, we can come up with a (or set of) solutions for it that make sense. |
@ehanoc For sure. Would love to setup meeting with you and talk a bit. I can share experiences and it could be that we at DappsOnCardano we are rather users of this than contributors. I see a problem today on Cardano that protocol XYZ tells me that they have audit from CertiK for V2 and not only V1 and I have to analyze this and trust them. I would like CertiK to publish this on chain. This could be yet another use case but I would happily talk to you if possible about all these things we have been facing. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 Great proposal. I think it's a good step forward for the user experiences and the ecosystem. There is still details to iron out but I like the general concept and the proposed solution.
See my comments and questions below:
…mprovements in schema and release properties
…d recommendation for keeping all past histories of off-chain snapshots.
CIP-0072/README.md
Outdated
"action":{ | ||
"type":"string", | ||
"enum":["REGISTER", "DE_REGISTER"], | ||
"pattern": "^(REGISTER|DE_REGISTER)$", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this is defined as enum, do we additionally need the regex?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
probably not, good point
Co-authored-by: Marcin Mazurek <marcin@mazurek.pro>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Review at last meeting highlights already live & reference implementations, so should be merged as Proposed
to facilitate further adoption. Therefore marking Last Check and we should also get @KtorZ to review and @Ryun1 will also add comments.
I've also been reading this periodically and I find it quite satisfactory today & acknowledge it's also well received by apparently unaffiliated parties and therefore @ehanoc our merging as Proposed
would solve the chicken-egg problem of merging as CIP and evidence of further adoption depending upon each other.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work on this proposal @matiwinnetou, for me this proposal is well written and has a solid technical approach and thus is a good candidate to merge.
I only have a few minor points - see below. 🤠
|
||
on-chain_metadata = { | ||
subject: string, | ||
rootHash: sig_256, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this type a signature and not a hash?
CIP-0072/README.md
Outdated
update the proposal to be in `ACTIVE` state. | ||
|
||
### Acceptance Criteria | ||
- IOG and CF approval |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How is this measured?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
More importantly, this CANNOT be an acceptance criteria. IOG and CF are not authorities when it comes to approving CIPs. Acceptance criteria must reflect actually measurable data points and show "proof of activity / usage".
CIP-0072/README.md
Outdated
|
||
### Acceptance Criteria | ||
- IOG and CF approval | ||
- Community representative approval (Santiago / TxPipe and Marcel / Eternl wallet) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If these people are meant to be implementors of the standard, then we should list them as implementors. And, it goes without saying that they should confirm having such role.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They didn't, I removed them.
is in `PROPOSED` status. After certain period (no longer than 6 months), from time of merging PR in `PROPOSED` status to the main / master branch, we will | ||
update the proposal to be in `ACTIVE` state. | ||
|
||
### Acceptance Criteria |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As a concrete acceptance criteria, I'd suggest to have at least 2-3 non-trivial dApps from different entities registered through this method. That would serve as a good measure of its acceptance.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
CIP-0072/README.md
Outdated
## Path to Active | ||
We will evaluate for a few months if we have not missed any details, collect feedback from dApp developers, stores. We reserve right to make small changes in this time, while the proposal | ||
is in `PROPOSED` status. After certain period (no longer than 6 months), from time of merging PR in `PROPOSED` status to the main / master branch, we will | ||
update the proposal to be in `ACTIVE` state. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This can only happen if the proposal meets its acceptance criteria though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
makes sense, changed
CIP-0072/README.md
Outdated
Authors: | ||
- Bruno Martins <bruno.martins@iohk.io> | ||
- Mateusz Czeladka <mateusz.czeladka@cardanofoundation.org> | ||
Implementors: [] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given that there's an implementation plan, this shouldn't be empty.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
Co-authored-by: Ryan Williams <44342099+Ryun1@users.noreply.github.com>
@ehanoc the
These points are probably addressable within the hour; perhaps you can make it to the meeting and, if they've been fixed before then, perhaps we can merge it. Otherwise I will suggest we label this |
@rphair, I have confirmed @matiwinnetou's attendance for this meeting 😎 |
@matiwinnetou thanks for the discussion in the last hour's CIP editors' meeting, after which we have agreed to leave on the We also noted that this question might be addressed by leaving the list of implementors empty, but also that this could negatively impact adoption of the standard (this is a common difficulty that affects a number of CIPs). If you need more time to work out that detail please let us know. |
@rphair I will work on the last remaining points, they should be ready for sure for next CIP editors meeting. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the prompt update @matiwinnetou 🙏
required by already-merged #355
* Initial draft for dapp registration certificate spec * Init Draft CPS-0001 * Add Use Cases, improve descriptions * Typo * Generalizing CPS, simplifying problems and use cases. Add open questions * Add type key for REGISTER & UPDATE. Define rules for calculting hash of the metadata object tree * typoe fix * mistake folder added in last commit * Suggest metadata transaction labels for dapp registration and certification * Suggest metadata structure, off chain storages up to the operators. Improvements in schema and release properties * Refactor for more compliant header * Removing permissionToAggregate * Section for stores custom required metadata fields * Better descriptive title * Metadata links included in cert. Removing audits and simplify explanation * Update CIP-0072/README.md Co-authored-by: simonjohnthompson <s.j.thompson@kent.ac.uk> * Update CIP-0072/README.md Co-authored-by: simonjohnthompson <s.j.thompson@kent.ac.uk> * Update CIP-0072/README.md Co-authored-by: simonjohnthompson <s.j.thompson@kent.ac.uk> * typos, structure adjustments and small prose adds * Metadata links included in cert. Removing audits. Small refactoring * specify size of hash * Authors update * Delete sample-cip26.md * removing auditId * Add logo to suggested metadata properties * amendments based on comments / experience / feedback. * re-intro website + added regex patterns. * Update CIP-0072/README.md Co-authored-by: Robert Phair <rphair@cosd.com> * example fixes and adjusting to CIP template * added placeholders * added rationale section * fixes in rationale section * more rationale * fixed on-chain signature scope * categories * typo fixes * word wrapping test * cosmetics * cosmetics * Path to Active * more community comments * Fixes according to feedback * CIP version is mandatory, releases is optional, new algo to calculate signature * signature generation: hex vs byte array clarification * formatting fixes * added version description and more decisions rationale * typo fix * Fixed patterns for hex strings, added changed DE-REGISTER to DE_REGISTER and added new DE_REGISTER_ALL, schema version changed from 04 to 2019-07. * fixed several outdated things across CIP (ehanoc#16) * removed several outdated things across CIP * addressed all comments on initial commit * Allow to express longer metadata URLs as an array of strings (ehanoc#17) * latest changes as per last meeting agreements * Update README.md * Update README.md * CDDL * CDDL fix * cosmetics * initial categories update * security_vulnerability field, added comment field in on-chain json and recommendation for keeping all past histories of off-chain snapshots. * Update CIP-0072/README.md Co-authored-by: Marcin Mazurek <marcin@mazurek.pro> * latest comment fixes * Apply suggestions from code review Co-authored-by: Ryan Williams <44342099+Ryun1@users.noreply.github.com> * changes according to the recent comments * correction on Acceptance Criteria --------- Co-authored-by: simonjohnthompson <s.j.thompson@kent.ac.uk> Co-authored-by: Ryan Williams <rwilliams1@firstderivatives.com> Co-authored-by: Mateusz Czeladka <mateusz.czeladka@cardanofoundation.org> Co-authored-by: matiwinnetou <mateusz.szczap@gmail.com> Co-authored-by: Robert Phair <rphair@cosd.com> Co-authored-by: Volodymyr Hulchenko <57362128+vhulchenko-iohk@users.noreply.github.com> Co-authored-by: Marcin Mazurek <marcin@mazurek.pro> Co-authored-by: Matthias Benkort <5680256+KtorZ@users.noreply.github.com> Co-authored-by: Ryan Williams <44342099+Ryun1@users.noreply.github.com>
required by already-merged cardano-foundation#355
* Initial draft for dapp registration certificate spec * Init Draft CPS-0001 * Add Use Cases, improve descriptions * Typo * Generalizing CPS, simplifying problems and use cases. Add open questions * Add type key for REGISTER & UPDATE. Define rules for calculting hash of the metadata object tree * typoe fix * mistake folder added in last commit * Suggest metadata transaction labels for dapp registration and certification * Suggest metadata structure, off chain storages up to the operators. Improvements in schema and release properties * Refactor for more compliant header * Removing permissionToAggregate * Section for stores custom required metadata fields * Better descriptive title * Metadata links included in cert. Removing audits and simplify explanation * Update CIP-0072/README.md Co-authored-by: simonjohnthompson <s.j.thompson@kent.ac.uk> * Update CIP-0072/README.md Co-authored-by: simonjohnthompson <s.j.thompson@kent.ac.uk> * Update CIP-0072/README.md Co-authored-by: simonjohnthompson <s.j.thompson@kent.ac.uk> * typos, structure adjustments and small prose adds * Metadata links included in cert. Removing audits. Small refactoring * specify size of hash * Authors update * Delete sample-cip26.md * removing auditId * Add logo to suggested metadata properties * amendments based on comments / experience / feedback. * re-intro website + added regex patterns. * Update CIP-0072/README.md Co-authored-by: Robert Phair <rphair@cosd.com> * example fixes and adjusting to CIP template * added placeholders * added rationale section * fixes in rationale section * more rationale * fixed on-chain signature scope * categories * typo fixes * word wrapping test * cosmetics * cosmetics * Path to Active * more community comments * Fixes according to feedback * CIP version is mandatory, releases is optional, new algo to calculate signature * signature generation: hex vs byte array clarification * formatting fixes * added version description and more decisions rationale * typo fix * Fixed patterns for hex strings, added changed DE-REGISTER to DE_REGISTER and added new DE_REGISTER_ALL, schema version changed from 04 to 2019-07. * fixed several outdated things across CIP (ehanoc#16) * removed several outdated things across CIP * addressed all comments on initial commit * Allow to express longer metadata URLs as an array of strings (ehanoc#17) * latest changes as per last meeting agreements * Update README.md * Update README.md * CDDL * CDDL fix * cosmetics * initial categories update * security_vulnerability field, added comment field in on-chain json and recommendation for keeping all past histories of off-chain snapshots. * Update CIP-0072/README.md Co-authored-by: Marcin Mazurek <marcin@mazurek.pro> * latest comment fixes * Apply suggestions from code review Co-authored-by: Ryan Williams <44342099+Ryun1@users.noreply.github.com> * changes according to the recent comments * correction on Acceptance Criteria --------- Co-authored-by: simonjohnthompson <s.j.thompson@kent.ac.uk> Co-authored-by: Ryan Williams <rwilliams1@firstderivatives.com> Co-authored-by: Mateusz Czeladka <mateusz.czeladka@cardanofoundation.org> Co-authored-by: matiwinnetou <mateusz.szczap@gmail.com> Co-authored-by: Robert Phair <rphair@cosd.com> Co-authored-by: Volodymyr Hulchenko <57362128+vhulchenko-iohk@users.noreply.github.com> Co-authored-by: Marcin Mazurek <marcin@mazurek.pro> Co-authored-by: Matthias Benkort <5680256+KtorZ@users.noreply.github.com> Co-authored-by: Ryan Williams <44342099+Ryun1@users.noreply.github.com>
required by already-merged cardano-foundation#355
This proposal aims to standardize the process of metadata claims, dApp registration, discovery and verification. and to provide a way for DApp developers to make a set of claims when registering their Dapps and adding a way for other actors to index / crawl and discovery registration of DApps in the eco-system.
It attempts to create a fair standard for actors to discover dapps being registered in the ecosystem and no boundaries to participate and collect information about dapps, authors, scripts, audits. Also by design tries to give options to the different actors of the system:
Validation mechanisms:
(rendered proposal in branch)