CPS-0001 | Metadata Discoverability and Trust

[ehanoc]

There seems to be multiple proposals and attempts to solve issues around metadata specific to certain contexts. Proposing this as a first CPS in order for us to agree what the general problem actually is and try to steer the process to tackle the root cause of the problem. This is my attempt at describing the problem.

---

(current draft in branch)

[rphair]

among other things, this relates to our currently open CIP's that address identity for individuals (creators / authors) & stake pools:

• CIP-0077? | Verified Stake Pool Identity #361
• CIP-0066 | NFT Identity #294
• CIP-0989? | ISPO KYC_CDD #241

[KtorZ]

Please re-order the sections as per the latest structure 🙏 (and apologies for this, I guess that goes with being one of the first CPS pioneers!):

• Abstract
• Problem
• Use Cases
• Goals
• Open Questions

---

Also, given the numerous proposed solutions; it might help to formulate what part of the problem remains to be solved and what parts have been properly addressed already.

[ehanoc]

Also, given the numerous proposed solutions; it might help to formulate what part of the problem remains to be solved and what parts have been properly addressed already.

Great @KtorZ ; i think here there some attempts in coming out with some solutions (i.e token metadata, off chain storage[cip-26]), for very specific use cases but not to the general problem of discovering, verifying and asserting trust in metadata?

Maybe someone can help me by pointing out current solutions / implementations, that in their opinion, are working well for a specific context. And those can provide lessons to try tackle this in a more generalized way.

CC: @rphair @SebastienGllmt

[KtorZ]

What I meant was that, the current document lists several CIPs as "proposed solutions"; which implies that the listed proposals address either partially or fully the problem. If they are simply related to the problem, but not actual solutions to it, then I'd suggest to move them elsewhere (i.e. in the problem statement itself, if those existing efforts and their shortcomings are worth mentioning).

(note: I haven't reviewed the statement yet, nor any of the linked PR; so I am mostly speculating here. My gut feeling being that this particular CPS is about some dimensions of metadata -- discoverability and trust -- that existing CIPs do not address properly. Hence, they shouldn't be listed as 'proposed solutions' because none of them is about solving the discoverability and trust problem in the metadata landscape -- except maybe CIP-0068 in some sense?)

[Ryun1]

Would the "metadata is up to date" be part of correctness or discoverability? or neither?

[ehanoc]

"Up to date" to a given point in time? In my mind whatever is anchored on chain is "up to date" and if there will be updates; we need mechanisms to discovery / be notified of new versions. Makes sense?

[Ryun1]

Is this a combination of problems and should be split into multiple CPS?

It might make sense to split this problem by metadata subject i.e. stake pools, tokens, scripts, etc. As the problem can be solved quite differently for each of these entities.

Without the historical context for CPSs its hard to know how wide the scope should be.

[fallen-icarus]

I believe the beacon token CIP here addresses pretty much all of your use cases. I have created reference implementations that do similar things.

1. Find scripts used by a dapp - cardano-reference-scripts. Users can trustlessly find and use reference scripts being shared by other users in a fully decentralized and cryptographically guaranteed manner.
2. Discover general information of a dapp - cardano-address-book and cardano-datums. The former shows how you can make it so that only the dapp creators are able to update information using metadata while still being easily found by other users. This behavior is cryptographically guaranteed by the blockchain. The latter shows a similar method but uses datums instead of metadata. IMO datums should be used instead of metadata for public registration because format can be strictly enforced (registration will fail if a required field is missing). I believe this addresses the concern mentioned with CIP-26.
3. Find the different metadata claims associated with a subject - the cardano-address-book program uses beacon tokens for this.
4. Associate some form of identity that can be cryptographically verified - the cardano-address-book program does this. This is accomplished by only allowing that beacon token to be minted by that particular user. This is cryptographically enforced by the blockchain.
5. Offer mechanism to attest for the correctness of a given metadata object that can be fetched by wallets and applications from off-chain sources - using the datums instead of metadata would guarantee correct formatting. As far as truthfulness of the information, by only allowing the user/dapp entity to add information with that beacon token, the risk of this is heavily minimized.
6. Discover datum schemas used by a script in a specific context or dApp use cases - this was actually one of the motivations for the cardano-datums program.
7. A wallet receiving a request to connect to a dApp, it can verify the authenticity of the dApp and the metadata associated with it - again, since beacon minting can only be done by the required entity, the authenticity can be cryptographically guaranteed.

Beacon tokens are extremely generalizable. Do you agree that they address your use cases? Or am I misunderstanding something?

[fallen-icarus]

To further highlight the generalizability of beacon tokens, I used beacon tokens to create cardano-swaps. It is a distributed DEX proof-of-concept where users maintain full delegation control and custody of their assets at all times. Thanks to beacon tokens, no batchers are needed. Instead, users lookup the beacon tokens to find each other (and the relevant information to execute swaps) in a p2p manner.

[rphair]

FYI @ehanoc the fact that a candidate CIP is relevant to this CPS came up in today's CIP Editors' Meeting (cc @KtorZ @Ryun1): #467 (comment)

[rphair]

@Ryun1 @Crypto2099 it seems a shame that CPS-0001 never went anywhere but @ehanoc I have to assume this has been abandoned at least due to personnel changes.

@fallen-icarus in the unlikely event that you want something extra on your plate, you would have my full confidence to advocate & continue this submission: or perhaps just to tag anyone else who might be interested in reopening & completing it.

[Ryun1]

I would like to pick this one back up, when I have time :)