Response to the opaque URL comment:

Below, I wrote some investigations that I did about the differences between opaque and other WASM files. But I guess if we want to treat opaque the exact same way as we treat the other WASM files it wouldn't be a problem:

• Add a new CopyPlugin to webworkers webpack config
• Add another global string variable injected into html e.g. opaqueWebworkerURL

The reason the differences exist in this revision of this diff is that I wanted to use the same opaqueURL for both tab-JS-context and webworker-JS-context. But the corresponding JS files for these context are hosted in different places and so have different default origins for network calls.

In website-responders.js this is how we specify the URLs:

olmFilename: '',
commQueryExecutorFilename: '',
opaqueURL: 'http://localhost:8080/opaque-ke.wasm',
backupClientFilename: '',

and for prod:

olmFilename: manifest['olm.wasm'],
commQueryExecutorFilename: webworkersManifest['comm_query_executor.wasm'],
opaqueURL: `compiled/${manifest['comm_opaque2_wasm_bg.wasm']}`,
backupClientFilename: webworkersManifest['backup-client-wasm_bg.wasm'],

I started investigating it and I discovered some weird things with the opaque WASM file:

• Alongside the web/dist/opaque-ke.[contenthash].wasm which is created with yarn prod, another file is created -> 955995f625ff00ecc335.wasm. I calculated hashes of both of these files and they match so the second file is also the opaque WASM code.
  • This also happens for yarn dev but instead of files being created they are hosted on the dev server (localhost:8080)
  • After adding my code which starts to reference the opaque on the shared worker (compiled to dist/webworkers/database.build.js) this file is also created from the shared worker webpack config (dist/webworkers/955995f625ff00ecc335.wasm)
  • The actual [contenthash] matches the beginning of the weird file name (dist/opaque-ke.955995f625ff.wasm)
• If instead of running initOpaqueKe(opaqueURL) (initialization function imported from opaque) I just run initOpaqueKe() the network call goes to http://localhost:8080/955995f625ff00ecc335.wasm (in dev mode). The WASM is downloaded successfully

So it looks like webpack is automatically copying the wasm file for us but I'm not sure why.

That still doesn't really explain why we use 'http://localhost:8080/opaque-ke.wasm'. Possibly just a mistake and it's not necessary?

Additionally in prod version, opaqueURL has compiled/ prefix while e.g. olm doesn't. This might be a difference in how the initialization code is generated by wasm-pack and emscripten?

Thanks @michal for this detailed research. Do we know who first introduced the opaque WASM? Was it me or @varun maybe?

I think the best next step here is to create a new Linear issue with your observations as well as proposed changes to make it consistent, and then to assign to whoever introduced the opaque WASM first. If it's a former team member, then you can assign to me.

The reason the differences exist in this revision of this diff is that I wanted to use the same opaqueURL for both tab-JS-context and webworker-JS-context. But the corresponding JS files for these context are hosted in different places and so have different default origins for network calls.

I think after migrating the Identity client to worker we will no longer need opaque on tab-JS-context, so it probably makes the most sense to now introduce a new CopyPlugin and match handling opaque wasm as other wasm files in our codebase, and after flipping the switch we can stop hosting this file for tab-JS-context?