Software developer
One deliberate body of work, held to a single standard: software you can verify, run fully offline, and trust not to phone home. Every project ships with public source and a static trust report, so a clean no-telemetry posture is something you can inspect before you run it — not a claim you take on faith. Built in the open as a standing practice in AI pair-programming.
github.com/ariugwuM.S. in Cyber Security. Full-stack background spanning TypeScript, .NET, SQL Server, and Elastic Search. I gravitate toward security and reliability problems — and toward turning them into things you can read, run locally, and audit yourself.
One body of work in three parts — the apps you run, the libraries they're built from, and the passion projects I tinker with. The trust report each one ships is concrete, not a slogan: an SBOM, a full license inventory, and a documented offline posture, versioned in plain files in the public repo.
Three plain promises, the same for every project — and each one you can check for yourself:
Verifiable. The source is public, and every project ships a trust report: a parts list of everything inside it (an SBOM), a full inventory of the licenses, and a note on how it behaves with the network off. You don't have to take my word for any of it — the receipts are right in the repo.
Offline. These run on your own device, in your own browser. Switch the network off and they keep working; your files and notes never have to leave the machine.
No telemetry. Nothing phones home — no tracking, no analytics, no accounts, no quiet uploads. There's simply nowhere for your data to leak to.
The reusable cores. Most are one Rust core compiled to native + WebAssembly and wrapped across several surfaces — a CLI, an npm package, a web app, a VS Code extension.
A pocket toolkit for the people who actually wrangle PKI files. Drop in a mystery X.509 cert in some odd encoding, a PKCS#12 bundle, a CHUID container, a portrait JPEG, or a fingerprint WSQ — pivlib will tell you what it is, classify the PIV key role from the evidence, and hand you a canonical form. One Rust → WASM core, five surfaces.
A pair of libraries for Elsa 3 workflows, sharing one home at elsa.ariugwu.com. The broker is a durable queueing front end: clients submit typed requests over an mTLS-secured API — the certificate is the identity, never the request body — and each request type is handled by a versioned Elsa workflow, tracked through a full audit trail you can poll. The diagrams converter turns Elsa 3 workflow JSON into Mermaid flowcharts — one Rust → WASM core wrapped as a CLI, an npm package, a web app, and a VS Code extension.
A converter that turns NetJSON documents — graph, configuration, monitoring, routes, or a collection — into PlantUML deployment diagrams plus an auto-generated Markdown paper for the metadata that doesn't fit cleanly in a diagram. Same Rust → WASM pattern as elsa-to-mermaid: one core, five surfaces (CLI, npm, web, VS Code, library crate). The Elsa Toolbox draws its broker architecture with it.