Closed punk3700 closed 1 year ago
practically speaking, punching holes in the sandbox is something we'll have to do very carefully to not open the door to things like XSS.
philosophically speaking, I think one of the things that people like about inscriptions is that all the data is on-chain and there isn't a view-time dependency on external servers. If you download an inscription in 100 years (and have the right rendering lib), it'll still look how it is today. Having external dependencies on third party CDNs breaks that -- if that CDN goes away or changes the URL, your inscription is no longer viewable.
If you're going to take a dependency on a third-party hosting service, I think a better route to take would be to just embed a link to off-chain content (as most ERC721-style NFTs do today). It would be MUCH more efficient use of blockspace and the main tradeoff (content hosted offchain) is something you're already signing up for.
that makes sense. what if we inscribe these popular libs? and then reference these libs from the art inscription?
re-usable too. other people can also reference these "on-chain" libs for their work.
I think that's a great idea and probably the way to go. Check out https://github.com/casey/ord/issues/1082. I think that's the intent there.
There's also an issue https://github.com/casey/ord/issues/801 for off-chain content. I think for what you want to do, the former is what we'll want
do you know when #1082 will be ready?
also.. p5.js lib is 900K. is it possible to create an inscription lib this big?
Contributions welcome! :-)
You could inscribe a library that large, but you wouldn't want to. I suspect that people will either write new libs for inscriptions, or cull existing libs down to the bits that are most useful in inscriptions.
i think the benefit of inscribing a popular lib like p5.js is that we inscribed it once but many people can reuse it many times.
so one time cost but the benefit is tremendous as we can onboard thousands of generative artists onto ordinals.
This is a great discussion, and thank you both for such great questions and answers! I think this is covered by multi-file inscriptions, and inscribing popular libraries for reuse, so I'm going to convert this to a discussion.
gm. i created a few gen art inscriptions. they use some external creative coding libraries.
the inscriptions are done. the data is on-chain. just that the ordinals explorer couldn't render them, because the site doesn't allow external libraries.
can you guys please support external creative libraries? my code is using 2 popular libs hosted on cloudflare and 2 less popular libs hosted on our website (generative.xyz)
here is the inscription: https://ordinals.com/content/da2cde167d67f136d47ef78735f2f5a09c526c4e6574bfc172a1f0d6ee8f45a9i0
here is the error:
Refused to load the script 'https://cdnjs.cloudflare.com/ajax/libs/p5.js/1.5.0/p5.min.js' because it violates the following Content Security Policy directive: "default-src 'unsafe-eval' 'unsafe-inline' data:". Note that 'script-src-elem' was not explicitly set, so 'default-src' is used as a fallback.
da2cde167d67f136d47ef78735f2f5a09c526c4e6574bfc172a1f0d6ee8f45a9i0:1 Refused to load the script 'https://cdn.generative.xyz/ajax/libs/c2/1.0.0/c2.min.js' because it violates the following Content Security Policy directive: "default-src 'unsafe-eval' 'unsafe-inline' data:". Note that 'script-src-elem' was not explicitly set, so 'default-src' is used as a fallback.
da2cde167d67f136d47ef78735f2f5a09c526c4e6574bfc172a1f0d6ee8f45a9i0:1 Refused to load the script 'https://cdnjs.cloudflare.com/ajax/libs/chroma-js/2.4.2/chroma.min.js' because it violates the following Content Security Policy directive: "default-src 'unsafe-eval' 'unsafe-inline' data:". Note that 'script-src-elem' was not explicitly set, so 'default-src' is used as a fallback.
da2cde167d67f136d47ef78735f2f5a09c526c4e6574bfc172a1f0d6ee8f45a9i0:1 Refused to load the script 'https://cdn.generative.xyz/ajax/libs/p5.grain/0.6.1/p5.grain.min.js' because it violates the following Content Security Policy directive: "default-src 'unsafe-eval' 'unsafe-inline' data:". Note that 'script-src-elem' was not explicitly set, so 'default-src' is used as a fallback.
thanks!!