DEV Community: Isaiah Peter

Student proposal: can stolen money be traced across banks in seconds without sharing customer data? Please break this

Isaiah Peter — Thu, 01 Oct 2026 05:05:59 +0000

I'm a 300-level Computer Science student at NOUN in Lagos. I have no professional experience in fraud or banking, so this post is me asking for correction from people who do.

The problem as I understand it

When online fraud happens, the money often moves through several mule accounts and gets cashed out within minutes. Victims usually report hours later. Each bank or wallet only sees its own part of the trail, and privacy and banking secrecy rules (rightly) stop them from freely sharing customer data. So by the time anyone connects the dots, the money is gone.

The idea

Transactions are naturally a graph: accounts are nodes, transfers are edges with a timestamp and amount. My question was why money isn't traced like one across institutions. After reading around, I now understand the main reasons: each institution only holds its own edges, ledgers need strict consistency, and sharing data raises legal and competitive problems.

So my proposal is a federated, privacy-preserving transaction graph:

Each institution keeps its raw ledger and runs a local node.
There is no central database of everyone's transactions.
When fraud is flagged, a machine-readable alert follows the money from node to node. Bank A tells Bank B, "funds from case X arrived in one of your accounts." Bank B checks its own ledger, places a temporary hold, and forwards the alert to wherever the money went next.
The graph is never assembled in one place. It exists as a chain of handoffs.

The machine-only boundary

Only fixed-schema messages cross between institutions, with no free text and no names:

{
  "case_token": "c_8f21...",
  "account_token": "HMAC(consortium_key, account_no)",
  "amount_bucket": "100k-500k",
  "ts": 1767225600,
  "action": "HOLD_REQUEST",
  "sender_sig": "..."
}

Messages would be signed, sent over mutual TLS, rate-limited, and fully audit-logged. The receiving node can recognize its own accounts from the token but learns nothing about unrelated customers. Anything beyond match, hold and forward would require a legal process with a human involved.

Prior work

I know this isn't new. As I understand them, the BIS's Project Aurora, Singapore's COSMIC platform, FinCEN's 314(b) sharing and some federated learning pilots explore related ground. What I couldn't find is an open standard for the cross-institution alert protocol itself, which may mean the gap is real or that I'm missing something. Please tell me which.

Where I think it breaks (please attack these)

Re-identification: if tokens are stable and edges carry timestamps and amounts, could patterns link pseudonyms back to people? Would token rotation, per-case tokens and amount bucketing be enough?
Wrongful holds: automated holds will freeze innocent people. Who is liable, and how should expiry and appeals work?
Legal basis: is the NDPA or banking secrecy law a hard blocker in Nigeria, or can a consortium model work?
Adoption: would a bank or fintech realistically adopt an open spec? Or is a shared blacklist enough and this is overengineered?
Coverage gaps: wallets, crypto exchanges and cash-out agents that don't join would leave dark spots in the trail.
Taint rules: when mixed funds move, FIFO, proportional and "poison" tracing give different answers. Which would a court accept?

What I'd build first

A message spec
A two-node simulator showing a hold propagating across two simulated institutions
A threat model document covering re-identification and false positives

Everything would be open source (Apache 2.0). Keys, detection thresholds and any live network would stay with whoever operates a deployment.

What I'm asking for

Engineers: poke holes in the protocol, token design and failure modes.
People in fintech, banking, compliance or law enforcement: tell me what fraud recovery really looks like today and where this wouldn't fit.
Anyone: point me to existing projects or papers I've missed.

Nothing here is validated. It's a design I want torn apart before I write code, so blunt, specific criticism is the most useful kind. Thanks for reading.

No repo yet. I'd rather get your criticism first, then open one with the spec and a two-node simulator, and I'll link it in the comments once it exists.

A Tiny Nim Microservice, Three Real Bugs, and What They Taught Me About My Own Mummy Fork

Isaiah Peter — Tue, 15 Sep 2026 00:12:26 +0000

A Tiny Nim Microservice, Three Real Bugs, and What They Taught Me About My Own Mummy Fork

I recently needed something small: a POST /api/contact endpoint for my portfolio site at https://www.isaiah.name.ng that takes a name, email, and message, validates it, and emails it to me. The kind of thing you'd normally knock out without thinking twice.

I decided to build it directly on my own Mummy fork — the one with OpenAPI schema generation, typed validation, and composable middleware — partly to actually dogfood it on something real, and partly because I assumed a single-endpoint service would be trivial. It mostly was. But three specific bugs along the way taught me more about the fork's internals than building the fork itself did.

The Shape of the Service

Nothing exotic: a ContactBody type with name, email, and message, all required strings. Validation happens in two layers — parseValidatedBody[ContactBody] checks presence and type against the fork's schemaOf-generated schema, and then explicit checks enforce non-empty fields, a 2000-character cap, and a hand-rolled email format check. Either layer raising the fork's ValidationError gets mapped to a clean 400 {"error": ...} by installDefaultErrorHandler. A send failure is logged server-side and answered with a generic 500 — the caller never sees why an email failed to send, only that it did.

On top of that: CORS middleware that rejects disallowed origins with 403 and answers preflight requests properly, an in-memory rate limiter capping submissions at 5 per IP per 10 minutes, and the fork's loggingMiddleware as the outermost layer so every request logs method, path, and timing. The OpenAPI docs come free from the same schema the validator uses, served at /docs with the spec at /openapi.json — the whole reason I built the fork in the first place.

The Pivot Nobody Plans For: SMTP → Resend

The original plan was plain SMTP via std/smtp. It compiled fine against the fork. Then I deployed to Render's free tier and every send just hung until timeout — Render blocks outbound SMTP ports (25/465/587) on that tier. Resend's REST API runs over HTTPS:443, which isn't blocked, and needs just one API key. As a bonus, its failures come back as ordinary HTTP errors the handler already catches and logs, instead of the occasional AssertionDefect that a raw SMTP library can throw and potentially take a worker down with it.

This is the kind of constraint you only discover by actually deploying, not by reading docs — worth remembering if you're building anything Render-hosted that needs to send mail.

Three Bugs That Taught Me More Than the Feature Did

1. Two HttpHeaders types that look identical and aren't.
Mummy imports std/httpcore aliased internally, and Request.headers is typed against that aliased import. My module also did a plain import std/httpcore for the Resend payload types — and suddenly every header operation threw a "type mismatch" between what looked like the same type. Nim's module system treats the two imports as distinct type identities even though they're structurally the same. The fix was narrow: import std/httpcore except HttpHeaders, so my module only pulled in the pieces it needed for the Resend payload and left the header type alone. This was, by a wide margin, the buggiest hour of the whole build — and a good reminder that "same type, different import path" is a real failure mode in Nim, not a theoretical one.

2. gcsafe doesn't care that your global never actually changes.
The fork's Middleware and RequestHandler types are marked {.gcsafe.}, which means the compiler's data-race checker gets strict about any global state touched inside a handler — because Mummy dispatches requests across a worker-thread pool, not a single event loop. My CORS middleware read a var global holding the allowed-origins list, set once at startup and never touched again — and the compiler didn't care that it was logically immutable after init. It only sees a mutable global read from a gcsafe context. The fix was a {.cast(gcsafe).} block around that specific read, while the genuinely-shared rate-limit table stayed behind a real Lock — the same pattern the fork already uses internally for bearerAuthMiddleware. It's a useful distinction to internalize on a threaded server: "never mutated after startup" and "thread-safe" are not the same claim, and the compiler will only ever check for the second one.

3. An unregistered route means your middleware never runs — including for the request that most needs it.
Browsers send an OPTIONS preflight before certain cross-origin POST requests. Mummy only runs its middleware chain for methods that have a registered route — so with no OPTIONS /api/contact route, Mummy answered preflight with its own 405 before corsMiddleware ever got a chance to run. The browser never saw the Access-Control-Allow-Origin header it needed, so the real POST was blocked client-side despite the server being otherwise correctly configured. The fix was almost comically small: register an OPTIONS /api/contact route whose handler does nothing but exist, which is enough to route the request into the middleware chain where corsMiddleware can actually answer it with a 204. Easy to fix once you know it — genuinely confusing the first time a working-looking CORS setup silently fails only on the preflight leg.

What Actually Got Verified

Before calling it done, I ran it locally and checked the specific paths that tend to hide bugs rather than just the happy path: a disallowed origin (403), a malformed email (400 with the exact field named), a name at the 2000-character boundary (passes) versus one character over (rejected), six rapid submissions from one IP (five succeed, the sixth comes back 429 with Retry-After), and that /health and OPTIONS both stay outside the rate limiter so Render's health checks and CORS preflight never get throttled.

Why This Was Worth Writing Up

None of these three bugs were about the feature — a contact form endpoint is about as unglamorous as backend work gets. They were about the specific intersection of Nim's module aliasing, gcsafe's literal (not logical) read of what's safe, and Mummy's routing-before-middleware order. If you're building anything on Mummy — my fork or the original — that touches CORS, thread-shared state, or has more than one import path into std/httpcore, these three are worth checking for before you hit them the hard way.

The full service, Dockerfile, and a drop-in script.js for wiring this into any static contact form are in the repo if you want to see the whole thing end to end.

Adding OpenAPI Support to Mummy, a Nim HTTP Framework

Isaiah Peter — Tue, 25 Aug 2026 21:45:31 +0000

Nim doesn't have a lot of options for building HTTP APIs with the kind of
batteries-included developer experience you get in frameworks like FastAPI or
Express with Swagger middleware. mummy is a
fast, solid HTTP/WebSocket server library for Nim (my fork with the
additions below is at
github.com/isaiahpeter/mummy) — but out of the box, it
doesn't generate OpenAPI specs, validate request bodies, or give you typed
path parameters. So I forked it and added those.

This post walks through what I built, why, and what I learned extending an
existing Nim library instead of starting from scratch.

Why mummy, and why OpenAPI

I wanted a Nim backend for a few projects (a contact-form API, a todo API
demo) and kept missing three things I'd take for granted in other
ecosystems:

Auto-generated API docs — a /docs endpoint you can actually hand to someone, generated from your routes instead of hand-written.
Typed path parameters — pulling id out of /users/{id} as an int without manual parsing and error handling in every handler.
Request validation — rejecting a bad JSON body before it reaches your handler logic, with a schema to back it up.

mummy is fast and minimal by design, which is exactly why it was worth
extending rather than replacing.

What I added

OpenAPI spec generation. I added openapi_schema.nim and
openapi_router.nim, which let you wrap routes in an OpenApiRouter and
attach a summary, tags, and a response schema via schemaOf. The router
serves both /openapi.json and a browsable /docs page generated from your
actual route definitions — so the docs can't drift out of sync with the code
the way hand-written API docs do.

Typed path parameters. pathParam[T](request, "id") pulls a path
segment and parses it as the type you ask for, with a clean 400 response if
parsing fails. One gotcha worth flagging if you try this yourself: in this
Nim version, the generic dot-call form (request.pathParam[int]("id"))
doesn't parse — you have to call it as pathParam[int](request, "id")
instead.

Request body validation. parseValidatedBody[T] checks an incoming JSON
body against the schema generated by schemaOf, and returns a 400 with a
clear error message on mismatch, instead of letting a malformed body reach
your handler and fail in some less obvious way further down.

Composable middleware. A Middleware type and a use() method on
OpenApiRouter, plus a couple of built-ins — loggingMiddleware and
bearerAuthMiddleware — so cross-cutting concerns don't have to be copy-pasted
into every handler.

Migrating the examples

mummy ships with 12 example servers. I migrated all of them to the new
OpenApiRouter to sanity-check the additions against real, varied code
instead of just a toy case. That surfaced a few real bugs I wouldn't have
caught otherwise:

One example declared a requestBody schema for a route whose handler never actually read a JSON body — leftover from copy-pasting between examples. Easy to miss, misleading if it ships in generated docs.
The WebSocket example used a wildcard route (/*) for channel names. I converted it to a named path parameter (@channel), which also fixed a latent bug: the original handler read request.uri, which can include a ?query string, instead of the clean decoded path.

Only one example actually declared response schemas, and those checked out
correctly — the rest use the router's default 200 OK, which needed no
changes.

What's next

I'm using this fork to build a small todo API demo (deployed on Render) as a
live, working example of the OpenAPI/validation/middleware features
together, and a contact-form microservice for my own site. Both are useful
proof that the additions hold up outside of the example suite they were
tested against.

If you're working in Nim and have hit the same "no OpenAPI docs, no request
validation" gap with mummy or another minimal framework, I'd be curious to
hear how you've worked around it — or if you want to look at the fork
yourself, it's at github.com/isaiahpeter/mummy.

Things you need to know before learning django.

Isaiah Peter — Mon, 11 Sep 2023 02:05:19 +0000

The django framework is a web framework used to build web applications.It is also known as the framework for perfectionist with a deadline.The most trendy and popular python framework for web development.
You might be wondering what are the topics or things you should know before learning django.
First you must know the python programming language fundamentals.
what are these fundamentals?

variables
list, tuples and dictionary
functions
class especially how to inherit from another class properly
Understand object oriented programming
You should also have a basic understanding of html, css and javascript it will come handy when you are writing your models that will be translated to an html element.
know the GET and POST request what they mean and when to use them.
You also need to understand database and sql like foreignkeys, relationship between tables and how they map to your python model.
what a virtual environment is.
why django is called an MVT framework.
learn to use git and the django documentation.