Parallels with a generalized contract metadata standard?

[bartolomej]

Hey, I like this solution for defining token contract metadata!

But it makes me wonder if there should also be a more general solution for specifying any contract metadata, which could include things like description, image, Github URL, website URL, etc...

I realized this would be needed when I saw a cool contract on Twitter: https://twitter.com/0xBartek/status/1742276379977056307. But I couldn't get any more info about that contract, verify it's trustworthy, or get involved with the development because there was no "backlink" from the contract to the author or a GitHub page.

Luckily in this case I knew who the author was as I originally saw that on Twiter, but this is a special case scenario. I imagine in the future, Flow developers will browse contracts either on the blockchain explorer or a package manager-like tool (such as https://contractbrowser.com) and see a contract they wanna use in their project or get involved with. How would they verify it's trustworthy (i.e. has been reviewed or has a trustworthy Github repo/author), contact the author, or learn more about the project (e.g. their website, Github page or Twitter)?

To solve that, I think it we could define a FLIX-like standard, but for contracts. There was also a related discussion in Discord around this some time ago: https://discord.com/channels/613813861610684416/1191864918232801322/1191864922657783858

I think this project could be a good starting point for the standardized & generalized solution if you'd be interested in that. We can also team up and try to propose/build such solution together!

Let me know any thoughts you have around that!

[btspoony]

In fact, Contract Metadata is not limited to FT and NFT, because FT and NFT just implement the contract interface ViewResolver by default, and ViewResolver can provide any view data.
https://github.com/onflow/flow-nft/blob/master/contracts/ViewResolver.cdc

The Tokenlist is mainly for solving the listing problem of FT, and ViewResolver for parsing contract-level metadata is a part of it. In the future, it will also need to find a way to manage the ERC20 metadata for EVM on Flow.

But currently, it only focuses on FT.

[bartolomej]

@btspoony Hmm, you are right. Although I doubt Cadence devs are actively implementing ViewResolver interface on their (non-FT / non-NFT) contracts. I wonder if we could make this approach more standard, so that more developers would use it to define metadata for any contract on Flow.

Maybe this is just a matter of adding better documentation around that? Or maybe we could incentivize that by having a system (like https://contractbrowser.com) that automatically indexes and prioritizes (e.g. in the UI - by featuring them in the search results or in the dashboard) contracts that implement ViewResolver and have metadata defined - this would in a way be similar as defining metadata HTML tags for better SEO.

Do you have any thoughts on how we could approach this problem and do you agree this is something worth solving? I personally think this would be a fairly important problem to solve, as it would provide better DX for both devs and users:

• devs could get better insights for a contract (links to docs, Github, support, etc...)
• users could see a more human-friendly representation of the contract they are interacting with (e.g. we could show title/image/description next to the contract name in wallets or something like that). FLIX already solves that for transactions/scripts, but there is still no way to expose project details to the users.

[btspoony]

Yeah, I agree.
ViewResolver can be something like ERC-165
I think this may need to be resolved through better standard documentation for commonly-used Flow Cadence standards.