Goal
Provide a WebAssembly wrapper around the core reVault API so browser and JavaScript/TypeScript clients can use the core lockbox functionality without going through the CLI.
Context
The Rust crate currently appears to be lockbox_core; confirm whether the public package/API should be named revault_core, lockbox_core, or a dedicated WASM package name before publishing.
The wrapper should target WASM consumers while keeping the core Rust API as the source of truth.
Proposed scope
- Add a WASM-friendly wrapper crate or package for the core API.
- Use
wasm-bindgen or the project-preferred WASM binding approach.
- Expose ergonomic JavaScript/TypeScript bindings.
- Support the expected runtime targets, at minimum browser use, and document Node support if included.
- Wrap common lockbox operations needed by clients.
- Convert Rust errors into clean, stable JS-facing errors.
- Avoid exposing raw secrets longer than necessary and document WASM memory/security limitations.
- Add examples for browser and TypeScript usage.
Testing
- Add CI coverage that builds the WASM target.
- Add smoke tests for the exported bindings.
- Add API-level tests for representative create/open/read/write flows where practical.
Notes
The core crates already contain some wasm32-unknown-unknown dependency configuration, so this should start by auditing the existing WASM readiness before introducing new structure.
Goal
Provide a WebAssembly wrapper around the core reVault API so browser and JavaScript/TypeScript clients can use the core lockbox functionality without going through the CLI.
Context
The Rust crate currently appears to be
lockbox_core; confirm whether the public package/API should be namedrevault_core,lockbox_core, or a dedicated WASM package name before publishing.The wrapper should target WASM consumers while keeping the core Rust API as the source of truth.
Proposed scope
wasm-bindgenor the project-preferred WASM binding approach.Testing
Notes
The core crates already contain some
wasm32-unknown-unknowndependency configuration, so this should start by auditing the existing WASM readiness before introducing new structure.