Selected work

KERI Foundation, 2026

Python identity runtime for the browser

Added IndexedDB persistence to Keripy's Pyodide runtime and built WASM-compatible cryptography packages.

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

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.
  • WASM-compatible libsodium and liboqs packages, plus a Pyodide BLAKE3 recipe.
  • Local FortWeb runtime integration using the libsodium and BLAKE3 packages.

Key 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.

How I tested it

  • Identity creation, key rotation, and remote identity discovery in the browser.
  • Persistent state recovered by a fresh worker after reload.
  • Local runtime loading with WebAssembly builds of libsodium and BLAKE3.

Public code

Built with: Python, TypeScript, Pyodide, WebAssembly, IndexedDB, Emscripten

A note on scope

This case study describes implemented and locally validated browser-runtime work. It does not claim an App Store, Play Store, or packaged mobile release.