diff --git a/LSPs/LSP-21-Metadata-Discovery.md b/LSPs/LSP-21-Metadata-Discovery.md new file mode 100644 index 00000000..09536853 --- /dev/null +++ b/LSPs/LSP-21-Metadata-Discovery.md @@ -0,0 +1,123 @@ +--- +lip: 21 +title: Metadata Discovery +author: Jean Cavallera, Samuel Videau, Hugo Masclet, Callum Grindle +discussions-to: shorturl.at/fnwKS +status: Draft +type: LSP +created: 2023-03-17 +requires: ERC725Y, LSP2 +--- + + + +## Simple Summary + +This standard defines the **zero data key** `0x0000000000000000000000000000000000000000000000000000000000000000` as an entry point for an ERC725Y smart to make its metadata publicly discoverable and retrievable. + + +## Abstract + +This standard addresses the issue of making the different schemas used by an ERC725Y contract discoverable for users or applications that interact with the contract for the first time. This is useful for applications that have no prior knowledge of the different JSON schemas used for the metadata, and that do not know where this schema can be obtained off-chain. + +## Motivation + +The LSP2 standard provides a schema that enables to read and interpret the metadata of an ERC725Y smart contract in a human friendly. This is also useful for tools to automate encoding and decoding of standard entries in the storage of a ERC725Y smart contract. + +### Current Problem + +Despite the benefits that LSP2 provides, a problem around metadata remains: + +> _how does someone that does not know the set of ERC725Y JSON schemas used by a smart contract can read the data from the contract storage in the first place?_ + +With no prior knowledge of the schemas, the contract metadata cannot be fetched as the schema helps to construct the `bytes32` data key, so that the contract can be queried to fetch data from it. + +### Existing Solutions + +Currently, the JSON schemas can be obtained through various ways, including public/private Github repositories, documentation websites, README, packages or Gist. There is no standard "rules" or recommendations on where and how these schemas should be shared, which leads to a need for a "LSP2 JSON sharing" model, a way to store the link of the JSON Metadat where the schemas can be retrieved from. + +The only way to be able to read all the data of an ERC725Y contract without prior knowledge of it is to be aware of all the schemas available. In the previous "link sharing model", users and participants are aware of the schemas through third party services, where the schemas are hosted and published. To accomplish this without a trusted party, the schemas must be publicly discoverable, and we need a system for participants to agree on a single method to retrieve these schemas and the metadata. + +One approach can be to store the external URL inside the smart contract on-chain. + +A common solution is to introduce a state variable inside the smart contract that can be publicly queried. However, using this method creates several limitations and inconsistencies: + +1. different smart contracts implementations can use different variable names or getter functions +2. different smart contracts implementations can store the Metadata Schema URL at different slots in the storage. + +This lead to a non-standard way to retrieve this important information, as there is no "standard rule" for retrieving these schemas. + +We need a way for users and tools: +- to know **how to retrieve** the JSON Schemas of the publicly available metadata. +- to know **how to remember** how the schemas can be retrieved. + +### Proposed Solution + +For our purpose, we use a single unique and easy to remember `bytes32` data key: the **zero data key**: `0x0000000000000000000000000000000000000000000000000000000000000000`. + +The advantage of the **zero data key** over other data keys is that it is unique and easy to remember, while the hash of the data key requires to remember the hash of the data that was hashed to obtain the `bytes32` data key. + +## Specification + + +The following schema defines the **zero data key** to make schemas and metadata of an ERC725Y smart contract publicly discoverable. + +```json +{ + "name": "LSP21MetadataDiscovery", + "key": "0x0000000000000000000000000000000000000000000000000000000000000000", + "keyType": "Singleton", + "valueType": "string", + "valueContent": "" +} +``` + +The data stored under the **zero data key** can be one of the following two options: +- **on-chain**: a `JSON` file as utf8 encoded string. +- **off-chain**: a `JSONURL` linking to + +_Requirements_ + +Whether the Schemas are stored on or off-chains, the JSON data MUST adhere to the following requirements: +- MUST be an array of Metadata JSON schemas that comply with the [LSP2 JSON Schema object format](./LSP-2-ERC725YJSONSchema.md#specification). + +### When the Schemas are stored on-chain + +- _What are the requirements_ +- _Put an example here_ + + +### When the Schemas are stored off-chain + +- _What are the additional requirements_ +- _Put an example here_ + + +## Rationale + +The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.--> + +The link to the schema can point to either a decentralised storage networks like IPFS or centralised servers like private Google Drive, according to the preference of the user. + +So when a user, tool or an other smart contract want to read and interact with the ERC725Y Metadata of a contract that it does not know, it can just fetch that JSON Schema from the zero data key to discover the metadata publicly available and then extract the data from the store. + +Making the metadata publicly discoverable through the **zero data key** + +- if you interact with an unknown ERC725Y, you’ll still be able to fetch data +- if a project get abandoned or whatever, the ERC725Yjson will still be there, and will not be lost + +The **zero data key** also enable custom data keys (_e.g: `CollectionDescription`, `CollectionImage`_) that are custom to a specific user (e.g: a Universal Profile) to be publicly discoverable. + +Some objections that the metadata key raise are that through this method, any metadata can now be more publicly visible and accessible. This can be a debate as users or smart contracts might not necessarily want to make all there metadata publicly known and discoverable. Some might not necessarily want anyone to be able to look up certain metadata. For instance, a user might want to attach some specific data to his Universal Profile but keep it hidden from the publicly, so that only the Universal Profile owner (the actual user) know how to access it because he knows the data key. Therefore, some users might want not include the schema of metadata they want to keep secret inside the JSON linked to the **zero data key**. + +## Backwards Compatibility + + +## Test Cases + + +## Implementation + + +## Copyright +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).