search

fixes-world / token-list

A permissionless on-chain fungible token list registration platform on Flow Blockchain
https://token-list.fixes.world/
Apache License 2.0
0 stars 1 forks source link

Parallels with a generalized contract metadata standard? #15

Open bartolomej opened 1 month ago

bartolomej commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

@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:

btspoony commented 1 month ago

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.