The week's most-worked theme wasn't a feature you can screenshot. It was an invariant — a property a system must hold no matter what it is doing — and it earned more commits than anything else on the board. Stated exactly as the work item states it:

"the daemon is bounded only by system resources, never by its own JS thread(s)."

That sentence is doing more work than it looks like. Here is what it promises, and what it takes to keep.

How the local hub is supposed to work

A daemon is a program that runs quietly in the background rather than being opened and closed like an app. The NAOMS daemon is the local one every surface talks to: the terminal interface, the browser surface over a WebSocket connection, the command line, and other people's daemons — peers — reaching in from across the network. It is the single point through which identity, encryption, chain operations and peer sync all flow.

At its heart it runs an event loop: one thread that holds a queue of pending work and services it one item at a time, switching between thousands of in-flight operations. This is the concurrency model of most network programs written in JavaScript, and its premise is cooperative — each task promises to do a small piece of work and then yield, handing the thread back so the loop can serve the next one. Nothing is interrupted by force; everything takes its turn voluntarily. That is what lets one thread feel like many.

Now layer in what this daemon actually does, because it isn't shuffling JSON. It does cryptographic work. It calls into native Rust code through an FFI — a foreign function interface, the bridge that lets one language call directly into compiled code written in another — for the heavy lifting: signing, lattice operations, blob hashing. It appends to a chain, the append-only log that is the system's record of what happened.

So the invariant is a precise contract about those operations: the daemon may be slow because the CPU is busy or the disk is full — those are honest, system-level limits — but it must never be slow because one of its own operations refused to yield the loop. The bottleneck must always be the machine, never the daemon's own thread blocking on itself. In practice that means every heavy operation — a bulk import that signs ten thousand entries, an FFI call into grinding native code, a chain append — is written to hand the thread back rather than to run to completion inline.

And when the loop is busy anyway, there is a second door. The daemon carries a control plane on a Unix-domain socket — a local channel between processes on the same machine, addressed by a file path rather than a network port, entirely separate from the main request path. Control operations such as status and restart go through it, so they do not have to queue behind whatever the loop is currently working on. This is the deliberate part of the design: if the only way to ask a daemon how it is doing is the same congested front door as everything else, you cannot manage it precisely when it is struggling. The management channel is the one that has to stay reachable.

Beside it sits a daemon-state subsystem, which makes liveness a first-class, queryable fact rather than something you infer from a request that hasn't come back yet — and a clean restart path. That last one is an honest admission built into the design: even with the invariant held, the operational reality of a long-running background process includes "turn it off and on again," and that path deserves to be engineered rather than improvised into a kill-and-pray.

What goes wrong when the invariant is not held

Event-loop concurrency is a wonderful model right up until the moment it isn't. It has exactly one catastrophic failure mode, and every event-loop system shares it: a single synchronous operation that doesn't yield freezes everything. Not the slow operation — everything. Every connected client, every peer, every pending request, all stalled behind one call that decided to do its work without giving the loop a turn.

Every heavy thing the daemon does is a candidate. The bulk import. The FFI call that blocks while native code grinds. The chain append that does its work inline. Each is a loaded gun pointed at the loop, and the trigger is the word synchronous.

Here is what makes that non-optional rather than nice-to-have. In a single-user desktop app, a momentary freeze is an annoyance: the spinner hangs, you wait, it recovers. This daemon is the local hub for an agent fleet and a multi-surface client. When the thread blocks, it does not degrade one user's experience — it blocks the browser surface, the control path, the peer connections and every agent operation in flight simultaneously, because they all live behind the same loop. One un-yielding call doesn't slow the daemon down. It takes the daemon offline, for everyone, until it returns.

That is why this became the highest-commit theme of the week. Every other feature is only as available as the loop that serves it. An identity system that freezes is not a more secure identity system. It's a down one.

What landed, and what is still true afterwards

The marquee landing was exactly the three pieces described above: the production daemon-state subsystem, the control-plane channel over a Unix-domain socket, and the clean restart path.

We want to be precise about status, because honesty about partial work is one of our rules: this one genuinely shipped. It is one of the week's real, completed wins, not an in-progress claim. The invariant isn't a goal we're chasing; it's a property we landed and gated.

What it does not do is make slowness impossible. It makes slowness honest — which is the distinction worth carrying away.

There are two kinds of limit a system can hit. Honest limits come from physical reality: the CPU is saturated, the disk is full, the network is down, there are genuinely more requests than hardware to serve them. Those limits are true — the system is telling you something real about the world, and the right response is more hardware or less load. Dishonest limits come from the system's own structure: it is slow not because the machine is busy but because it fought itself, blocked its own thread, serialized something that didn't need serializing. A dishonest limit is a system pretending the machine is the bottleneck when the bottleneck is its own architecture.

"Bounded only by system resources, never by its own thread" is a commitment to only ever hitting honest limits. When this daemon is slow, the slowness should always point at something true. That is a Wholeness-flavored idea: a whole component's performance is governed by its real environment, not by an internal flaw it has to apologize for.

A footnote from the same day, on honest limits

It is fitting that 2026-05-21 had its own small lesson in honest versus dishonest limits, on the infrastructure side rather than the daemon side. From the day's chat:

"something went wrong. the wireguard tunnel stopped working. investigate" — owner message, 2026-05-21T15:25Z

"yes now it works again" — owner message, 2026-05-21T15:29Z

A four-minute network outage between hosts in the private mesh. That is an honest limit — the network was genuinely down, and the fix was to restore the tunnel, not to paper over it in software. Same distinction the daemon invariant draws, one layer down the stack: when something is slow or unreachable, find out whether the limit is real (fix the world) or self-inflicted (fix the code), and never let a self-inflicted limit masquerade as a real one.

The least screenshot-able theme of the week was also its most foundational. Every visible feature rides on a single loop, and a single loop is always one un-yielding call away from taking everyone down at once. The week's most-worked invariant is the unglamorous promise that it won't: that when this daemon is bounded, it is bounded by the machine telling the truth about its limits — never by the daemon lying to itself about its own.

Written by AI agents from real project logs; owned and edited by Mujo.