Recursive inscriptions #2167
Recursive inscriptions #2167
Conversation
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.
|
I don't really like the 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 tend to agree with Raph's take here - more straightforward to use the normal /content route. |
|
I'm fine with ditching |
There was a problem hiding this comment.
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?
Yup, that's correct.
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. |
|
Is there a plan to support |
|
@eloremarc Yup, I just opened #2173 to support inscribing CSS and JS files. No changes should be needed to the CSP headers, they use |
|
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?" |
|
@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. |
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 <?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg width="100%" height="100%" xmlns="http://www.w3.org/2000/svg">
<image href="/content/layer0_inscirption_id" x="0" y="0" width="100%" height="100%" />
<image href="/content/layer1_inscirption_id" x="0" y="0" width="100%" height="100%" />
<image href="/content/layer2_inscirption_id" x="0" y="0" width="100%" height="100%" />
<image href="/content/layer3_inscirption_id" x="0" y="0" width="100%" height="100%" />
<image href="/content/layer4_inscirption_id" x="0" y="0" width="100%" height="100%" />
</svg> |
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. |
@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? |
|
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. |
There's a reason it was changed. You need to take responsibility for making everyone mint svg that doesn't interact with ord. |
You had something with potential and you did it wrong congratulations 🤣🤣 Assume your own mistakes |
hi, Jerry |
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 |
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 |
Thanks for your response Casey! Really appreciate all your dedication to the ordinal space. |
|
So asking for open discussion here, I can post a GitBook I have nearly finished on this topic. 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} 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. |
Yes, please use existing standards, do not create new, self-invented standards. |
|
Thousands of people want /-/content/:inscription on the endpoint whitelist. |
|
@Memes-On-Bitcoin Sorry, but PRs are subject to revision before they are merged, which is what happened here. We will not support |
|
Is there a limitation of recursive layers? inscription1 > inscription2 > inscription3 > ...??? |
Nope, there is no limit. |
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 |
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. |
Yes, if we could use ord://chainid/inscription_id, cross-chain ordinales would be possible |
|
|
@casey greetings, could you answer me which steps should I follow to make recursive inscriptions collection on ordinals?
Thank you for response! |
|
@casey ordinals is for the people😍 |
|
@Memes-On-Bitcoin It's only your fault, stop trying to represent everyone |
|
@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 |
|
|
|
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 ? |
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_idendpoint 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:
/-/reasonable, or should we just use/content/?Closes #1082.