A message board that needs no internet: the ESP32 captive-portal community hub
A message board that needs no internet: the ESP32 captive-portal community hub
Most community noticeboards moved onto the internet a decade ago, and the trade was never fully examined. The local corkboard became a Facebook group, and with it came accounts, algorithms, advertisers, data retention and moderation policies written in California. Victor Frost decided to run the experiment in reverse: he built a physical lantern-shaped device, solar-powered and battery-backed, that hosts a community message board on nothing but an ESP32 and its own Wi-Fi network. Hackaday featured the build in May 2026, and it is one of the clearest demonstrations in a while that useful networked infrastructure does not require the network.
The device looks like a lantern because it is one — a shell housing an ESP32, two 18650 lithium cells and charging circuitry fed by a 6-watt solar panel. Inside, there is no uplink of any kind. The ESP32 serves an HTTP page, but not on the world-wide web: the only way to reach it is to join the wireless network the device itself broadcasts. Connecting triggers a captive portal that shunts your browser straight to the message board, the same mechanism public Wi-Fi hotspots use to force a login page. Here it is repurposed for something friendlier — an unfiltered, very-local corkboard in the 21st-century sense.
The captive portal, briefly
A captive portal is an old and well-documented trick. When a client joins the network and the operating system probes for internet connectivity — every modern phone and laptop does this automatically — the device intercepts those probes and answers in a way that says "you are not on the internet, but here is where to log in." The phone then pops open its mini-browser on the portal page. Mozilla documents the HTTP status code this dance relies on, 511 Network Authentication Required, which exists precisely to signal "you must authenticate to this network before anything else will work." The Wikipedia article on captive portals covers the detection mechanisms in more detail, including the well-known connectivity probe URLs every OS hardcodes.
The elegance is that the ESP32 needs no DNS infrastructure, no certificates, no cloud. It simply answers the probes and serves one page. Anyone within a few tens of metres can read and post. Nobody further away can, because there is no internet connection to reach it through.
Privacy by architecture, not policy
For a privacy-focused readership, the interesting part is not the electronics — it is the threat model, or rather the absence of one. A conventional online forum collects IP addresses, device fingerprints, session cookies, and hands everything to a hosting provider under whatever jurisdiction applies. This device collects none of that, because there is no upstream. The board's data lives in the ESP32's flash and nowhere else.
There is also an inherent anonymity trade-off worth stating honestly, and Hackaday's commenters raised it: because access requires physical proximity, posters are within a few metres of the device, and therefore of each other. That is not anonymity by distance — it is more like the dynamics of an actual corkboard, where everyone writing a note can see everyone else reading it. Frost noted in the comments that some moderation capability exists after all: an admin panel, password-protected and reachable at a /admin path, lets the operator view all live postings and delete them individually or wipe the board. So it is unmoderated in the sense of having no terms of service, not in the sense of having no steward.
For Australian community settings — a festival, a permaculture site, a tool library, a scout camp — this proximity-is-identity property is arguably a feature. Local messages stay local, and the jurisdiction is the patch of ground the lantern sits on.
The engineering details that make it maintainable
Two technical choices deserve attention, because they are transferable to almost any long-lived ESP32 deployment.
First, the flash layout. Frost subdivided the ESP32's flash into three partitions: one for data and two for software, using LittleFS. The two software slots allow live updates with a known-good backup in reserve — flash the new firmware to the inactive slot, boot it, and roll back instantly if something breaks. Anyone who has bricked a remote device and faced a ladder-and-screwdriver recovery trip understands why this matters. It is the same A/B partitioning discipline that commercial OTA update systems use, scaled down to a microcontroller.
Second, the whole user interface — the HTML, CSS and JavaScript of the board's web page — is stored in a single string in PROGMEM rather than as files on the filesystem. That bundles firmware and UI into one artefact, so an update ships both together and there is never a version mismatch between the two. It is a pragmatic choice with real trade-offs (no independent UI iteration, harder web development tooling), and it works precisely because the UI is small and changes rarely.
The code is on GitHub under the GPL, which Hackaday notes sits comfortably alongside the solarpunk ethos — community infrastructure with community licensing.
Extending it with a mesh
The natural next question: what if you want the board readable beyond one lantern's Wi-Fi radius, without giving it an internet uplink? That is exactly what LoRa mesh hardware solves, and it is where our own product line picks up. The mesh community hub kit pairs the same self-hosted, no-internet philosophy with Meshtastic-style LoRa nodes, so messages can hop node-to-node across a valley or a campus while staying entirely off the public network. A single Heltec V3 node bridged to the ESP32's serial pins would let the corkboard relay postings out onto a wide-area mesh — still no internet, still local-first, just a much bigger patch of ground. For the fundamentals of how that mesh keeps messages private, see our Meshtastic encryption explainer.
Power is the other solved problem. A 6-watt panel and two 18650 cells are generous for an ESP32's duty cycle when the radios are throttled sensibly — our solar mesh power budget guide walks through the arithmetic for exactly this class of off-grid build, and the same numbers apply whether the load is a LoRa node or a captive-portal web server.
Why this matters beyond the lantern
It is tempting to file this under charming oddity. Resist that. The pattern it demonstrates — a small, solar-powered computer that provides a genuinely useful service with zero subscriptions, zero accounts and zero data outflow — is the template for a whole family of resilient local infrastructure: community sensor dashboards, offline emergency information points, event schedules at venues with no connectivity, teaching tools for digital literacy that do not require enrolment in anything. The technical components are all commodity; what Frost's build contributes is proof that the whole is small enough, cheap enough and reliable enough to leave outdoors on a pole.
Offline-first infrastructure is having a quiet resurgence, from mesh networking kits to self-hosted home servers, and the reason is not nostalgia — it is the growing recognition that "the cloud" is a dependency with terms you do not set. A lantern with a message board inside will not replace the internet. But for the message that matters most — the one for the people standing next to you — it turns out you never needed the internet in the first place.