Growing a mesh: early lessons from Dictyon-net and Hypha Nodes

Dictyon-net is my research project for a decentralized, low-power communications mesh. The nodes are called Hypha Nodes — a nod to fungal networks, which route nutrients across a forest without any central coordinator. That's the dream: a network that grows, heals and routes itself.

This post is about the ideas I'm testing, and the discipline I'm trying to keep while testing them.

Why a mesh, and why now

Most of my career was spent on networks with a clear center: data centers, core switches, hospital campuses. Those networks are excellent until the center goes away. A mesh has no center to lose. Every node is a little bit of infrastructure.

Projects like Reticulum have shown that you can build cryptography-based, transport-agnostic networks that run over LoRa, packet radio, serial lines, Wi-Fi or plain IP. Dictyon-net is inspired by that thinking, scaled to inexpensive ESP32 and RP2350-class hardware.

Idea 1: identity independent of transport

In IP networks, your address is tied to where you are. Move to a different network and your address changes. In a mesh, that's painful: a node might be reachable over LoRa now and over Wi-Fi in five minutes.

So identity comes from a key pair, not a location. A node is its public key (or a hash of it). Paths to that identity can change freely; the identity doesn't.

Idea 2: addressing that organizes itself

Nobody should have to assign addresses in a mesh. Nodes announce themselves; neighbors learn about them; routes form. The open questions are how much announcement traffic you can afford on a low-bandwidth radio and how fast the network converges after a node moves.

Idea 3: multipath, measured

When there are several ways to reach a destination — two LoRa hops, or one Wi-Fi hop through a gateway — which do you use? The answer depends on the traffic. A short status message wants reliability; a larger transfer wants throughput. I'm building automated path analysis that logs every path's latency, loss and hop count so routing decisions are based on data instead of assumptions.

The discipline: modular test setups

The biggest lesson so far isn't about routing. It's about experiments. A mesh has so many moving parts — radios, antennas, firmware, routing logic, power — that if you change two things at once, you learn nothing.

So the test setup is modular:

• Radio layer tests run with fixed firmware and a fixed routing table.
• Routing tests run in simulation first, then on hardware with a known radio config.
• Hardware changes (antennas, power, enclosures) get compared against a recorded baseline.

Every change is measured against a baseline. If a "better" routing idea doesn't beat the baseline on recorded numbers, it isn't better yet.

ESP32 or RP2350?

Both are in the lab. ESP32-class parts bring Wi-Fi and Bluetooth for free, which makes them natural gateways. RP2350-class boards are compelling for nodes that need precise I/O timing and lean power, with an external radio added. A heterogeneous mesh is the realistic future, so the network layer needs to treat them as equals.

What's next

• Long-duration tests to see how routes behave over days, not minutes.
• Power profiling: how long can a node run on a small battery while still forwarding traffic?
• More honest baselines.

I'll share results as they come — including the ideas that didn't survive measurement. Those are usually the most useful ones.