The problem
Native Python assumptions stop at the browser boundary.
Keripy was built around native Python, a filesystem, and compiled cryptography packages. A browser wallet needed the same identity behavior inside a Web Worker, without assuming native storage or native wheels.
What I owned
The parts I was responsible for.
I worked across the Python runtime, browser integration, storage layer, and build pipeline instead of hiding the browser behind a thin compatibility shim.
- Pyodide integration for the canonical Python identity implementation.
- IndexedDB-backed persistence for identity state across reloads.
- WebAssembly packages and recipes for libsodium, liboqs, and BLAKE3.
- Runtime packaging shared by browser and mobile-webview consumers.
Engineering decisions
Keep browser storage explicit
IndexedDB has different transaction and lifecycle rules from a native filesystem. The storage boundary is a first-class implementation, not an implicit fallback.
Build native dependencies for the actual runtime
The package pipeline pins Python, Pyodide, Emscripten, and wheel inputs so the cryptography modules match the runtime that loads them.
Test from a fresh worker
A browser reload is part of the persistence contract. Validation includes creating state, tearing down the worker, and recovering it in a new runtime.
Validation
What the implementation had to prove.
- Identity creation, key rotation, and remote identity discovery in the browser.
- Persistent state recovered by a fresh worker after reload.
- Runtime loading with WebAssembly builds of the native cryptography dependencies.
Claim boundary: This case study describes implemented and locally validated browser-runtime work. It does not claim an App Store, Play Store, or packaged mobile release.