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.

Current state (v0.1)

KeyRack has a keyrack-wasm crate that compiles to WebAssembly, exposing the same CryptoProvider interface as the Rust backend:

// You would need to write this wrapper yourself today
import init, { WasmProvider } from 'keyrack-wasm';
await init();

const provider = new WasmProvider();
const key = provider.generateKey('AES_256');
const ct = provider.encrypt(key, plaintext);

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.