TypeScript / Browser

Fit today: Poor — WASM target exists but developer experience is incomplete.

Who

Frontend engineers building browser or Node.js applications that need client-side encryption, data signing, or end-to-end encrypted features.

Local WASM bindings

KeyRack has a keyrack-wasm crate that compiles to WebAssembly, exposing a WasmKeyRack class backed by the Rust SoftwareProvider:

// Import the wasm-bindgen output from your local build.
import init, { WasmKeyRack } from './pkg/keyrack_wasm.js';
await init();

const provider = new WasmKeyRack();
const plaintext = new TextEncoder().encode('hello');
const aad = new Uint8Array();
const key = await provider.generateKey('AES_256');
const ct = await provider.encrypt(key, plaintext, aad);

What’s actually shipped

The WASM crate exists and compiles, but:

• No published npm package
• No high-level API wrapper — raw WASM bindings only
• No browser key storage integration
• No documented deployment path for browser apps talking to a remote KeyRack service

Recommended path today

For server-side TypeScript/Node.js, use the REST API (FOSS) — or, for existing AWS SDK code, the commercial AWS KMS shim — rather than WASM.

For browser apps, call KeyRack’s REST API from your backend — do not embed WASM client-side crypto until the npm package ships.

Biggest gap

Fixing TypeScript/browser requires a published npm package and higher-level API wrapper. This is the largest ecosystem gap in KeyRack’s use-case matrix.

See Developer guide for WASM crate details in the upstream repo.