Recursive inscriptions

[casey]

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.

[raphjaph]

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?

[mrkmcknz]

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.

[huuep]

Just using /content/ is simplest and shortest on-chain by a few bytes.

[veryordinally]

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.

I tend to agree with Raph's take here - more straightforward to use the normal /content route.

[casey]

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.

[casey]

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?

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.

[raphjaph]

Okidoki, gonna merge this.

[elocremarc]

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.

[casey]

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

[elocremarc]

So exciting! Who wants to volunteer to make a inscription friendly fork of Svelte?

[jerryfane]

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?"

[casey]

@jerryfane You can't, although you could compose text files from an HTML file.

[cryptomummy]

can anyone help me with guide, how to create recursive inscription.

[cryptomummy]

@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

[elocremarc]

@Durgesh728 same concept in HTML img

<?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>

[cryptomummy]

@Durgesh728 same concept in HTML img

<?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.

[jerryfane]

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

[kimo498]

I'm fine with ditching /-/, and just whitelisting /content/ directly.

[zmeyer44]

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?

[boring877]

https://unisat.io/brc20/recr

[SatoshiForce]

I have some questions about SVG 1, Does Recursive inscriptions support SVG format or only HTML? 2, Is there any issue with the format below? Currently, it is not displaying properly on ordinals.com.

<svg width="100%" height="100%" version="1.1" viewBox="0 0 64 64" xmlns="http://www.w3.org/2000/svg">
    <image href="/content/<inscirption_id>" x="0" y="0" width="64" height="64" image-rendering="pixelated" preserveAspectRatio="xMidYMid"/>
    ...
</svg>

The test inscription is this one: https://ordinals.com/inscription/6ca744d60618105ffd892801232a963378de2a135c44d04150a1caba7294d974i0

[huguojunsy]

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]

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.

[tomlson2]

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.

[DrK1NGG]

Acabamos de lançar uma das primeiras coleções recursivas (10k): "Recursive Punks" e todas as pessoas criaram usando /-/ e : na sintaxe:

Exemplo: https://ordinals.com/content/edf8823de582b35d1b4d32679227c7cd6c86d46e29665626ec40f0f16bb3347ai0

Podemos concordar em colocar este endpoint na lista de permissões. No final, ambas as formas devem ser válidas.

You had something with potential and you did it wrong congratulations 🤣🤣 Assume your own mistakes

[JerryYip456]

@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

[casey]

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]

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

[RecursivePunks]

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.

@casey

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!

[lukewrightmain]

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.