OmniNet

Why this writeup is honest

Most of the case studies on this site describe finished work. This one doesn’t. OmniNet is a set of ideas I spent a few weeks chasing in May 2025, prototyped enough to convince myself the simulations worked, wrote up in two long white papers, and then put down to focus on the projects that were closer to shipping. It’s still on my desk. It’s not abandoned, but it’s also not active.

I’m writing it up anyway because (1) the simulation results genuinely surprised me on the upside and I don’t want to lose track of why, (2) some of the ideas plug into NeuroMatrix in a way I want to think through in public, and (3) “shelved exploration” is a legitimate category of work — pretending the only valid case studies are finished products misrepresents how engineering actually progresses. If you’re reading this and you’ve ever spent two weeks in a side-project rabbit hole, you know the shape.

The starting question

Most of computing’s infrastructure is centralized — a few hyperscalers running a few continents’ worth of data centers. The economics of that model are extraordinary, but the failure modes are equally extraordinary: regional outages take large swaths of the internet offline, edge latency is unsolvable from a continent away, and the energy and capital concentration involved is hard to defend against any pressure that isn’t financial.

Meanwhile, the average household has multiple devices that are powered on and computationally idle for most of the day — a laptop, a phone, a smart TV, a router, maybe a home server. Estimates vary, but the aggregate idle compute capacity of consumer devices likely exceeds the active capacity of every hyperscaler combined. None of it is reachable as a coherent resource. The thing standing between “billions of idle CPU cores” and “a global mesh compute fabric” is, mostly, software.

OmniNet was an attempt to sketch what that software could look like.

The four threads

The project grew quickly because each problem I poked at turned up an adjacent problem worth poking at too. By the end of the exploration there were four interlocking threads.

1. OmniNet — the compute fabric

The core: a decentralized Kubernetes-like orchestration layer where idle consumer devices act as worker nodes, organized hierarchically into a supernode mesh, with workloads scheduled across the network by something closer to a market than a control plane.

The interesting design choices in the sketch:

• A three-tier device model. Full participants (devices with a custom OS, full hardware access — desktops, home servers), application-tier participants (devices running an OmniNet app on top of their normal OS — most phones and laptops), and connection-only participants (battery-constrained devices that contribute network presence but not compute). Pretending every device is equivalent is the failure mode of most peer-to-peer designs; respecting heterogeneity from the start gives you a network that actually works.
• A Rust UI for compute devices. The application-tier participant was meant to be a cross-platform Rust + Tauri app — system-tray icon, resource governor showing how much CPU/RAM/storage was being contributed, transparent reporting of what workloads were running. I got partway through this before the rest of the project went on the back burner.
• Hybrid networking. Direct device-to-device for local clusters (ad-hoc Wi-Fi mesh), supernode routing for regional coordination, traditional internet for cross-region. The hybrid is the point — pure peer-to-peer fails in real network topologies, pure server-centric isn’t decentralized, you need both.
• Container sandboxing as the safety primitive. A workload running on someone else’s machine has to be tightly bounded; the container is what makes that bounded.

The simulations covered network formation, supernode election, and workload placement at scales from 1,000 to 10 million nodes. The numbers that came out — 88 KB of routing state per node regardless of network size, sub-300ms route discovery in 10M-node simulated networks, 95%+ delivery success rates — were better than I expected. Simulation isn’t the real world, but the O(1) memory scaling result is the kind of property that’s either true or false; if it shows up in simulation it generally shows up in deployment too.

2. 3D packets — layered transmission over multipath

The second thread came out of the first: if you’re routing data across an unpredictable mesh of consumer-grade links, you need to think harder about what you’re routing than the conventional packet model lets you.

The 3D packet framework decomposes multimedia (video, audio, structured data) into semantic layers along three orthogonal axes — temporal (sequence), semantic (background vs. foreground vs. UI vs. audio), and transmission path (which route the packet takes). A 1080p gaming stream becomes four parallel streams: a slow-moving background layer that compresses 13:1, a motion-vector layer at 5:1, a UI overlay layer at 30:1, and an audio layer at 10:1. Each stream gets routed independently across the SD-WAN-style multipath. Total bandwidth: roughly 7.6× compression versus the 3.2× monolithic H.264 baseline, which is the headline 70–95% bandwidth reduction in the project’s TL;DR.

The interesting bits aren’t the compression ratios per se; layered video codecs are a known idea (SVC, scalable HEVC). The interesting bits are:

• Routing each layer separately. Different layers have different latency/reliability requirements. Audio absolutely cannot drop a packet; the UI overlay can wait two RTTs and nobody notices. Routing them as if they were one stream is leaving optimization on the table.
• Parallel arrival like a LAG. SD-WAN already does this for enterprise links — multiple physical paths bonded into one logical link. Doing it at the consumer-mesh layer over heterogeneous routes (one packet over fiber, one over LTE, one over a neighbor’s Wi-Fi) requires sequencing/reassembly that’s tighter than typical SD-WAN, but the principle generalizes.
• Graceful degradation when paths fail. If the motion layer’s path goes down, you lose motion temporarily — the background layer is still arriving, the UI is still arriving, the screen doesn’t go black. Layered transmission is its own redundancy strategy.

This thread is the one that felt most directly buildable. Most of the open problems are engineering rather than research.

3. Ant Colony Optimization — bio-inspired routing

Routing on a mesh of millions of devices needs a different shape of algorithm than the link-state protocols built for thousands. The thread I explored was Ant Colony Optimization (ACO): a population of lightweight “ant” probes wanders the network laying down pheromone trails on edges that work well — high bandwidth, low latency, high compression effectiveness — and pheromone evaporates on edges that don’t. Routing decisions sample the pheromone distribution. Over time the network self-organizes into preferred paths, and reorganizes when conditions change.

ACO isn’t new — Dorigo’s original 1997 paper is a classic, and there’s been steady work since. What was interesting in the simulations:

• Context-aware pheromones. Different traffic types (gaming, file transfer, voice) reinforce different pheromones on the same edges. The same physical link might be a 9/10 gaming route and a 4/10 file-transfer route, and the network learns both ratings simultaneously rather than collapsing to one global “goodness” score.
• Compression-aware reinforcement. Pheromone deposit was proportional to compression effectiveness on a path, not just to delivery success. Paths that route through nodes with strong compression compatibility get reinforced; the network learns to prefer them.
• Stable convergence at scale. I expected ACO to oscillate or get stuck in local minima at 10M-node scale. In the simulations it converged to within 6% of an oracle-best route in roughly 50 iterations on networks up to 1M nodes. I want to dig into why before I trust the result — convergence properties are exactly the kind of thing where simulation can flatter you — but the pattern was consistent across different network topologies.

4. Asymptotic encryption — the one that didn’t work

The last thread is the one I want to be upfront about: I had an idea, I pushed on it for a few days, and I don’t think it survives scrutiny. It’s worth including anyway because watching an idea fail is half of how exploration actually works.

The premise: most encryption schemes take low-entropy plaintext and turn it into high-entropy ciphertext, on the theory that ciphertext indistinguishable from random is what you want on the wire. What if you went the other direction? What if you took high-entropy data and asymptotically reduced its on-the-wire entropy toward zero, with the “missing” entropy redistributed across side channels — timing, packet ordering, link selection, the routing pattern itself? The wire payload would look almost like a constant; the information would live in the metadata of how the constant was transmitted.

The intuition was that traffic analysis becomes very strange when the content contains almost no information and the channel pattern contains almost all of it. An adversary capturing only the wire bytes captures nothing useful; an adversary doing full traffic analysis has to reconstruct information from a much wider attack surface.

The problems started showing up immediately. The side channels have less bandwidth than the original payload by orders of magnitude — the math on how much data you can encode in packet timing on a real network is unforgiving. The “asymptotically zero entropy on wire” framing is also a bit of a sleight of hand: from an information-theoretic perspective, the entropy doesn’t disappear, it just moves, and a sufficiently determined adversary observing the right channels gets it back. Real cryptographers have thought about steganography and covert channels for decades; I was reinventing a corner of that field, badly. The honest summary: it was a fun thought experiment, the math didn’t work out, I learned something about why mainstream encryption is shaped the way it is. That’s a valid outcome for a sketch.

Where this connects to NeuroMatrix

The thread I keep coming back to: there’s a coherent architecture where the OmniNet network is the substrate and NeuroMatrix-style spiking computation is what runs on it. The mapping is direct enough to be suspicious of, which is part of why I want to think about it more carefully:

• Devices as neurons. Each participating device is a node in the compute mesh and, simultaneously, a unit of computation in a larger spiking network.
• Spikes as messages. Neuromorphic systems communicate through sparse, event-driven spike messages — typically over the Address-Event Representation (AER) protocol on a chip. AER is conceptually identical to a routed packet on a network. A spike from device A to device B is an OmniNet packet.
• Sparsity matches the network’s strengths. OmniNet’s biggest concern is bandwidth — millions of consumer-grade links don’t have datacenter bandwidth. Spiking computation is, by design, sparse. A 25,100-neuron network at 0.71% instantaneous sparsity (the number from the NeuroMatrix paper) emits ~178 spikes per millisecond. That’s a routing load even a slow consumer mesh can handle.
• Continuous learning, distributed by construction. STDP — the learning rule NeuroMatrix uses — is local. Each synapse updates based only on the timing of its own pre- and post-synaptic spikes. There’s no global gradient, no parameter server, no all-reduce. Distributed implementation isn’t a translation problem; it’s the native shape.

The honest version of this is that I haven’t worked through the implications. The dishonest version would be to wave my hands and call it a vision. What I’ll say is that when I shelved OmniNet, I shelved it knowing there was probably a path back through NeuroMatrix, and that’s part of why the project is still on my desk rather than in the bin.

Why I shelved it

A few reasons, none of them “the project doesn’t work”:

Focus. In May 2025 I was simultaneously working on NeuroMatrix’s first paper, Fabrica’s solver rewrite, the Ensemble platform’s federation endpoints, and the EN-59 capstone. Adding a four-thread research project to that list meant doing all of them badly. NeuroMatrix had the clearest near-term result (a paper), Fabrica was the dependency that gated NeuroMatrix, Ensemble was production work for real users, and EN-59 had an external sponsor. OmniNet had none of those properties, and “this is interesting” isn’t enough to compete for hours.

Validation hardness. OmniNet’s simulation results were promising, but the bar for trusting them is high. Real network behavior at consumer-mesh scale doesn’t look like simulation, and the difference is often where the project either works or doesn’t. Getting from “the simulator says 95% delivery” to “real devices say 95% delivery” is an order of magnitude more work than I’d done.

The asymptotic encryption thread was a warning. When you find yourself reinventing a field’s known-hard problems, that’s usually a sign you’re outside the area where your intuition pays off. The encryption thread was that for me. The other three threads are more grounded, but the experience tuned my skepticism appropriately about how much further the other threads could be pushed without external review.

A path forward I trust more. The “devices as neurons, spikes as messages” framing in the previous section is, to me, a more interesting version of what OmniNet was originally trying to do — and it depends on NeuroMatrix being further along than it is. Putting OmniNet down to push NeuroMatrix forward isn’t a retreat; it’s compounding.

What I might come back to

Not commitments. Just the parts of this I haven’t stopped thinking about:

• The 3D packet framework as a standalone protocol. It’s the most engineerable thread. Layered transmission over multipath is a thing people are already paying for in enterprise SD-WAN; bringing the idea to consumer-mesh and to multimedia is a contribution of its own, independent of the rest of the OmniNet vision.
• Context-aware ACO routing. The result that pheromones can encode different “goodness” scores for different traffic types simultaneously is the kind of thing I want to see formally analyzed before I trust it. It might be obvious to someone who’s been in routing research longer than I have. If it’s not, it’s worth a paper.
• The neuromorphic-network mapping. As above. This is the thread most likely to pull OmniNet off the shelf, and it depends on NeuroMatrix being mature enough that the question “what does the network look like?” becomes the next bottleneck. We’re not there yet. We might be in a year.

The encryption thread I’m letting stay buried. Some lessons learn themselves.

If you’re working on decentralized compute, layered transmission, or bio-inspired routing — or if you’ve thought about the device-as-neuron framing and want to argue about whether it actually holds up — email me. I’d rather have someone tell me which of these threads is worth pulling on first.