fixed several outdated things across CIP #16

vhulchenko-iohk · 2023-04-18T17:16:01Z

fixed several outdated things across CIP in various sections.

kolesarp1 · 2023-04-19T06:55:24Z

CIP-0072/README.md


 *`type`*: The type of the claim. This is a JSON object that contains the following properties: 
 - *`action`*: The action that the certificate is asserting. It can take the following values: 
  - *`REGISTER`*: The certificate is asserting that the dApp is being registered for the first time. 
  - *`UPDATE`*: The certificate is asserting that the dApp is being updated.
  - *`DE_REGISTER`*: The certificate is asserting that the dApp version is being removed and it is requested that stores no longer show it.
-  - *`DE_REGISTER_ALL`*: The certificate is asserting that all dApp version are being removed and it is requested that stores no longer show it.
+  - *`DE_REGISTER_ALL`*: The certificate is asserting that the DApp's development is stopped, and it is depricated.So, no futher DApp's on-chain updats are expected.


Do we want to change all "dApp" to "DApp" across document? @vhulchenko-iohk

"The certificate is asserting that the dApp's development is stopped, and it is deprecated. So, no further dApp's on-chain update are expected."

@kolesarp1, good comment. Just checked the doc. It seems that we have dApp everywhere. Let's check with the rest of the folks on the CIP-72 call if that's OK to change all "dApp" to "DApp" across the doc.

@matiwinnetou, yep, just inserted this exact line above.

matiwinnetou · 2023-04-19T07:34:52Z

CIP-0072/README.md

@@ -32,25 +32,21 @@ Also, having this formalisation facilitates any actor in the ecosystem to index
 - **metadata claim** - Generically any attempt to map off-chain metadata to an on-chain subject. This specification looks at dApp specific metadata claims.
 - **client** - Any ecosystem participant which follows on-chain data to consume metadata claims (i.e. dApp stores, wallets, auditors, block explorers, etc.).
 - **dApp Store** - A dApp aggregator application which follows on-chain data looking for and verifying dApp metadata claims, serving their users linked dApp metadata.
- **publishers** - Entities which publish metadata claims on-chain, in the case of dApps the publishers are likely the dApp developer(s).
- **auditors** - These are clients which maintain lists of trusted entities and metadata servers, checking metadata claims against these. 


Ah yes good point, why did I overlook this.

matiwinnetou · 2023-04-19T07:35:41Z

CIP-0072/README.md


 ### **Developers / Publishers**
 Developers and publishers of dApps can register their dApps by submitting a transaction on-chain that can be indexed and verified by stores, auditors and other ecosystem actors.

 ### **Stores / Auditors**
 Stores and auditors should be able to follow the chain and find when a new dApp registration is **anchored** on-chain. They should then perform *integrity* and *trust* validations on the dApp's certificate and metadata.

-##### **Targetted Releases**


Why remove this?

@matiwinnetou
Two points:

I was thinking that it might not be possible to do taking into account the current CIP-72 process. t doesn't seem to be a way in the current CIP to mark that this particular release is for a particular consumer (a DApp store, auditor, etc.) - and maybe it is too early to introduce this.

Now, it feels that this part deviates from the current CIP-72 process that aims to let DApp developers set up and maintain a single off-chain JSON (as you can see we unify things and create predefined lists to avoid potential mess) that cable to cater to various consumers (e.g. DApp stores, auditors, other DApps, etc.). So, to keep things simple in the MVP version of the CIP, it feels it is better to move this stuff completely or move it to the bottom of the CIP and convey it as a discussion point to monitor feedback and demand for it.

Depends how you interpret targeted releases, can you provide your interpretation?

matiwinnetou · 2023-04-19T07:35:54Z

CIP-0072/README.md

 #### **Suggested Validations**
- **`integrity`**: The dApp's metadata off-chain should match the metadata **anchored** on-chain.
+- **`integrity`**: The dApp's off-chain metadata should match the metadata **anchored** on-chain.


matiwinnetou · 2023-04-19T07:36:39Z

CIP-0072/README.md

@@ -76,14 +72,14 @@ The on chain dApp registration certificate MUST follow canonical JSON and be ser
 ```

 ### Properties
-*`subject`*: Identifier of the claim subject (dApp). A UTF-8 encoded string. This uniqueness of this property cannot be guaranteed by the protocol and multiple claims for the same subject may exist, therefore it is required to exist some mechanism to assert trust in the *veracity* of this property.
+*`subject`*: Identifier of the claim subject (dApp). A UTF-8 encoded string, max 64 chars. The uniqueness of this property cannot be guaranteed by the protocol and multiple claims for the same subject may exist, therefore it is required to exist some mechanism to assert trust in the *veracity* of this property.


If we put 64 chars (which is ok), then we should also update JSON schema to reflect this.

Yep, just added this line everywhere:

Properties section - subject's description

On-chain JSON Schema

Off-chain JSON Schema

matiwinnetou · 2023-04-19T07:42:15Z

CIP-0072/README.md

@@ -76,14 +72,14 @@ The on chain dApp registration certificate MUST follow canonical JSON and be ser
 ```

 ### Properties
-*`subject`*: Identifier of the claim subject (dApp). A UTF-8 encoded string. This uniqueness of this property cannot be guaranteed by the protocol and multiple claims for the same subject may exist, therefore it is required to exist some mechanism to assert trust in the *veracity* of this property.
+*`subject`*: Identifier of the claim subject (dApp). A UTF-8 encoded string, max 64 chars. The uniqueness of this property cannot be guaranteed by the protocol and multiple claims for the same subject may exist, therefore it is required to exist some mechanism to assert trust in the *veracity* of this property.

 *`type`*: The type of the claim. This is a JSON object that contains the following properties: 
 - *`action`*: The action that the certificate is asserting. It can take the following values: 
  - *`REGISTER`*: The certificate is asserting that the dApp is being registered for the first time. 
  - *`UPDATE`*: The certificate is asserting that the dApp is being updated.
  - *`DE_REGISTER`*: The certificate is asserting that the dApp version is being removed and it is requested that stores no longer show it.


DE_REGISTER_RELEASE
DE_REGISTER_DAPP

Yep, changed to the proposed names everywhere

matiwinnetou · 2023-04-19T07:42:54Z

CIP-0072/README.md

@@ -478,15 +474,11 @@ We believe that CIP-26 is geared towards storing this type of off-chain metadata
 We went back and forth whether we should actually store link (links) to off-chain metadata, eventually we settled on a solution that this is required
 because there could be a situation that a dApp registration may have off-chain metadata stored somewhere but some stores have it, others don't have it. Now it is required that a dApp developer points to at least one store that has off-chain metadata (as a reference metadata).

-### Limited fields dApp Registration (what is mandatory / what is not)


* 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>

removed several outdated things across CIP

0eb5d12

kolesarp1 reviewed Apr 19, 2023

View reviewed changes

matiwinnetou reviewed Apr 19, 2023

View reviewed changes

addressed all comments on initial commit

b79613a

matiwinnetou merged commit 92e5bdc into ehanoc:cip-72_dapp-registration Apr 20, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

fixed several outdated things across CIP #16

fixed several outdated things across CIP #16

vhulchenko-iohk commented Apr 18, 2023

kolesarp1 Apr 19, 2023

matiwinnetou Apr 19, 2023

vhulchenko-iohk Apr 19, 2023

vhulchenko-iohk Apr 19, 2023

matiwinnetou Apr 19, 2023

matiwinnetou Apr 19, 2023

vhulchenko-iohk Apr 19, 2023

matiwinnetou Apr 19, 2023

matiwinnetou Apr 19, 2023

matiwinnetou Apr 19, 2023

vhulchenko-iohk Apr 19, 2023

matiwinnetou Apr 19, 2023

vhulchenko-iohk Apr 19, 2023

matiwinnetou Apr 19, 2023

fixed several outdated things across CIP #16

fixed several outdated things across CIP #16

Conversation

vhulchenko-iohk commented Apr 18, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment