https://whopaystaxes.nyc Viewer for property tax inequity across New York City, built on public assessment data. Paper Route NYC.
property tax / open data / nyc / maps
Work
https://whopaystaxes.nyc 
https://letspaytaxes.nyc Multilingual intake for VITA free tax preparation. Paper Route NYC.
vita / multilingual / intake / nyc
https://househunches.casa Real-estate price-guessing game on NYC listings. A house is revealed clue by clue: photo first, then beds, baths, size, and neighborhood. Guess within 5% to win; fewer clues, bigger score. One shared Wordle-style daily with streaks and a shareable emoji result, plus unlimited free play. Listing data scraped from Zillow with a custom harvest pipeline. React and Fastify with a server-authoritative core: the price and unearned clues never leave the server early. Self-hosted from the homelab.
game / real estate / nyc / react / fastify / self-hosted
Security research portfolio piece. A Rust C2 framework demonstrating an Electron CDP injection chain: SIGUSR1 inspector activation into the Node runtime, then WASM-based modular post-exploitation, completing end to end in roughly 80ms. Closed by Electron as not in scope, but affected products were notified. Olmsted Firm.
rust / wasm / c2 / electron / security research
Remy’s Kitchen
Remy’s Kitchen is a small Rust C2 I wrote to demonstrate an Electron injection chain end to end, in roughly 80ms. Disclosed through The Olmsted Firm.
The chain
Sending an Electron application SIGUSR1, with the default fuse configuration that
covers most apps, activates the Node.js inspector, which binds to localhost without
authentication. From there you connect over the Chrome DevTools Protocol and execute
JavaScript in the main process’s Node context, reaching child_process, fs, and
any privileged IPC the application trusts. The payloads are WASM modules that load
into that context, and the full sequence completes in about 80ms. The inspector port
is exposed for a window too brief for a port scanner to catch.
Disclosure
I reported it to Electron as GHSA-65rv-vgcg-mxww. They closed it as out of scope for their threat model, and the affected downstream products were notified.
The point worth stating plainly: a stock Electron application exposes an unauthenticated code-execution path to any local process, with no user interaction and almost no trace. Out of scope and not a problem aren’t the same thing.
https://openward-demo.maxisaacs.com Corrections management system in Rust, targeting Caribbean jurisdictions.
corrections / rust / caribbean
Fast, cross-platform desktop music player for Subsonic servers (Navidrome, Airsonic, Gonic). React and TypeScript front end, Rust audio engine, Tauri underneath, no Electron. Native FLAC/MP3/AAC playback and local files, full-screen player with art and lyrics, library export to a poster, and a plugin system for custom components and Rust extensions.
rust / tauri / react / subsonic / audio
GuteMusik
GuteMusik is a native desktop music player for Subsonic servers, no Electron. I self-host my library on Navidrome and wanted something fast to play it with, so it’s React and TypeScript on the front end, a Rust audio engine underneath, held together by Tauri.
What it does
- Browse by album, artist, playlist, or chronologically
- Native playback of FLAC, MP3, AAC, and more through Rust, plus local files
- Full-screen player with album art and lyrics, and a pop-out mini player with the queue
- Search across the whole library, and export it to a poster
- Playlists, favorites, and starred albums, synced back to your server
- A plugin system for custom components and Rust extensions
Running it
It’s alpha, with builds for Linux, macOS, and Windows (the Windows build is untested, since I don’t have a machine to try it on). You’ll need a Subsonic-compatible server.
git clone https://github.com/MaxwellIsaacs/gutemusik.git
cd gutemusik
npm install
npm run tauri:devCryptographically anonymous polling. The operator can verify that eligible people voted, but never how anyone voted. Enforced by the protocol, not by policy. Zero-knowledge proofs with deterministic nullifiers prevent double-voting, and the tamper-evident vote chain is publicly auditable. Built in Rust, no blockchain.
rust / zero-knowledge / cryptography / voting / anonymity
Sealed
Sealed answers a question I wanted settled. Can you run a poll where the operator can prove the result is legitimate but genuinely cannot determine how anyone voted, not as a promise but as a property of the system? You can, and this is the implementation, in Rust.
What it guarantees
- The operator can prove every counted vote came from an eligible participant, and that no one voted twice.
- No one, whether the operator, an observer, or a later auditor, can link a vote back to the person who cast it.
Those two properties usually trade off against each other. Sealed holds both, because the anonymity isn’t a policy anyone chooses to follow. The link simply isn’t expressible in the system.
How it works
Each voter proves membership in the eligible set with a zero-knowledge proof, without revealing which member they are. A deterministic nullifier yields one unlinkable marker per voter, so a second ballot is rejected without revealing whose it was. Every ballot is recorded in a tamper-evident chain that anyone can audit, so the final count is independently verifiable.
No blockchain. It doesn’t need one.
/sudoku-wasm/index.html High-performance Sudoku built in Rust and compiled to WebAssembly. Algorithmic generation and canvas rendering, playable in the browser.
rust / wasm / canvas / web
DAG-based orchestration for Claude Code agents across git worktrees.
claude code / dag / git worktrees / agents
Nightrunner
I don’t love OpenClaw. I don’t really see the use for it, and I’m not about to hand an agent unfiltered access to my homelab and hope it behaves. But I did want to hand off a night’s worth of coding and wake up to it done, so Nightrunner is the version I’d actually trust. It runs on a ThinkPad T450 with a broken keyboard that sits on my Tailscale network with no inbound access from outside it, takes a spec, decomposes it into a graph of prompts, asks its questions up front, then executes the graph overnight with Claude Code, committing as it goes. I can check in from my phone, but I never have to.
The shape of a run
spec.md → decompose → question pass → run the graph → git branches + commitsThe dependency graph
Decomposition produces one prompt per file plus a sequence describing how they depend on each other:
1.a -> 2.a || 2.b -> 3.aNumbers are tiers. Tier 2 doesn’t begin until all of tier 1 is done. Letters are
tracks that run concurrently (2.a || 2.b). That’s the whole grammar, and it’s
enough.
Why it asks first
The failure mode I wanted to avoid is an agent guessing at 3am and building the wrong thing for hours. So before anything runs, a single session reads the whole spec, records every ambiguity and open decision, and waits for my answers. Those answers are folded into the prompts before execution begins.
https://no-button.maxisaacs.com A tool for buying the No side of NBA player-prop markets on Kalshi. FastAPI backend signs and places orders; a Next.js arthouse UI on top. A thin contract gateway bridges two independently-specced wire protocols.
kalshi / fastapi / next.js / trading
No.
Kalshi doesn’t let you buy the No side of an NBA player-prop market from their interface. The only way to take that side is through the API. A friend of mine wanted to do it regularly, so I built the interface that should exist: a FastAPI backend that holds the credentials, prices the No side, and places the order, with a Next.js front end over it.
The contract gateway
I specced the frontend and backend separately, and they ended up disagreeing on the
wire format. The frontend calls /orders, /markets, and /balance in camelCase.
The backend serves everything under /api/... in snake_case, with orders at
POST /api/orders/no. Rather than rewrite either side, I put a small translator
between them, demo/gateway.py, that speaks both. It’s required in production as
well as the demo, until I reconcile the contract inside one of the two codebases.
Running the demo
A mock upstream is built in, so the whole stack runs without a Kalshi account or any real money.
bash demo/run_all.sh # mock → backend → gateway → next, then open localhost:3000Going to production
Production places real orders, so a few things are worth knowing first:
- It trades a single account, the one whose keys are in the environment. There’s no per-user login, so anyone who can reach the UI is trading that account. Keep it off the open internet.
- I implemented the Kalshi-specific pieces (request signing, a few query parameters, the orderbook shape, the fee calculation) against their published spec, but haven’t verified each one against the live API. Place a demo order first and confirm the responses.
- Eligibility is enforced by Kalshi per jurisdiction, independently of this tool.
Credentials stay in the backend and are never committed.