npub1fe…ejzfa on Nostr: Kimi K3 opinion on my fips-tollgate MVP: "Honestly? It's one of the better MVPs I've ...

Kimi K3 opinion on my fips-tollgate MVP:

"Honestly? It's one of the better MVPs I've read, and having now changed code in it rather than just reviewed it, I can say that with more confidence — the
codebase fought back in all the right places.
What genuinely stands out The dependency discipline is the headline. A stdlib-only core with the entire Cashu/Nostr dependency graph quarantined in one isolated module means the
money-and-access logic is auditable in an afternoon, builds offline, and tests without network. Most projects get this backwards — they let the payment
library leak into everything and then can't test anything without a mint. You (or whoever drove those early phases) made the expensive-correct call before it
was expensive.

The safety engineering has real blast-radius thinking: --apply never implied, the /etc/fips fixture guard, managed blocks that preserve operator content,
atomic writes with fsync and directory sync, strict mode treating unmanaged allow entries as hostile. That's the mindset of someone who has been bitten by a
config-management tool clobbering hand edits before.

And the docs culture — phase reports with an explicit "honest limitations" section admitting the Phase 7 customer was your own upstream — is rarer than any
technical feature here. Projects that lie to themselves in their docs lie to themselves in their code eventually.

The one systemic blindspot

The expiry bug is instructive precisely because the testing was otherwise good. Every layer was verified: timers tested in-process, the live pilot tested the
adapters, replay tested against a real mint. But nobody ran the composed system in the shape it's actually deployed — purchase via one-shot CLI, process
exits, timer service ticks later. Each fish was healthy; the tank had a leak. That's the classic MVP trap, and the fix (reconcile over per-process timers) is
the right one because it matches operational reality instead of aspiring to be a daemon it isn't yet. I'd rather maintain a correct cron loop than a
half-built daemon.

What I'd watch as it grows

1. The CLI-per-action model is at its ceiling. Purchase races, 30-second expiry granularity, no event log — these all quietly point at a long-running process
eventually. Not now; the reconcile model bought you time. But the day you want sub-minute expiry or an audit trail, that's the daemon forcing function.
2. The money path is test-funds honest but real-funds fragile: payment-taken-gate-failed strands customer sats, and remainders vanish. Fine today; both must
close before any real-value pilot, along with the audit log — the first "I paid and got nothing" dispute with no event log ends the experiment.
3. The product question underneath it all: paid access to mesh-local services is a niche. The real TollGate gravity is internet-access resale. What this MVP
actually proves — that FIPS's npub identity + ACL maps cleanly onto TollGate's pay-per-allotment model, with cryptographic customer identity from day one
(no MAC addresses, no IPAM) — is the genuinely novel part, and it transfers. You're not locked into mesh-only; you've built the control plane either way.

Verdict

Compact (~3,200 lines, much of it tests), honest, correctly scoped, and now — with expiry reconciled — internally consistent in the shape it deploys. It's not
production-ready and says so, which is exactly what "good MVP" means: every claim in the README survived me checking it except one, and that one is fixed. The
distance from here to "a stranger could run this with test funds" is short and mostly paved: the P0 money-path items, the audit log, and a two-node pilot.

If you keep the same discipline — small phases, honest results files, verify in deployment shape — this has a real shot at being the reference FIPS-TollGate
bridge. Solid little fish. 🐡"