Miraculous Owonubi

Senior Rust Engineer · Distributed Systems, P2P Networking, Protocol

I design and build systems software in Rust: overlay networks, custom transports, storage engines, and protocol internals. I was a core engineer at NEAR and engineering lead at Calimero; I am now independent, building theia.

Selected work

NEAR core & developer tools

80+ merged PRs across nearcore, NEAR's core protocol client. Creator and principal author of the Rust NEAR JSON-RPC client; authored the NearSchema derive in near-sdk-rs; introduced contract ABIs; found and documented BOS platform exploits.

Calimero engineering lead

Calimero is a peer-to-peer app platform: apps run as WASM on each user's own node, and a group's shared state syncs between nodes over CRDTs, end-to-end encrypted. I joined as the systems engineer for its hardest problems while it was still a private sharding layer on NEAR; when that stalled, a protocol I prototyped at an internal hackathon won out and became the platform, and I built its stack: the node-to-node wire format, networking over rust-libp2p with hole-punching and relay, CRDT-state foundations, recursive state sync, an actor-model core, a purpose-built zero-copy storage layer, a Wasmer runtime with a swappable engine, and the guest-app SDK. I designed both generations of the protocol, a transactional proof of concept then an eventually-consistent redesign, and its end-to-end encryption for dynamic groups, and authored the adopted spec paper. As engineering lead I grew a team that was mostly new to Rust, hands-on, and reviewed most of what shipped. theia is where I keep building that same idea, further than Calimero's path allowed.

theia Rust · P2P overlay + services

A public-key-addressed peer-to-peer overlay and services layer I architected and built. You reach a machine by its ed25519 key instead of its address, and every service behind that reach is gated by a capability rooted in the same key, verified offline with no coordinator. Access is given per service, can expire on a date, and is taken back at the host: a revoke ends an open session, ssh included, in under a second, and leaves everyone else connected. The networking underneath is pluggable: iroh today (its hole-punching does the NAT traversal) and quirk, a UDP stack I wrote from scratch to understand how a modern transport works; by design the reach layer extends to a purpose-built transport per medium (Bluetooth and other non-IP radios), which is a goal, not yet built. A shared conformance suite holds every transport to one identity contract: a transport that misattributes who it reached is rejected, and a reference transport each must pass keeps the interface from overfitting to iroh. It's a stack of small Rust crates:

  • bifrost (reach): opens a byte-stream to a machine named only by its ed25519 key, carried over a swappable transport. Finding the peer across NATs is the transport's job (iroh's hole-punching); you address who a peer is, not where.
  • nauthy (the gate): one ed25519 key mints, narrows, delegates, and revokes capability tokens, each verified offline with no coordinator, rooted in the key a transport handshake already proved. Attenuable, expiring, and revocable through a denylist the node checks at admission.
  • tightbeam (the tunnel): publishes your local services by name behind the gate, runs a short handshake that selects one and confirms admission before a byte flows, then hands back a plain two-way stream, so any program speaking a TCP port or Unix socket rides it unchanged.
  • services (the engines): standalone units, fetch, measure, sshh (keyless SSH), and transfer, that each do one job on an already-admitted stream, embeddable one at a time.
  • swoosh (the product): one CLI that binds the layers into human verbs, ssh in, send files, forward ports, fetch through a peer, hand out revocable access, all by public key, with no IP addresses to manage.

Open source tools & contributions

  • freyr: a music-downloader CLI (Spotify, Apple Music, Deezer), 2.3k stars and 42k+ Docker pulls.
  • Merged upstream contributions to tickrs, Apache Arrow, rustyline, and dialoguer.

Approach

I build systems where control sits with the person using them, not with a company in the middle. In the theia-hq overlay, your identity is a key you hold, not a row in someone's database, so there is no account to register and no dashboard to suspend; the relays that carry traffic pass bytes they cannot read, and you can run your own. I reach for the smallest design that does the job, which sometimes means writing a layer from scratch to understand it and then deliberately not shipping it. The test I hold work to is whether it still answers to you when the vendor is gone and you are running every piece yourself.