The core insight is a classic computer science move applied to a real constraint: don't store what you don't need to reconstruct. Every prior ESP32 DNS sinkhole loaded full domain strings into RAM, which meant you needed PSRAM — a $6-8 premium on a $2 chip. Mohamed Abozaid's project stores only 5-byte FNV-1a hashes of blocked domains, sorted in flash, and binary-searches them on each DNS query. The result: 141,000 domains in 0.67 MB of flash, matched in roughly 10 milliseconds, using about 50 KB of RAM. At 537,000 domains, you get statistically one false positive. The birthday-bound math is straightforward and honestly presented. At 40 bits, 141k domains produce zero expected collisions. At 537k, you get approximately one — meaning one legitimate domain gets incorrectly sinkholed. Dropping to 32 bits would save 20% flash but cost seven collisions at 250k entries. Going to 64 bits wastes three bytes per entry to solve a non-problem. This is the kind of engineering tradeoff analysis that separates a useful project from a proof-of-concept. The hardware story is equally clear-eyed. The target is the ESP32-C3 SuperMini with 4 MB flash and no PSRAM, costing roughly $2. A printable enclosure lets it plug into a router's spare USB port — no power supply, no extra box. The same hash-in-flash approach scales up: on a 16 MB ESP32-S3, you could hold 2.7 million domains versus 466k for strings in 8 MB of PSRAM. The technique isn't a workaround for cheap hardware; it's strictly better than the string approach everywhere. The security model is unusually honest for a hobbyist project. The author documents the exact threat model: Basic Auth over plain HTTP on port 80, which stops casual LAN abuse but not an on-path network attacker. CSRF protection uses a custom X-Requested-With header that blocks drive-by and attacks. The open WiFi setup portal is explicitly called out as an unencrypted radio link during the brief configuration window. Default credentials trigger a serial warning and dashboard banner. This is not enterprise security, and the project doesn't pretend it is. The build and update pipeline is designed for one-time USB flash followed by wireless everything. Firmware and blocklist both update over-the-air via the web dashboard. A GitHub Actions workflow rebuilds the default blocklist weekly and publishes it at a stable URL. The 4 MB flash creates a real tradeoff: dual-app partition tables (enabling firmware OTA) cap the blocklist at roughly 250k domains, while the single-app layout fits the full 537k list but requires USB for firmware updates. What makes this generative rather than merely clever is that it's a technique, not just a product. The hash-in-flash pattern works on any microcontroller with flash storage — it's a general approach to membership testing under extreme memory constraints. The project is open-source, well-documented, and has already drawn community contributions for classic ESP32 support. Featured coverage on Tom's Hardware and XDA Developers suggests it's reaching people who build things. The practical limitation is that this is still a DNS-level blocker with all the same constraints as Pi-hole: it can't block ads served from the same domain as the content, it can't do HTTPS inspection, and it relies on blocklist curation. But at $2 in hardware, plugged into a router USB port, it lowers the barrier to network-level ad blocking from 'buy a Raspberry Pi and configure Linux' to 'flash a chip and point DNS at it.'
