Right now the NextJS application requires headers to be set:

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

This is to allow for multithreading to work. Otherwise we get this error:

Uncaught (in promise) Error: Failed to execute 'postMessage' on 'Worker': SharedArrayBuffer transfer requires self.crossOriginIsolated.

This is due to a security policy change in modern browsers. SharedArrayBuffers were disabled in most browsers because they could be used in a type of attack called a Spectre attack. SharedArrayBuffer and high-resolution timers could be used in combination to read memory across origins, which is a serious security issue.

However, SharedArrayBuffers were re-enabled on pages that are cross-origin isolated. Cross-origin isolation is a state a website can be in where it can safely use powerful features like SharedArrayBuffer.

Right now the NextJS requires that the config has an esmExternals: "loose" flag set up, so that it allows for the new Worker(new URL("../../barretenberg.js", import.meta.url)).

The alternative to this, is importing the worker script by using worker-loader, but it hangs on build due to the circular nature of the import.

The esmExternals: "loose" flag could be removed from NextJS by refactoring barretenberg and removing the circular dependency, and then adding worker-loader to the webpack config - or by finding a different way of loading the script.

Right now the NextJS app requires for minification to be disabled in the prod version of the build. This is likely not needed, and it could be because of webpack not resolving the worker script path correctly.

This can probably be fixed by fixing how webpack handles the minification of the worker script.

To minimize confusions:

• A "Working In Progress" warning should be added to the README until build and release infrastructures are in place and the builds hosted in this repo are ready for consumption
• The source code of where the builds are compiled from should be linked to in the README