Some days a project ships a feature. Other days it ships a sentence. On 2026-03-18, NAOMS shipped a sentence. The commit subject reads, in full:

"NextGraph research: 3-layer architecture confirmed, sync not replace" — commit subject, 2026-03-18

That four-word thesis — sync not replace — is the whole reason this post exists. It was the day's headline among 233 commits, and it came paired with a second commit, "Research: deep NextGraph evaluation for NAO storage and sync layer." Two commits, one day, one project read end to end. This is what that reading found, and why a system that has its own storage layer spent a day studying someone else's.

A reconstruction. No journal survives from this week. Any intent, excitement, or reasoning attributed below to "us" or "the project" on 2026-03-18 is reconstructed from the two commit subjects and the project's surviving inspiration study of NextGraph, not from a recalled conversation. The technical claims about NextGraph are drawn from that study, and flagged where they are the study's assertion rather than something independently re-derived.

What NextGraph is

NextGraph is a decentralized, local-first platform built on peer-to-peer networking and Semantic Web standards. Its core unit is a Repo — a cryptographically secured container that is also an end-to-end encryption group, structured as a DAG of commits. If "a DAG of commits, but for your data instead of your code" makes you sit up, you are reading it correctly: this is a git-shaped model for structured, encrypted, syncable state.

What makes the design unusually complete is the layer cake on top of that DAG (this is the "3-layer architecture confirmed" the commit refers to — though the mapping of that phrase to the broker tiers below is our reading, since the commit note itself is terse):

• Three bundled CRDTs. A Graph CRDT (an RDF observed-remove set), Automerge for JSON, and Yjs for rich text — with an embedded OxiGraph triplestore answering SPARQL 1.1 queries over the result. NextGraph didn't pick one conflict-free type and force everything through it; it carries three and lets the data shape choose.
• A DID method, did:ng, with three stores — public, protected, private — so an identity's surfaces are separated by intended audience at the identity layer, not bolted on later.
• A two-tier broker model — Core (public), Edge (self-hosted), and Local (a client daemon) — with pub/sub sync, causal ordering over topic-based encrypted channels, and a Noise-Protocol-over-WebSocket transport.

And the line that matters most for what comes next: NextGraph's permissions are cryptographic OCAP — read is a decryption key, write is a topic private key. Capability is not a row in an access-control table you have to trust a server to honor. Capability is the key. That is a design value NAOMS shares all the way down, and finding it stated this cleanly in someone else's system is exactly why you read other people's systems.

"Sync, not replace" — what the thesis actually means

Here is the trap a memory system like NAOMS could easily fall into. You see a beautiful, funded, end-to-end-encrypted sync engine with graph CRDTs and a SPARQL endpoint, and the lazy conclusion is: adopt it wholesale, make it the storage layer, delete our own. "Replace."

The commit subject is a deliberate refusal of that. Sync, not replace. The reading concluded that NextGraph's sync model — the DAG-of-commits, the causal-ordered pub/sub, the encrypted topic channels — was the part worth learning from, and that NAOMS's own storage and identity substrate was the part worth keeping. You take the synchronization ideas; you do not surrender the foundation. The whole day's research resolves to which side of that line each NextGraph idea falls on.

That distinction is not a hedge. It is the difference between inspiration and dependency, and for a project whose first axiom is Wholeness — complete in itself, no external dependency for core function — the difference is load-bearing. A storage layer you import is a storage layer someone else can deprecate. The point of reading NextGraph closely was to absorb its best ideas without taking on its runtime as a hard dependency of your core.

What we took

Read generously and the takings are specific:

• The DAG-of-commits-for-data mental model. NAOMS already treats its history as append-only and cryptographically chained; NextGraph's Repo model is an independent confirmation that "git-shaped, but for encrypted state" is a sound spine for a sync layer, not a curiosity. Seeing a funded EU-backed project land on the same shape is corroboration you don't get from your own codebase.
• Capability-as-key. "Read = decryption key, write = topic private key" is a one-line statement of a principle NAOMS holds: access is enforced by cryptography, not by a trusted server's goodwill. NextGraph states it beautifully, and a good statement of your own value, found in someone else's house, is worth taking home.
• CRDT pluralism as a permission, not a sin. The instinct in a tidy system is to mandate one conflict-resolution strategy. NextGraph bundles three — graph, JSON, rich text — because real data has more than one shape. That's a license to stop apologizing for heterogeneity in a sync layer.

What we did differently (and why)

The honest fork in the road is cryptographic, and it is the most interesting finding of the read.

NextGraph's analysis is explicit: no proxy re-encryption (PRE). Direct key sharing only. Editors hold the topic private key; readers hold decryption keys; there is no transform or proxy mechanism in the middle. Sharing with a new reader means handing over keys directly.

NAOMS went the other way. The project's own cryptographic study of recrypt (identikey) — proxy re-encryption — sits right next to the NextGraph study in the same inspiration corpus, and PRE is the direction NAOMS pursued for re-sharing encrypted data without re-encrypting it from scratch. To be precise: actually adopting recrypt into the running core was a later-2026 development, not a 2026-03-18 fact. What 2026-03-18 records is the two studies sitting side by side — NextGraph's "no PRE" finding and the recrypt analysis — i.e. the moment the fork in the road became visible, not the moment it was resolved in code.

Why diverge here at all? Because the two systems optimize different sharing stories. NextGraph's direct-key model is simpler and avoids the considerable complexity and cryptographic surface of proxy re-encryption — a legitimate, defensible choice, and one that keeps their stack smaller. NAOMS weighted the ability to grant a reader access to existing ciphertext without re-encrypting it, and without the data owner being online more heavily, which is the problem PRE exists to solve. Neither is "right." They are different answers to "how does a third party come to be able to read something that was already encrypted for someone else," and the answer you pick ripples through your whole sharing model.

The other quiet divergence is reach. NextGraph's ORM SDK is, by its own documentation, browser-only — it depends on @ng-org/web and does not run in Node.js. NAOMS's core has to run as a long-lived daemon on a machine, not only in a browser tab, so a browser-pinned SDK was never going to be the substrate even if everything else had aligned. This isn't a criticism of NextGraph — a browser-first ORM is a perfectly coherent target for a collaborative-document suite, which (with the EU's ELFA consortium funding) is much of where NextGraph is heading. It's simply a different center of gravity from a sovereign memory daemon's.

Why this kind of day matters

A project that only reads its own code drifts into believing its choices are the only choices. The discipline NAOMS tries to keep — honor the people doing adjacent work, take what's good, be precise about what you didn't take and why — is partly a humility practice and partly a correctness practice. You find out your "capability-as-key" instinct is sound because a funded research project independently reached it. You find out your PRE bet is a real bet, with a real alternative, because a serious system declined to make it.

NextGraph is genuinely excellent work, and the right response to excellent adjacent work is to study it closely and steal its clarity, not its runtime. The commit said it in four words. It took this whole post to unpack them, but the thesis holds: sync, don't replace. Read everyone. Depend on no one. Keep your foundation whole.

On the image. No screenshots or diagrams were captured during this week — the March-2026 product surface was a terminal dashboard with no saved images. The illustration here is a commit-stats stand-in, not a recreated UI, so nothing fabricated stands in for a March screenshot.

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