Programmable Audio - SharedArrayBuffer on Ordinals.com

[owenstrevor]

We're emulating the Nintendo NES 8-bit sound chip and the Texas Instruments TMS5220 speech synthesizer chip to make the sound effects for the Pizza Pets project.

We noticed that ordinals.com is not running in a cross origin isolated environment, so therefore we do not have access to the "SharedArrayBuffer" object which we would like to be able to use in order to have communication between audio worklets and the main thread, without having to go through the hassle of copying memory buffers back and forth between threads.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer

I was wondering, would it be possible to set the necessary headers on your server to enable this?

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp

cc @patrick99e99

Thanks so much!

[Trollfarmer]

@owenstrevor Did you try the service worker approach?

https://dev.to/stefnotch/enabling-coop-coep-without-touching-the-server-2d3n

[patrick99e99]

@owenstrevor Did you try the service worker approach?

We are trying to have as good of a UX as possible, this means that we have an animated loading screen that displays immediately on page load, and proceeds to animate until all dependencies and resources have loaded. The "service worker approach" involves having an abrupt page refresh which would result in a less than ideal user experience based off of how we are loading / preparing the application.

It would be ideal if we can just get the ordinals indexers to all offer cross origin isolated environments by setting these headers.

[casey]

This seems reasonable to me. The only question I have is, it looks like these are more restrictive policies, is it possible that they could break any existing inscriptions?

[patrick99e99]

is it possible that they could break any existing inscriptions?

I can't see how. All these headers do is isolate the webpage from other origins, and disallow any communication with cross-origins that have not opted in. The result of this is the unlocking of features such as the SharedArrayBuffer.

Inscriptions viewed from the indexers already have no access to the outside world, so it's expected that they should not allow any cross-origin windows from interacting with them or making any communication with other cross-origins.

[casey]

Okay, sounds reasonable to me. Feel free to open a PR! It would also be worth thinking about how to communicate this change to the various explorers, since to get cross-ecosystem support, other explorers would have to add this header as well.

[patrick99e99]

Feel free to open a PR!

#3898

I thought more about this... One potential side effect of this change is that Ord will be completely broken for anyone attempting to run it on a different computer within their home network with intentions of accessing it remotely via a local domain like: my-other-computer-running-ord.local. This is because it requires a "secure context", so must be served with https with the exception of localhost being allowed for http.

For that reason, I added the server config option disable_cross_origin_isolated to allow people to get around this if it is ever an issue for them.

[casey]

Merged! I added a test, and changed the name of the flag to --disable-cross-origin-isolation. Thanks for the PR!