This EIP allows us to not rely on third-party services to query metadata about a smart contract and also verify the smart contract ABI and Source Code that would be provided by the Dapp developer through an on-chain registry to be submitted on IPFS
Really great idea @pedrouid, it is important that this key data is available! Once this kind of metadata is present and commonly used, then new layers will be made possible. Currently, contracts and addresses are in data silos.
A question: would you be open to adopting the JSON-LD format for this?
This approach would enable the format to be more easily defined and validated by present tools. Secondly, it encourages data modeling. And possibly most important of all, JSON-LD is designed to extend and be extended, enabling implementers to easily interconnect / reference other JSON-LD files stored on IPFS.
Also, I wonder if it’s a good idea to duplicate data such as decimals under the ERC20 section of standards. Totally understand why you would need that info, but if you have the contract address, can’t you just ask the contract directly for its ticker and decimals?
Hi everyone!! Thanks for the great responses. It would be awesome to be able to access this type of information without having to depend on API silos.
I am looking into JSON-LD. When I try the examples in the playground (https://json-ld.org/playground/ > recipe) the @context in the example leads me to a dead link for the schema. Is it possible to avoid such a situation by hosting the JSON-LD context as a separate file on IPFS and link to that in @context? If anyone is more familiar with the LD specification it would be great to have some guidance and support drafting up the context document @jpitts@boris.
@tjayrush I agree ERC820/165 is superior for getting contract interface implementations, where implemented. I am assuming superior ways of retrieving which interfaces are implemented or other new ERCs will be preferred over manually submitting data, thus over the course of time superseding parts of the spec.
A key weakness in JSON-LD (and the Semantic Web and Web in general) is that a link to a schema or other critical resource can become broken! This encourages centralization of schema definitions in order to better guarantee continued access (by way of aggregating stakeholders who would raise hell should something like https://schema.org make moves to shut down).
We do need a resource w/ an ENS domain name for Ethereum dapp-related schemas in order to address the uncertainty about broken links to dependencies. I had considered this last year, thankfully now we’re here and can better coordinate
I’ll keep bringing a resource for JSON-LD schemas up as the Data Ring organizes (perhaps eventually that conversation will become a Metadata Ring).
@pedrouid Looks like I’m a little late to the party!
I really like the thought and direction on this! So here are a few thoughts:
(Apologize in advance for formatting )
Is there a need for cataloging/allowing blockchain specific data? Couple use cases:
– When a client requests meta for an address, they may not know which blockchain or network it belongs to, if there was some way to signify it would all the client to respond with a better initial connection for the user. Ex: User is connected to mainnet ethereum, navigates to an address that only exists on rinkeby, which would return rinkeby related meta. The client could then change its connection to rinkeby.
– Second idea: If/when there is better inter-blockchain support, there should be a way to allow linking/extending of meta. This would enable games or other types of clients to quickly service different types of connections at once. Ex: User is connected to mainnet ethereum where all the core transactions and Ether/Tokens are held for their wallet, upon interaction with a sidechain user transmits some type of game-specific token to be accounted for on both chains. Related meta would then need to supplement which sidechain and which token bridge/swap mechanism is possible. I realize this one is a bit farther down the line, however I think the context of extensibility is key to capture early.
–Lastly, I think there could be a new section under “reputation” where blockchain specifics could be linked or described
We chatted about images & image standards (thanks again for that!) Here’s a few ideas where meta could map:
– Under “metadata” looks like a simplified “logo” key exists. I think this is probably a little oversimplified and would get quickly outgrown. Maybe there could be something like “icons” which would allow for other web-spec icons or logos to exist?
– Another Idea: We talked about adding asset definitions within each of the standards, allowing for a standard url schema. This is something I am more specifically thinking about creating a new EIP for, just exploring the data model locally. If all ERC or etc mapped to an “AssetSchema”, it could standardize the way image assets (or really any media) get represented which would simplify implementation and use across wallets & dapps.
Questions about reputation:
– Where do the tags come from? Are they simply user created or is there a standard updatable list? My first reaction was it would be awesome if that could reference something like etherscamdb for instance.
– Reputation in general feels like a larger spec, it could be its own module of sorts, or another linked reference schema.