Add WalletKit browser WASM package POC

[Dzejkop]

Summary

• make crates/walletkit the browser WASM artifact source using target-specific UniFFI runtime wiring
• add the published walletkit-web package with compiled ESM, declarations, wasm-bindgen glue, optimized WASM, and embedded proving artifacts
• expose one browser initialization interface: initializeWalletKit()
• add a WASM-only ephemeral CredentialStore constructor for the current browser demo
• move ubrn generation, compatibility patches, and wasm-opt -Oz --converge into the package build
• convert the Next.js App Router POC into a consumer of walletkit-web@0.21.3 from npm and remove its duplicate Rust wrapper and generated bindings
• run WalletKit in a dedicated web worker and extend the POC with an opt-in staging flow: register an authenticator, initialize storage, issue a faux credential, and generate a uniqueness proof
• sign the staging RP proof request in-browser and proxy faux issuance through a same-origin Next route because the hosted issuer blocks browser CORS preflights
• build through the repository WASM Nix shell, which supplies Clang, LLVM, Node, Binaryen, Firefox, and geckodriver without host-specific paths

This remains a feasibility prototype: the package is published manually, but generation and publication are not integrated into the release workflow yet.

The branch is rebased onto #493 at 8fc59d6. That brings in walletkit-sqlite 0.21.4 and its encrypted persistent browser SQLite path using the multipleciphers-opfs-sahpool VFS, together with the exported initializePersistentStorage() setup function.

The example still deliberately constructs CredentialStore.newEphemeral(). Switching the example to persistent storage is a separate integration step: call initializePersistentStorage() in the dedicated worker, then construct the store with deterministic paths and host implementations of DeviceKeystore and AtomicBlobStore. The currently published walletkit-web@0.21.3 also predates #493, so the registry package must be updated before the published-package path can exercise those APIs.

Validation

• nix develop .#default --command cargo check --workspace --all-targets --all-features --locked
• nix develop .#wasm --command cargo test -p walletkit-sqlite --target wasm32-unknown-unknown (Firefox dedicated-worker OPFS test passes, including encrypted persistence without plaintext at rest)
• nix develop .#wasm --command bun run --cwd web/walletkit build
• nix develop .#wasm --command bun run --cwd examples/uniffi-web-authenticator-poc build with the published package
• Next.js production build also passes while linked to the locally generated package
• walletkit:local and walletkit:published successfully switch between the local Bun link and locked registry package
• full browser staging flow previously passed: registration finalized, faux credential issued, and a Groth16 uniqueness proof plus nullifier generated in browser WASM
• browser proof generation no longer panics on SystemTime, triggers UniFFI's recursive-mutex cleanup panic, or corrupts signed credential u64 fields through JSON
• the browser-generated proof-request JSON shape matches walletkit-cli proof generate-test-request
• malformed local faux-issuer proxy requests return 400 without contacting staging
• cargo fmt --all -- --check
• Prettier checks for the edited package/example files
• git diff --check

Known limitations

• pins the workspace to UniFFI 0.31.2 because generator 0.31.0-5 cannot parse UniFFI 0.32 metadata; remove the pin once update uniffi to 0.32 version jhugman/uniffi-bindgen-react-native#409 lands
• patches the installed generator's wasm-bindgen processor and generated TypeScript
• the published walletkit-web@0.21.3 package does not yet contain feat: persist encrypted WASM SQLite in OPFS #493's persistent-storage APIs
• the example's ephemeral browser store is intentionally discarded on refresh; persistent use still needs browser-side keystore and atomic-blob adapters
• embedded proving artifacts grow the optimized WASM to approximately 40 MB; lazy artifact delivery and bundle splitting are not implemented
• npm publication automation and WalletKit release-version synchronization are not implemented

[socket-security]

Warning

Review the following alerts detected in dependencies.

According to your organization's Security Policy, it is recommended to resolve "Warn" alerts. Learn more about Socket for GitHub.

Action	Severity	Alert  (click "▶" to expand/collapse)
Warn		Obfuscated code: npm @noble/hashes is 90.0% likely obfuscated Confidence: 0.90 Location: Package overview From: examples/uniffi-web-authenticator-poc/package.json → npm/viem@2.56.0 → npm/@noble/hashes@1.8.0 ℹ Read more on: This package | This alert | What is obfuscated code? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support@socket.dev. Suggestion: Packages should not obfuscate their code. Consider not using packages with obfuscated code. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment @SocketSecurity ignore npm/@noble/hashes@1.8.0. You can also ignore all packages with @SocketSecurity ignore-all. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.
Warn		Obfuscated code: npm @noble/hashes is 90.0% likely obfuscated Confidence: 0.90 Location: Package overview From: examples/uniffi-web-authenticator-poc/package.json → npm/viem@2.56.0 → npm/@noble/hashes@1.8.0 ℹ Read more on: This package | This alert | What is obfuscated code? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support@socket.dev. Suggestion: Packages should not obfuscate their code. Consider not using packages with obfuscated code. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment @SocketSecurity ignore npm/@noble/hashes@1.8.0. You can also ignore all packages with @SocketSecurity ignore-all. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.
Warn		License policy violation: npm caniuse-lite under CC-BY-4.0 License: CC-BY-4.0 - The applicable license policy does not permit this license (5) (npm metadata) License: CC-BY-4.0 - The applicable license policy does not permit this license (5) (package/package.json) License: CC-BY-4.0 - The applicable license policy does not permit this license (5) (package/LICENSE) From: examples/uniffi-web-authenticator-poc/package.json → npm/next@16.3.2 → npm/caniuse-lite@1.0.30001810 ℹ Read more on: This package | This alert | What is a license policy violation? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support@socket.dev. Suggestion: Find a package that does not violate your license policy or adjust your policy to allow this package's license. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment @SocketSecurity ignore npm/caniuse-lite@1.0.30001810. You can also ignore all packages with @SocketSecurity ignore-all. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.

View full report

[paolodamico]

we won't be able to release with this uniffi version (perhaps, we create rc releases)?

[paolodamico]

nit. I'd just put this under examples/web