support on-chain metadata as strong instead of erroring

[remnynt]

Some smart contracts use base64 encoded JSON metadata to protect against external dependencies.

We should support NFT projects that aim to provide value through immutable on-chain art and NFTs.

Using the vibes.art contract, located at: 0x6c7C97CaFf156473F6C9836522AE6e1d6448Abe7

And looking up token 1, the result is now:

[vercel[bot]]

This pull request is being automatically deployed with Vercel (learn more).
To see the status of your deployment, click below or on the icon next to each commit.

🔍 Inspect: https://vercel.com/theweaver19/checkmynft/6L6iyfqsuPAt2fCBgP3YvMA3nrJr
✅ Preview: Failed

[remnynt]

This fixes the issue I posted earlier today: https://github.com/theweaver19/checkmynft/issues/13

[niccolopetti]

Hi @remnynt I know it's an old PR but I was thinking of making another PR where #17 and #14 could be merged together to have something more complete, about this PR I'm not sure if cases like vibes.art should be classified as Strong, because even though metadata are stored onchain, in this case a part of it is still stored in a centralized way:

if we take a look at the metadata for id 1 we have:

{"name": "vibe #1", "description": "vibes is a generative art collection, randomly created and stored on chain. each token is an interactive html page that allows you to render your vibe at any size. vibes make their color palette available on chain, so feel free to carry your colors with you on your adventures.", "image": "https://vibes.art/vibes/jpg/1.jpg", "attributes": [{ "trait_type": "element", "value": "light" }, { "trait_type": "palette", "value": "sylvan" }, { "trait_type": "colors", "value": "5" }, { "trait_type": "style", "value": "smooth" }, { "trait_type": "gravity", "value": "low" }, { "trait_type": "grain", "value": "medium" }, { "trait_type": "display", "value": "mirroredUpsideDown" }]}

and so we can see how the image field is still stored in a centralized way on https://vibes.art/vibes/jpg/1.jpg . I think there should be a distinction between a fully decentralized solution and a partially decentralized one.

[remnynt]

hi @niccolopetti - thank you so much for the response!

it's a challenging problem to automate solving for on-chain-ness, since there are so many creators working around the current implementations of centralized marketplaces.

i've recently been following https://www.0xchain.art/

their solution has been a sort of curation of projects. this is not ideal since it's not automated, but i do appreciate the lens of what constitutes a decentralized ERC-721 project.

using vibes as an example:

the vibes output is on-chain HTML, combining a blockhash captured at time of mint with a rendering script (written in raw JavaScript, no dependencies) and stored in a constant within the contract (SSTORE).

in other words, the artwork is a generative computer program that outputs art "jpegs" at any size. since that program is stored 100% on Ethereum, and can be retrieved via tokenScript and run in any web browser to reproduce visual representations of itself, it is both decentralized and resilient to decay or loss.

if someone produces outputs from the program, and caches them somewhere else on the internet, that does not make the on-chain artwork less decentralized.

this approach is common amongst developers seeking to create with HTML / JS on-chain, since marketplaces like OpenSea do not support direct from on-chain HTML (though i've been told it's on their roadmap). the only solution for now to offer the optimal UX is to cache outputs off-chain, but we do include on-chain toggles for when marketplaces better support direct from on-chain HTML.

another example, one of my personal favorites, is Terraforms by Mathcastles. they also cache their on-chain outputs on their private web servers for the time being, and point to them from the contract tokenURI, but what they've done on-chain is truly remarkable, and has no vector or risk for centralization in my review.

with regards to the PR, i appreciate your time in reading it along with my thoughts here - please feel free to close or merge; it's my hope that the our interaction is useful in some small way. cheers!

[niccolopetti]

Hi @remnynt, thank you so much for your response! I didn't know Terraforms AND 0xchain.art and was fascinated by the examples of onchain art they provide!

I admit I didn't read carefully through the code of vibes.art but just focused more on what was returned by the tokenURI. Focusing only on that I think checkmynft should treat that cases like that (onchain metadata with links to offchain resources on centralized servers) as a special case (currently ending up in a false negative for vibes.art, but if we want to treat NFTs as a blackbox I can't think of a way to handle cases like vibes.art unless a new EIP is proposed, which might not be a bad idea though).

If we prefer to accept false positives over false negatives then also the current implementation is fine. I recognize that given current limitations of various marketplaces the solution you found is probably the best and is surely decentralized and is ready to be fully decentralized without touching offchain servers once there will be support from 3rd parties.

Thank you again for the response which brought me to discover useful resources, and with regards to the PR I am just a contributor like you not a mantainer so I have no power to merge or close the PR, I merged it on my fork https://github.com/niccolopetti/checkmynft/pull/1#issue-1276189290 though because I needed it together with support for other evm chains, and through vercel I now have that hosted without needing to set up a server for it through https://github.com/theweaver19/checkmynft/pull/17#issuecomment-1146865578 If it can be useful to others they can use the result of both PRs through that until they eventually get merged by the mantainer.