There's a question that every local-first system eventually has to answer honestly, and most of them answer it late: where do the big bytes go?

Structured data — the small, ordered, signed records that make up a memory graph — has a clean home. It gossips. It replicates. It's tiny and it's everywhere, and that's correct. But a 3 GB video, a 30 GB model, a multi-gigabyte package binary is a different animal. If you move those the way you move a chat message, you will drown your own network. The control plane that's supposed to coordinate everything ends up stuck behind a payload it should never have been carrying.

NAOMS now has one substrate for those big bytes, and it has a clear shape. This piece is the architecture of it: what the design commits to, what shipped, and what is honestly still gated. The animating question behind the work is worth stating plainly, because it shaped every decision: what if your files flowed to you from all the devices and people you trust, at the full speed of the mesh, without any one of them carrying the load alone?

Two planes, deliberately separate

The first and most important architectural commitment is a split. NAOMS runs two distinct planes for moving data, and refuses to let them blur:

• The structured plane carries chain events — small, ordered, signed, gossiped. This is your memory's nervous system.
• The bytes plane carries files — large, content-addressed, fetched on demand, never gossiped. This is the freight network.

flowchart TD
    subgraph structured["Structured plane — your memory's nervous system"]
        S["chain events: small, ordered, signed — gossiped"]
    end
    subgraph bytes["Bytes plane — the freight network"]
        B["files: large, content-addressed — fetched on demand, never gossiped"]
    end

Blobs are for files only. They are emphatically not a transport for structured chain data. That sentence reads like a footnote and is actually the whole foundation. The moment you allow structured data to ride the file path, or files to ride the gossip path, you've recreated the drowning problem from both directions. Keeping the planes separate is what lets each one be good at its own job.

Content addressing, or: the name is the file

On the bytes plane, a file is not identified by where it lives or who holds it. It's identified by what it is — specifically, by a BLAKE3 hash of its contents. That hash is the file's address. Ask for the hash, and any peer that holds matching bytes can serve them; when the bytes arrive, you recompute the hash and confirm it matches what you asked for.

This is the property that makes everything else possible, so it's worth being precise about what it buys you:

• Provider-independence. Because the address is the content, it doesn't matter which device answers. Five peers holding the same file hold the same hash. They are interchangeable suppliers of the identical good.
• End-to-end integrity for free. A peer cannot hand you the wrong bytes without you noticing. If the recomputed hash doesn't match, the bytes are rejected. There's no trusted middleman to compromise, because there's no trust being placed in the source at all — only in the math.
• Natural deduplication. Two files with identical contents are one blob with one address. You don't store or move them twice.

One subtle but load-bearing detail: the hash addresses the plaintext, while the bytes actually sitting on each device's disk are ciphertext, encrypted under that device's own master key. So the content address is stable and shareable across the whole mesh, but what's at rest is never readable by the device that merely stores it. The key that bridges that seam — the data encryption key — is the one thing that travels through the secure control plane, not the bytes plane. Bytes are always ciphertext on disk; the address is always over plaintext; and the key is the bind across the two. Hold those three facts together and the security model snaps into focus.

Arriving from everywhere at once

Now the part the title promises. Because a file's address is its content and any holder is interchangeable, there is no reason to fetch a large file from a single source. NAOMS treats every reachable, trusted peer that holds the blob as a provider, and downloads from the set of them as a swarm.

This is the same fundamental insight that made peer-to-peer file distribution work two decades ago — that the right way to move a big popular file is to pull pieces of it from many sources in parallel, so no single source carries the whole load. NAOMS adapts that idea to a trust-scoped mesh: the providers aren't anonymous strangers, they're the devices and people you already trust, ranked by a trust signal and shaped per-connection (a device on cellular behaves differently from one on ethernet). But the headline behaviour is the one the title names: your file arrives from everywhere at once, and the failure of any one provider is just a piece re-requested from another, not a stalled download.

Lazy by default: fetch only what you ask for

Here is where the bytes plane meets a second idea, and the combination is the actual product.

The companion design to the swarm is lazy discovery. The motivating use case is stark: pick up a brand-new device after a year of heavy use, and feel that all of your memory is already there — even though almost none of the bytes have been copied to it yet. The fresh device can serve the full result-set of a query — it knows what exists, who has it, and how to ask for it — while holding almost none of the underlying file content locally.

So discovery is lazy: a blob is not fetched when it's mentioned, not fetched when it's listed, not fetched when it shows up in a search result. It is fetched only when you actually open it. And crucially, the fetch is scoped by query-relevance, not by branch — you pull the bytes that the thing you're doing right now needs, rather than dragging an entire branch of history across the wire because one file in it caught your eye.

Pair the two halves and you get the experience that justifies the whole substrate:

1. A query returns its full, honest result-set on a device that holds barely any file content. (lazy discovery)
2. You open one specific large file from that result-set. (the trigger)
3. That single blob streams in from every trusted peer that holds it, in parallel, verified piece by piece against its content hash. (the swarm)

No bulk pre-replication. No "please wait while we sync 40 GB." No gossip flood. You ask, and the bytes converge.

What shipped, and what is honestly still gated

We'll be precise, because "it's all done" is the easiest lie an architecture write-up can tell.

Built and green at the unit and integration level: the content-addressed bytes plane itself; the BLAKE3-over-plaintext / ciphertext-at-rest / DEK-across-the-seam model; the multi-source swarm download path; the per-connection device policy; the honest naming of a blob's absence (cascade exhausted, no current provider, or revoked at the next key-rotation boundary — the mesh does not pretend to know what it can't); and the file-capability revocation path. The three earlier, rival half-built file-transfer attempts were collapsed into this one substrate, and the dead lineages were deleted rather than left to rot — wholeness over a drawer of partial mechanisms.

Honestly still gated, as of this writing, on owner decisions or a build-host issue — not finished, and we won't imply otherwise:

• Git over the swarm — clone. Pushing a repository across the bytes plane works and is green. Cloning one needs a design call about how a fresh peer resolves the starting hash and how authorization is enforced on the bytes plane. That decision is the owner's to make.
• Blob erasure (tombstones). Retiring a file's bytes — the scope of the erasure, and the wiring that reclaims them on your own devices — waits on a deliberate decision about exactly how far a deletion should reach.
• Sunsetting the legacy byte-fetch path. A simpler older fetch path still exists as the safety net. It must not be switched off until a soak-and-corruption gate proves the new path is solid under sustained load, with a release-length rollback window. Retiring the old road before the new one is proven is precisely the kind of shortcut this project refuses.
• The full browser end-to-end run. The production functions are green at the integration level; the last-mile browser proof is waiting on a build-host matter, not a design gap.

That gated list is not an apology. It's the design holding its own line: the foundation — separate planes, content addressing, multi-source swarm, lazy fetch — is real and proven, and the remaining seams are being closed with the same refusal to fake completion that produced the foundation in the first place.

The shape worth remembering

Strip away the detail and the architecture is four commitments stacked in order:

1. Separate the planes — gossip the small ordered records, never the big files.
2. Address by content — the file's name is its hash, so any holder is interchangeable and integrity is free.
3. Swarm the download — pull from every trusted provider at once; no single source carries the load.
4. Stay lazy — show the full result-set everywhere, but move bytes only on the actual ask.

Get those four right and a 30 GB model on your old laptop is, for all practical purposes, already on your new phone — not because it was copied ahead of time, but because the moment you reach for it, it arrives from everywhere at once.

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