Recursion

[casey]

SVG and HTML inscriptions should be able to access other inscriptions and use their content. They should be sandboxed such that they can't reach any external URLs.

Serve at a separate origin, and enforce same origin policy.

# inscription by ID
/ID/
# inscription by number
/N/
# inscription by symbol
/SYMBOL/
# inscription by relative number (+ or - this inscription's number)
N

Relative inscription numbers can be used to reference inscriptions made within a single transactions, where the inscription ID isn't known in advance.

Note slashes in URLs, so that relative URLs are appended correctly.

[bradleykirby]

If we decide to allow https://github.com/casey/ord/issues/786 then being able to reference other inscriptions on the same sat that occur in the future could allow for some limited mutability.

I'm imagining a prime inscription referencing the sat's subsequent inscriptions to use as an input to its rendering logic.

A simple example could be a "counter" inscription that rendered a number that was incremented each time a new inscription was created on the sat. Or a "guest book" inscription that would allow future owners of the sat to add an entry to a log.

This would fit nicely with the Yes. Show inscriptions after the first with less prominence, like comments. vision of multiple inscriptions on the same sat. And it would let us "stamp our digital artifacts with our chop-mark", no smart contracts or upgrade keys needed.

Syntactically it would be enough to have a pointer to the next inscription on a sat:

# Next inscription on this sat (ordered by timestamp)
next

[LunarMiolk]

BIP-322 fixes this methinks

A creator commits to a message. The message defines a protocol for combining a number of assets. The web client combines the requisite resources strictly by inscription ID.

[cognitive-canvas]

For HTML content, the only thing you need to do is change the way 'preview' pages are displayed?

When you show an HTML inscription in the iframe on your inscription page, you have a csp header:
content-security-policy: default-src 'self' and the iframe is sandboxed with sandbox='allow-scripts'. This will allow relative inscription urls to load in script, img, and other tags in the HTML, so we can reference other inscriptions as relative urls. Great!

But when in preview mode, it displays the HTML directly from your site (not in an iframe), and you add the csp header:
content-security-policy: default-src 'unsafe-eval' 'unsafe-inline' . I assume this is for safety, but it prevents relative inscriptions from loading.

To be consistent, maybe just load the preview in an iframe too (using the full page) and make the headers and sandbox the same as the iframe above. Then there is nothing more to do for this issue, at least for html content.

[sjalq]

Is this possible yet?
If not, is there any workaround for this?

[sjalq]

I take it this needs to be a standard of some sort that extends how Ordinal explorers interpret URLs?

Can someone please point me to, or give me an example of, how such a reference would look inside a piece of HTML?

[cognitive-canvas]

Totally agree with @sjalq on the significance of this issue for generative art. No need to change ordinals, just adopt a convention to avoid excessive code duplication on the blockchain. Current method: copying all code into <script> tags for each iteration - not ideal but better than images.

Two possibilities:

1. Relative URLs align with the idea of ordinals as a global web space of files, making it a good solution. Ordinal servers would manage this convention easily.

2. Adopting a new protocol scheme like ord:// could offer more flexibility beyond HTML web pages.

My preference is the ord:// scheme, as it provides a straightforward interpretation initially (likely just a relative URL) while leaving room for future development.

[sjalq]

@cognitive-canvas I've been playing around with this and I think the easiest, lowest hanging fruit on this is if we can just access inscriptions via the inscription id (as I tried to do in this HTML inscription: https://ordinals.com/content/adcc57e8f9099025804863e2cca2bb1bc305f9289832f5a233bc6202d449057ci0)

@casey is we can change the explorer's CSP to something like:

default-src 'unsafe-eval' 'unsafe-inline' data:; img-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'

This would allow is to use plain inscription id's as resources and would allow us to compose both code and images.

What can I do to help facilitate this?

=========

From the looks of the code, we only need to modify this:
https://github.com/casey/ord/blob/0d54a536c4046952465966c6126b98dcd9f310bc/src/subcommand/server.rs#L748
https://github.com/casey/ord/blob/0d54a536c4046952465966c6126b98dcd9f310bc/src/subcommand/server.rs#L2148
and
https://github.com/casey/ord/blob/3b49ab287ec54985746ae86eb1215abd94b7c5e2/tests/server.rs#L18

[cognitive-canvas]

@sjalq, indeed, using script-src and img-src with 'self' seems to be the best approach (perhaps with minor adjustments, as mentioned below). This will function in all scenarios, whether or not an iframe is present, and will only allow content from the same domain. The team's primary concern appears to be ensuring that this doesn't introduce new vulnerabilities, since 'self' can theoretically refer to other pages within the domain, not just the ordinals. By using something like script-src: 'https://ordinals.com/content', you can effectively close that security gap.

[sjalq]

For the sake of showing effort, below is what I propose as the exact configuration.

Content-Security-Policy: default-src 'none'; img-src 'self'; script-src 'self' /content/; style-src 'self'

If similar constraints are desired for images and styles, I would recommend:

Content-Security-Policy: default-src 'none'; img-src 'self' /content/; script-src 'self' /content/; style-src 'self' /content/

[mrkmcknz]

I think @sjalq is making some reasonable suggestions on this. It would open the door for some exciting generative collections that utilise recursion. Not sure if this has been discussed on Discord or other avenues since April.

[casey]

Content-Security-Policy: default-src 'none'; img-src 'self'; script-src 'self' /content/; style-src 'self'

@sjalq Does this work? I was unable to get a CSP header with a bare path to work, e.g default-src /content/ is not a valid directive.

If bare path directives don't work, I believe it'll be necessary to use two CSP headers, which would be, omitting 'unsafe-eval' 'unsafe-inline' data::

content-security-policy: default-src 'self'
content-security-policy: default-src *:*/content/

Note the *:*, instead of a bare path. I was unable to get */content/ working, but *;*/content/ seems to work.

The first header allows any requests to the current origin, and the second header allows requests to any origin, but only at paths beginning with /content/. The browser checks both, so the end result is that only requests to the current origin with paths beginning with /content/ are allowed.

There are a few things that inscriptions may want to have access to, for example the current block height, the content of other inscriptions, the current location of the inscription, the current block time, etc. To avoid having to add these to the CSP header individually, I suggest we put them under a common path prefix, and allow access to anything under that prefix. I like the /-/ path prefix, so that would be:

content-security-policy: default-src 'self'
content-security-policy: default-src *:*/-/

Inscriptions could then access /-/content/INSCRIPTION_ID, /-/height, any anything else that was placed under that prefix.

[sjalq]

@casey , sorry bud I was distracted. I see you just took things live already! Thanks for including this!