I publish working code in public repositories you can inspect.
checking
api.github.com/users/KubaOpoczka
I have a package published on the npm registry: zustand-devtools-bridge.
checking
registry.npmjs.org/zustand-devtools-bridge
The Zustand DevTools extension source is public and MIT licensed.
checking
api.github.com/repos/KubaOpoczka/zustand-devtools
The signature verifier you can try is my code, and it's still maintained.
checking
api.github.com/repos/KubaOpoczka/verify
Faultline: a deterministic distributed-systems failure lab you can break in the browser.
checking
api.github.com/repos/KubaOpoczka/faultline
Signal Garden: a local-only Web Audio system that turns sound into generative structure.
checking
api.github.com/repos/KubaOpoczka/signal-garden
Second Order: 10,000 seeded futures moving through a visible causal model.
checking
api.github.com/repos/KubaOpoczka/second-order
The DKIM verifier is built from first principles. No cryptography library.
inspect
RFC 6376 canonicalisation, DER public-key parsing, PKCS#1 v1.5. The RSA step is a
three-argument
pow() and a byte comparison. No API can confirm
an absence; you have to look. It's in the page source of the
verifier; search
_rsa_verify and
sha256.
96 automated tests in the DevTools extension, across two major framework versions.
inspect
Two independent implementations of one spec agree byte for byte.
inspect
Seven awkward cases: folded headers, repeated headers, tabs and trailing whitespace,
a signed header that's absent, an empty body. Method in the
colophon. It is reproducible: paste your own email into the
verifier and the same code path runs.
DAEMON: an email threat-intelligence console with 28 Python modules and 130 passing tests.
not public
This repository isn't public, so you can't check that number from here. I'll walk through
the code or screen-share the suite on request. The DKIM module from it
is
public. It's the one running in the
verifier.
BABAFlow and Found Local: a compliance platform and a productised web-design service.
not public
Built, not trading. Neither is a running business and I'm not claiming customers or
revenue for either. Private repositories, available to review on request.
Two and a half years diagnosing hardware and software faults; Leaving Certificate 2024.
references
Laptoplabs in Bray, retail at Dunnes Stores, Presentation College Bray. Ordinary
employment history. References on request. No way to prove it from a web page, and
I won't pretend otherwise.
What this page requests
Seven anonymous, read-only GETs against endpoints serving
already-public data: the same values on my GitHub and npm pages.
There is no API key or token in this page, deliberately: a credential in a public
page is a leaked credential. So rather than raising GitHub's anonymous rate limit, a
blocked request fails honestly and shows you the endpoint. Nothing about you is collected;
your browser does contact api.github.com and
registry.npmjs.org, so those two see your IP, like any image would.
Why build a CV like this
Because the interesting question isn't what a CV claims, it's which claims survive
checking. Most of a CV can't be verified by a stranger, so the honest move is to make
the checkable parts genuinely checkable and mark the rest clearly, instead of letting
confident formatting do the work.
On a browser extension I shipped, a review pass over my own finished code found three bugs
I'd already released. None crashed. All failed silently and looked fine.
Code that runs isn't code that's right, and a claim that reads well isn't a claim that
holds.