Note: Please check #2174 for documentation. Specifically, the endpoint URL has changed from the initial description, based on discussion here
Modify inscription content security policy header to allow for requests to /-/-prefixed endpoints, and add a /-/content/:inscription_id endpoint to allow inscriptions to request the content of other inscriptions.
Two CSP headers are required because it is not possible in a single CSP header to specify a policy that restricts requests to sub-paths of the current origin. So, we use two CSP headers, one to limit requests to 'self', the current origin, and one to limit requests to *:*/-/, the /-/ sub-path of any origin. Browsers check both CSP headers, which has the net effect of restricting requests to the /-/ sub-path of the current origin.
Restricts requests to /-/ instead of /content/ because we may wish to add more endpoints that inscriptions can access, for example block time or block height, and this allows putting them all under the /-/ path prefix, instead of having to add them all to the CSP header.
Works in Chrome and Firefox, nothing loads in Safari. I'm guessing that Safari doesn't correctly implement checking multiple CSP headers.
Questions:
Are we okay with Safari being broken?
Is /-/ reasonable, or should we just use /content/?
Closes #1082.
cbspears, kimo498, Omb77, Vingallo, tyleryu12, BXSWSSMBDX, and mintu9064 reacted with thumbs up emoji satoshi0770, jerryfane, sjalq, kimo498, antron3000, mintu9064, and w3n-grogu reacted with heart emoji
I don't really like the /-/ path prefix, because it may be a pain to have duplicate routes everywhere. Also more importantly how would that work in practice? You have a HTML inscription that references the /-/content/:inscriptionid endpoint? I think it would be best to have the same routes as normal because that is the way the people would be looking at what they are referencing. Along the lines of HATEOAS principles if that makes sense.
What is the down side of having many CSP headers?
What is the down side of having many CSP headers?
There isn't a downside other than the fact Safari (and potentially other browsers) does not support multiple CSP headers. The specification clearly outlines support for multiple headers.
Just using /content/ is simplest and shortest on-chain by a few bytes.
I don't really like the
/-/path prefix, because it may be a pain to have duplicate routes everywhere. Also more importantly how would that work in practice? You have a HTML inscription that references the/-/content/:inscriptionidendpoint? I think it would be best to have the same routes as normal because that is the way the people would be looking at what they are referencing. Along the lines of HATEOAS principles if that makes sense.
I tend to agree with Raph's take here - more straightforward to use the normal /content route.
Collaborator Author
I'm fine with ditching /-/, and just whitelisting /content/ directly. The CSP header will get longer as we whielist more endpoints, but in practice it won't be an issue unless we whitelist a zillion endpoints.
The reason will be displayed to describe this comment to others. Learn more.
This really is a bang for buck change!
Before I merge this self binds to the same URL scheme but *:*/content allows any scheme (i.e.http or https) but the layering will make sure the stricter of the two is enforced?
Also do we want to show an example inscription in the tests that uses this?
Collaborator Author
Before I merge this
selfbinds to the same URL scheme but*:*/contentallows any scheme (i.e.httporhttps) but the layering will make sure the stricter of the two is enforced?
Yup, that's correct.
Also do we want to show an example inscription in the tests that uses this?
I don't think it's something that should be in a test, since the actual sandboxing is performed by the browser, so a test can't check if it works.
It really it should be in the documentation somewhere, but we don't have any guides for making HTML inscriptions, which would be the obvious place to put it.
Okidoki, gonna merge this.
June 11, 2023 01:54
Is there a plan to support js and css files?
<script src="/content/inscription-of-scripts" />
<style src="/content/inscription-of-styles" />
Can this work under the new CSP headers?
Would be ideal to lower footprint and make dynamic websites.
Also would make the dev experience much better in development.
Collaborator Author
@eloremarc Yup, I just opened #2173 to support inscribing CSS and JS files. No changes should be needed to the CSP headers, they use default-src, which covers all kinds of resources.
So exciting! Who wants to volunteer to make a inscription friendly fork of Svelte?
So, it's only possible to use recursive inscription on HTML files, correct? How could one create a reference in a text file, for example?"
Collaborator Author
@jerryfane You can't, although you could compose text files from an HTML file.
can anyone help me with guide, how to create recursive inscription.
@eloremarc Yup, I just opened #2173 to support inscribing CSS and JS files. No changes should be needed to the CSP headers, they use
default-src, which covers all kinds of resources.
Bro, sorry to bother but i want to try inscribing 1 and using my logic design skill to create something, please help/guide me to create 1
@Durgesh728 same concept in HTML img
@Durgesh728 same concept in HTML
img
Bro means if i have to inscribe in ordinal wallet can i do it there, maybe i am not aware of creating general inscripton as i am not running any node, but using mediaors/inscripton service for creation of 1, please help me create 1 Recursive inscriptions.
@jerryfane You can't, although you could compose text files from an HTML file.
@casey got it. A few weeks ago, I introduced a standard called Generative BRC721, which shares many similarities with recursive inscriptions. In this process, collection creators initially inscribe their traits, encoded in base64, in a deployment inscription, while the actual digital artifacts refer to this deployment inscription and contain details about the individual traits used to compose the asset.
These assets are text files, which necessitates an off-chain renderer to be created by front-end systems. With recursive inscriptions, these assets can be transformed into HTML files, including their own rendering process. I've carried out an initial test at https://ordinals.com/content/a5349b30e93291909d31e03040923e9cdf752f08c2a0ae6caf22a7e325b5aaf6i0. The renderer itself can be inscribed and referenced within the asset inscription, ultimately leading to deterministic rendering.
I would appreciate any feedback on this idea (from anyone on this thread), as the initial concept is quite similar to recursive inscriptions.
I'm fine with ditching /-/, and just whitelisting /content/ directly.
Part of me thinks the /content/ is too general and should be further abstracted to ensure it is never accidentially replaced. Why not something like [^content] or just [^in] (abbreviation for inscription) to minimize size and ensure we are never replacing things that we shouldn't be?
I suggest creating a dedicated resource protocol for ordonals (ord) to avoid conflicts with other resources on the traditional internet (http, https, ftp): ord://content/:inscription_id
RecursivePunks, luismigueldev1, Neomeister2077, Decision2016, NoRaresEver, adsrf, thegodfava, sipalingtestnet, JGSharp, wuzhanfly, and 26 more reacted with thumbs up emoji DrK1NGG, tomlson2, kamarajendra, whitespur, lhui1991, zmeyer44, bergeron, lucas-cn1, tmoney145, GordonGit, and janniks reacted with thumbs down emoji
DrK1NGG, 0xdigiscore, kamarajendra, bankaholic, piiiieee, t4t5, bergeron, tmoney145, GordonGit, and janniks reacted with thumbs up emoji RecursivePunks, NoRaresEver, yellowdoodle, pabloust, pablopa2020, boldefarine, ramo-ux, and w3n-grogu reacted with thumbs down emoji
@jerryfane You can't, although you could compose text files from an HTML file.
@casey got it. A few weeks ago, I introduced a standard called Generative BRC721, which shares many similarities with recursive inscriptions. In this process, collection creators initially inscribe their traits, encoded in base64, in a deployment inscription, while the actual digital artifacts refer to this deployment inscription and contain details about the individual traits used to compose the asset.
These assets are text files, which necessitates an off-chain renderer to be created by front-end systems. With recursive inscriptions, these assets can be transformed into HTML files, including their own rendering process. I've carried out an initial test at https://ordinals.com/content/a5349b30e93291909d31e03040923e9cdf752f08c2a0ae6caf22a7e325b5aaf6i0. The renderer itself can be inscribed and referenced within the asset inscription, ultimately leading to deterministic rendering.
I would appreciate any feedback on this idea (from anyone on this thread), as the initial concept is quite similar to recursive inscriptions.
hi, Jerry I have checked your recursive gbrc inscription, it works perfectly. I think for simple image like ordibots, what you do is wonderful one inscription with html and json is simple enough for most users it could be a new standard for recursive gbrc inscription
Collaborator Author
We've just launched one of the first recursive collections (10k): "Recursive Punks" and all people have minted using /-/ and : in the syntax:
Example: https://ordinals.com/content/edf8823de582b35d1b4d32679227c7cd6c86d46e29665626ec40f0f16bb3347ai0
Can we agree on whitelisting this endpoint. In the end both ways should be valid.
Features are not final until they make it into a release, and should be considered subject to change at any time. We've already had multiple examples of people making invalid inscriptions speculatively, based on unreleased features, and my personal opinion is that it is not sustainable or desirable for ord to complicate the codebase or the protocol in order to support speculatively made invalid inscriptions which don't conform to what is eventually merged.
jerryfane, DrK1NGG, griffy, zmeyer44, facaid1, EasonSoong, t4t5, bergeron, lucas-cn1, and GordonGit reacted with thumbs up emoji pabloust, RecursivePunks, pablopa2020, yellowdoodle, facaid1, boldefarine, ramo-ux, StefanOpariuc, tyjvazum, and w3n-grogu reacted with thumbs down emoji
hi, Jerry I have checked your recursive gbrc inscription, it works perfectly. I think for simple image like ordibots, what you do is wonderful one inscription with html and json is simple enough for most users it could be a new standard for recursive gbrc inscription
Thanks! I've just pushed the first draft of the standard that now implements Recursive Inscriptions! Would be nice to have your feedback https://github.com/jerryfane/generative-brc-721/tree/recursive
We've just launched one of the first recursive collections (10k): "Recursive Punks" and all people have minted using /-/ and : in the syntax: Example: https://ordinals.com/content/edf8823de582b35d1b4d32679227c7cd6c86d46e29665626ec40f0f16bb3347ai0 Can we agree on whitelisting this endpoint. In the end both ways should be valid.
Features are not final until they make it into a release, and should be considered subject to change at any time. We've already had multiple examples of people making invalid inscriptions speculatively, based on unreleased features, and my personal opinion is that it is not sustainable or desirable for
ordto complicate the codebase or the protocol in order to support speculatively made invalid inscriptions which don't conform to what is eventually merged.
Thanks for your response Casey!
Really appreciate all your dedication to the ordinal space. In a message 5 days ago I've noticed you saying "The CSP header will get longer as we whitelist more endpoints". Would be amazing if we can agree on /-/content/:inscriptionid on the whitelist!
RecursivePunks, Memes-On-Bitcoin, josif33, Duckczester, HollywodMeta, MajnoonCrypto, diamineox, anansi1976, Sheryna1, ramo-ux, and 12 more reacted with thumbs up emoji Omb77, pabloust, pablopa2020, ramo-ux, Tsubasa10eth, boldefarine, pichangero, Abdel0071, RecursivePunks, tyjvazum, and w3n-grogu reacted with heart emoji
So asking for open discussion here,
I can post a GitBook I have nearly finished on this topic. I understand the CSP and Sandboxing to whitelist certain endpoints.
This is something I have been testing with a few people here on recursive ordinals using both Ordinals on BTC and Ordinals on LTC.
Now before you say anything the Ordinals Theory on LTC follows Casey's Ordinals Theory and really only implants the same changes just on a slower rate.
The Idea is to use the recursive format to allow at least pulls form the LTC OrdinalsLite.com/content/{inscription id} end point, or perhaps whitelist this.
Simply to save even more block space on BTC while using BTC for more of a recursion and LTC as more of a storage bloat since the block size is bigger etc...
I'm thinking of possibility of using it more so as a file storage system and aggregation via BTC which would hold benefits to both chains not just one. The cost difference here is pretty substantial in terms of bytes of storage available to you then.
The idea here is to host websites (big websites) with recursion. Using LTC ordinals blockspace and cheapness to then Becalled from Bitcoin Ordinals.
I suggest creating a dedicated resource protocol for ordonals (ord) to avoid conflicts with other resources on the traditional internet (http, https, ftp): ord://content/:inscription_id
Yes, please use existing standards, do not create new, self-invented standards. Keep it simple and stupid: ord://content/inscription_id
gmart7t2 pushed a commit to gmart7t2/ord that referenced this pull request
Jun 14, 2023
Thousands of people want /-/content/:inscription on the endpoint whitelist. It's not a made-up code, it was just updated to /content/ later on. Besides that, big exchanges are already support it. Isn't this what decentralization is all about? ❤️
Memes-On-Bitcoin, AllStarBallin, Monkeyll, pichangero, boldefarine, pablopa2020, pabloust, w3n-grogu, and tyjvazum reacted with thumbs up emoji lucas-cn1, t4t5, zmeyer44, tmoney145, GordonGit, and AIRBLOOD reacted with thumbs down emoji tyjvazum reacted with heart emoji
Collaborator Author
@Memes-On-Bitcoin Sorry, but PRs are subject to revision before they are merged, which is what happened here. We will not support /-/content/:inscription in ord.
zmeyer44, kiwidream, jerryfane, tmoney145, lucas-cn1, GordonGit, AIRBLOOD, and janniks reacted with thumbs up emoji boldefarine, pablopa2020, pabloust, and tyjvazum reacted with thumbs down emoji
Is there a limitation of recursive layers?
inscription1 > inscription2 > inscription3 > ...???
Collaborator Author
Is there a limitation of recursive layers?
inscription1 > inscription2 > inscription3 > ...???
Nope, there is no limit.
@Memes-On-Bitcoin Sorry, but PRs are subject to revision before they are merged, which is what happened here. We will not support
/-/content/:inscriptioninord.
We need decentralization in indexing. Thousands of people want /-/content:inscriptionid on the whitelist but 1 men decides different 🤥. Centralized as f*ck.
Fix of fade
pabloust, tyjvazum, and Monkeyll reacted with thumbs up emoji jerryfane, zmeyer44, tmoney145, and GordonGit reacted with thumbs down emoji Memes-On-Bitcoin, boldefarine, pablopa2020, pabloust, w3n-grogu, and tyjvazum reacted with heart emoji
We need decentralization in indexing. Thousands of people want /-/content:inscriptionid on the whitelist but 1 men decides different 🤥. Centralized as f*ck.
This is decentralized. If you feel strongly enough about this, feel free to spin up your own indexer that recognizes /-/content/ and see how many people decide to use it. Quit acting entitled for others to do the work for you.
I suggest creating a dedicated resource protocol for ordonals (ord) to avoid conflicts with other resources on the traditional internet (http, https, ftp): ord://content/:inscription_id
Yes, please use existing standards, do not create new, self-invented standards. Keep it simple and stupid: ord://content/inscription_id
Yes, if we could use ord://chainid/inscription_id, cross-chain ordinales would be possible
Collaborator Author
Yes, if we could use ord://chainid/inscription_id, cross-chain ordinales would be possible
ord will always be bitcoin-only, and will never support referencing data on other chains.
@casey greetings, could you answer me which steps should I follow to make recursive inscriptions collection on ordinals?
I will inscribe traits to ordinals
I will make generator for shuffle layers and get NFT done
I should inscribe this full ready NFT and it will be in collection?
Thank you for response!
@casey It is not too late to give the people what they want: just whitelist /-/content/:inscriptionid
ordinals is for the people😍
@RecursivePunks don't you think this has gone far enough? The decision has been made and catering to your special case will only set a bad precedent. It's really your responsibility to conform to the standard, not vice versa.
Right now on several marketplaces, users are purchasing your Inscriptions with the reasonable expectation that they are, as advertised, "Recursive" and "The first 10k recursive collection in ordinals." I was one of those users myself, until I was alerted by @tomlson2 's tweet. Not to mince words, I felt I'd been scammed.
When it becomes widely understood that your collection is not recursive (at least within the expected context, let's not quibble) and therefore not first, a lot of users stand to lose a lot of money. Not only is that obviously bad for users, it exposes you and the supporting exchanges to legal and reputational risk.
I would urge you to rename your collection and reword your description thereof to something less misleading. The orange background visible on the Magic Eden marketplace is not featured in your code, so that too is misleading.
Please be reasonable so we can all move on with building cool new things.
Just pinging myself to follow this thread especially to get an update on @RecursivePunks , as I am also one of the user of their ordinals. I do understand that @RecursivePunks has made a mistake and launched their inscriptions with a changes in the PR which were not merged yet. It's just a haste. I would not call it a scam as they did a free mint and didn't charge. Now the people like me would be suffering because they launched in haste. For the people and for the love of ordinals, we can whitelist /-/content too. Not sure, would welcome final decision. I also don't see how would it set bad precedent since there were initial discussion around - is /-/content reasonable in the main description of this PR, that means it was under consideration, maybe we can support this as a fallback @casey ?
Is it possible for inscriptions that are recursively invoked in the future to receive a share of the miner（mint） fees?
How is it possible to link the recursive inscription with a collection or the parent inscriptions ?
Reviewers
casey deleted the recursion branch
clrke clrke approved these changes
raphjaph raphjaph approved these changes
veryordinally Awaiting requested review from veryordinally
