Technology
How it actually works, in depth — for developers and due diligence.
Where this is going: A sovereign, local-first system that is whole, honest, and verifiable on its own.
Build Your First NAOMS Package
NAOMS's own landing page says it plainly: packages, not client apps, are the primary way to build on NAOMS. A package is a folder with a manifest and (usually) a screen; the daemon discovers it on disk, no registration list to edit. This walkthrough scaffolds a minimal one with `naoms package init`, boots it inside a real, isolated daemon with zero hand edits, and opens its screen in a real browser — plus what an earlier draft of this exact tutorial got wrong before the scaffolder itself was fixed.
Price per bug, not price per token
If you are choosing a model to fix bugs automatically, compare what one finished job costs, not the price per token. We first measured six models with no way to run code at all; that measured the wrong thing, because a model that cannot run a test cannot follow our own bug-fixing procedure, and the owner ruled that round invalid. We redid the fixing question properly on the two cheapest candidates: give each a tool to reproduce the bug as a failing test, fix it, and prove the fix green. DeepSeek V4 Flash fixed all five bugs correctly for $0.042 a job; MiMo V2.6 Flash fixed three outright for $0.053. Requiring the real test run cost DeepSeek about 60% more per job than skipping it, and removed every failure on this small set. We also priced the same work on a Claude Max subscription instead of the API, and tried a bug fix on a local model on our own GPU: correct, but far too slow to call a candidate yet.
One file that says where everything lives
If you run NAOMS yourself, there is now one file — naoms.config.toml in your NAOMS home folder — that records where your vault, database, keys and other data live. NAOMS writes it on first start and reads it from then on, so a later release that changes a default location does not move your data. You can point a run at a different file with --config, or override a single value with --set. If the file is broken, NAOMS refuses to start and says why. The wider move away from environment variables is still in progress.
Weather and vows
If you build on NAOMS, each kind of event you define is declared as a vow or as weather. Vows are signed and stored, and can reach devices that were offline. Weather lives in memory and blows through. This week the owner wrote down exactly what weather is, as four conditions that must all hold. When 16 existing weather declarations were checked against them, 12 turned out to be vows. This piece is the test, with the examples that failed it.
Weather should not be written down
NAOMS keeps two kinds of state. The permanent record is signed and kept forever. Passing state, like presence or a live location, only matters right now. On one of our machines, a component meant for the passing kind had quietly been copying the whole searchable view of each space and rewriting records of tens of megabytes as changes came in, for a sync that failed on every attempt we found. The decision this day was that passing state is never written to the database at all.
The pipeline is the approval
In the NAOMS project's own repository, nobody clicks 'approve'. The pipeline records what ran and what each check found, never counts an unreadable verdict as a pass, and, before a fix is handed to the people waiting for it, refuses to let one person sign off two stages when someone else could have. This piece explains why that is a stronger record than a click, what is finished as of this week, and why the automatic release step still refuses on purpose.
Untrusted bug reports get a narrow role
When a bug report arrives that no one is working on yet, an AI agent reads it and decides where it belongs. That report was written by someone you don't know, so the agent reading it now runs under its own narrow role: beyond recording where the report belongs and asking for a worker to be woken, it can only search and read, and nothing on its permission list can edit a file or run a shell. A setup where it would have borrowed a much more powerful role was measured and removed on the same day.
Authority is what you hold now
When a group takes away someone's steward role, that person should lose the powers that came with it, right away. A fix written on 4 September made one of the group's emergency powers check the live credential; its final form, which reached the main line on 24 September, requires both that credential and the record of appointments. That form keeps an important asymmetry: revoking a steward removes their power to act, but does not lower the number of stewards who must agree.
Coding with more context than the machine has memory for
Coding with a model wants two things that both cost memory: a big context, and more than one session at a time. On a memory-bound machine you normally pick one. A small fork of llama.cpp and its launcher park the idle sessions on disk and read them back when you switch, so you can have both — and this is our thank-you to the person who wrote them.
Where your identity keys actually live
Your database, your recovery words and your password should be all you need to get your identity back. A sealed copy of the key material now lives in the database itself, and if the loose file beside it ever goes missing, the copy is restored before anything tries to use it. The original file is still written and is still the authority — nothing has been deleted, on purpose.
What "off the record" checks, and how often
We are building calls you can take off the record mid-conversation: every participant signs the switch, it lands on the shared record the call is bound to, and from that moment both the audio and the video recorder refuse every frame and name the rule that refused it. Until this landed the switch changed the record and the label but not the recorder. This is one repair inside an unfinished calling feature, and the half that deletes what was already captured is still not wired.
A Link That Resolves to Nobody's Server
Sharing something in most apps means minting a link that points at the company's server — click it and you ask that server, politely, for permission. NAOMS took a different path for sharing a hive. The link is naoms://share/hive/<id>?t=<token>, and the token is a signed invitation the recipient can verify entirely on their own device: the inviter's public key is derived from the invitation's own identifier, so there is no directory to consult and no server to phone. The link carries its own proof. This piece walks through the codec, the offline verify, and the deliberately loud refusal that stops a hollow join — and it is scrupulous about how far the feature reaches today: you can mint a signed link, and a recipient who is already a paired contact can accept it and join. The stranger-with-a-link case across the open internet is the next milestone, not a shipped one. We say which is which, plainly.
Two devices, no server in between
Write something in a shared space on your laptop and it should appear on your phone, with no server in between. That works by sending once on the private stream your paired devices share, and backing that send with two recovery lanes: a small, spaced, capped re-offer, and a catch-up pull the moment the two devices meet. Shared-space content had been getting the single send only. It now rides the recovery lanes too, and the re-offer is bounded so a retry can never become a storm.
How It Remembers, and How It Reviews Itself
Three deep internals landed this fortnight, and they rhyme. When a long-running assistant hits its context limit, it summarizes, signs a checkpoint, and only then frees memory — so history is appended, never rewritten. The merge pipeline runs on our own substrate, with a local model reasoning about each change and emitting the verdict — no outside CI service. And a request is compiled into a checked, executable plan that either grounds in real operations or refuses out loud. Underneath all three is the same rule: the system is not allowed to quietly lie to itself about its own state.
Your Machines Know What They Can Do
If you run NAOMS across more than one machine, your fleet now knows what each one can do. Every machine carries two kinds of capability record — one it figures out about itself and keeps fresh, and one you can declare by hand and sign. When there's a job to run, the fleet throws out every machine that can't do it and ranks the ones that can, so work goes where it fits. What it does not yet do is re-check a machine in the middle of a job.
Naming the format your machine writes
Your machine turns a picture into a PDF using a converter program installed on that same machine, and the command that runs it names the output format outright rather than leaving it to be guessed from a filename. That naming is what makes the bytes it writes agree with the type it reports.
The Inbox That Can't Quietly Lose a Conversation
Open the app and every conversation you're part of — the ones that stand on their own and the ones that belong to a community — is already sitting there in one list. Nothing behind the scenes keeps an inbox file up to date. Each time you look, your own device rebuilds the list by asking the signed record who you belong with. That design has a quiet superpower: it shows a conversation as soon as your own device holds the entry that says you joined it, and it can't hand you a stale list that silently forgot one.
Your Files Stay on Your Own Machines — No Cloud Ever Holds Them
Your files live on your own devices, encrypted, and never get uploaded to anyone's cloud. When you open a large one, the bytes arrive from all your trusted machines at once instead of one server carrying the whole load. And when you cut off someone's access, the app doesn't pretend it happened by magic — it tells you plainly what the cutoff does and does not do.
Proof your message arrived, at network speed
When your device needs proof that another person's device received something, it waits for a short receipt before deciding the message was lost. That receipt answers at network speed rather than at the speed of the work — and the cost, stated plainly, is that it tells you nothing about whether that work succeeded.
Consent You Can't Forge — Group Calls Where the Crypto Enforces the Rules
When several beings are on a call together, two facts have to be trustworthy: the room is sealed against outsiders, and everyone in it agreed to be there on the terms shown. NAOMS encrypts group calls with real MLS — the modern group standard behind secure messengers — and does one more thing most systems skip: it binds the group's current key epoch and the consent state directly into the signature over every single media frame. A peer can't quietly swap your consent stamp or replay an old-key frame without the bytes failing verification. This is wired and verified by code path today. Be clear-eyed about scope: the full multi-party video call over the network, at scale, is still being built — this is the crypto layer proven, not a finished "make a group call" product.
One Command, Three Platforms — and the Native-Library Gymnastics Underneath
NAOMS is one memory system — your local database, your cryptography, the signing engine, on-device speech, and optionally a language model that runs on your own hardware. From one command family we build it for Mac, Linux, or Android (or all of them at once), and on each platform the output is a self-contained, on-device daemon: no server in the middle, nothing phoning home to run. The genuinely interesting engineering is that the same shared Rust library links its native math and ML stack differently on every operating system, so packaging it self-contained needs a different trick per OS — a static-link on Mac, a full shared-library closure staged and re-verified on Linux, a cross-compile plus a bundled C++ runtime and 16 KB page alignment on Android. One pipeline, three platforms, three real daemons — but the FORM differs by maturity. Only the Mac build is a notarized, celebrated double-click app. Linux ships a self-contained daemon tarball today, not a polished desktop app. Android is shipped and running, but under an active hardening effort. We say which is which, plainly.
Your Google Drive and Gmail Imports Really Reach Your Data — and We Prove It Every Run
You hand an importer your real accounts — your Drive, your mail, your bank export — so the least it owes you is to still actually reach that data months later, not just the day it was written. In this window importing from real consumer accounts genuinely works: a signed-in Google Drive file becomes a real, searchable entry in your memory, including the quiet step of renewing the access token; the Gmail and Drive set is complete; and a public-data path now runs on a nightly schedule with no stored secrets. The deeper change is that a live cloud import is now fed back through the same core a local import uses, so it gets the same signature checks, the same privacy gate, and the same deduplication — and an automated check re-proves that live path on every run. This is as much a proof story as a feature. Some providers can't be safely automated and carry a written manual playbook instead, and the proof already caught one real gap.
Build on NAOMS Without a Copy of NAOMS
A software development kit is a promise: take our pieces, build your own thing, and don't inherit our whole world to do it. Here that means an outside developer with none of our code on disk can scaffold a package, sign it, publish it into a private space only they can see, and promote it into a shared one — every step driven by the installed command-line tool against a real running system. The step that crosses from private to shared is the one worth understanding: it is countersigned by the group, so admitting a package into common space is a fact on the record rather than a claim you take on faith. For most of this project's life that only worked from inside our own source tree; this week we closed that gap and proved it the hard way. We also name the one rough edge that's left, because a kit that hides its seams isn't finished.
Your Phone Finds the Photo — On-Device, by What's Actually In It
Pick a photo in your library and ask for more like it. On your own device — no cloud, nothing uploaded — a real vision model reads the picture and turns it into a fingerprint of 1024 numbers. "Find photos like this one" then becomes a true nearest-neighbor search in that space: the system finds the pictures whose fingerprints sit closest to your chosen one, blended with the words and things found inside the images themselves. Be clear about what works today: this is image-to-image. Show it a photo and it finds visually similar photos. You cannot yet type "beach" and have the vision model go find beach pictures — a typed word reaches your photos only through the text read out of them (captions, the letters inside the image, detected concepts, places). Typing a description and having the vision model match it is the honest next step, and it is not shipped. The model itself stays dormant until you install it through a signing ceremony; until then, search quietly falls back to text and tells you which results came from where.
Live Captions from a Model That Can't Stream
We're building live, on-device speech captions — the kind that scroll under you as you talk — and the hard part is that the speech model we run has no streaming mode at all. It decodes one fixed chunk of audio and forgets everything between calls. This is a builder's walkthrough of how we're turning that batch, stateless model into a running caption stream: a sliding window we own on our side, overlapping decodes stitched together, and a strict rule that the raw microphone audio is wiped the moment it's consumed. This path is in progress, not a finished feature — only the early rung, audio actually arriving at the tap, is owner-accepted. We'll be plain about what is real today and what is still being wired.
Every Messenger in One List, and None of Them in Disguise
NAOMS is learning to hold every messenger you use in one calm list — your native NAOMS conversations alongside threads bridged in from Telegram, Signal, WhatsApp and others. The rule that makes such a list trustworthy is that every message renders with its true origin attached, read straight from the message's own stored record and never invented: you see "via Telegram" because that is where it came from. This week we closed a gap where bridged threads opened empty, because the code that gathers a conversation's history stepped over them.
What You Share With the Group Doesn't Carry Your Name
In NAOMS, a group of people — a family, a team, a community — shares memories into a common, cryptographically verified history that replicates to every member's machine. Until recently, each contribution you made was permanently stamped with your root identity: the one identifier that ties together everything you are across the whole system. This week we shipped per-group pseudonymity: what you share into a group is attributed to a name that exists only inside that group. The other members' machines can verify your contribution is genuine — but nothing that reaches them contains your root identity, and nothing lets two groups compare notes and discover their members are the same person.
The Database Falls, and Nothing Spills
NAOMS keeps everything a being entrusts to it — memories, credentials, governance records — in one local database. Until this week that database was encrypted as a single block: one passphrase, all-or-nothing. Open it and every byte inside was readable; and any code running inside the unlocked process could read all of it, whether it had any business with that data or not. This week we shipped compartmentalized at-rest encryption: each kind of data is sealed under its own key, in its own compartment, with the sensitive fields encrypted individually while the structural fields stay in the clear so the system can still index and query. A stolen database file reveals nothing. A caller without a grant for a compartment gets a typed "encrypted, no key" marker — never the ciphertext, never a fabricated value, never a crash.
No Message Lands Until Its History Does
NAOMS stores everything as hash-linked records: each one names its parents by their content fingerprint, and a record cannot be applied until you already hold the record it points back to. When one arrives before its history, it waits — and the system has a single way to go and fetch what is missing: one question that asks for the whole chain of ancestors between what you hold and what you lack, across every branch, in an order you can apply straight down. Just as importantly, the parts it genuinely cannot reach — because it hit a limit, or because the other side simply does not have them — say so out loud rather than being dropped on the floor. Getting there meant replacing roughly a dozen half-overlapping mechanisms whose gaps used to leave records waiting forever.
The Governance Socket Is Back
Our AI agents don't reach NAOMS's rules and memory through a private back door. They use MCP, an open standard interface, and everything an agent does — booting, checking what it is permitted to do, calling a tool — travels that one wire. This piece explains what the wire carries: an entitlement gate on every tool call, a trust tier that decides how loudly you are asked to approve, a signed receipt that proves a human said yes, and a boot vocabulary that tells an agent how the lifecycle works. Then it walks the four places that had frayed, and how each was repaired.
Your Whole Memory System, in Your Pocket
An Android build now runs the real NAOMS daemon on the phone itself — in production governance mode, not a permissive sandbox, and not a thin client phoning home. The encrypted vault stays on the device, and its data encryption key is wrapped behind a hardware Keystore key that a fingerprint releases for exactly one unlock. This is the deep version of how that works, and the specific, unglamorous walls we hit getting there: an ECIES dead end on real hardware, a biometric prompt that silently never appeared, and an approval the on-device daemon couldn't even ask for.
A Mac That Trusts the App Before It Opens
Signing and notarizing a Mac app sound like one chore. They are two different things, and conflating them is why so many builds ship broken. One is a cryptographic seal that makes the build tamper-evident — change a byte, break the signature. The other is Apple scanning your build and stapling a verdict the OS checks at open. We wired both behind one command, and along the way hit the un-fun truth that `codesign --deep` silently refuses to sign the binaries that matter most, and that "it boots fine" can mean nothing more than "this machine happened to have Homebrew installed."
Where You Run a Local Model Matters as Much as Which Model
Running an assistant on your own machine means choosing a model file and, separately, the runtime program that loads and runs it. Both choices affect whether the assistant actually takes the action you asked for instead of merely describing it. We measured that gap, and we now hand the model exactly one tool on the first turn so the decisive first action lands the same way on every runtime we tested it on — four of them, at 100%.
Declare what a record's origin stamp reveals
You can now declare what a record's origin stamp may reveal, instead of hoping the code that writes it remembers. Declare a record kind private and the engine that files it writes no signer onto it; declare nothing, and the same engine still withholds the signer from a record carrying one of three known-dangerous markers.
A Repo Too Big for the Old Limit Now Streams Straight In
You can push a git repository into your own NAOMS storage, and however big it is it goes in chunk by chunk rather than as one giant message — sealed at the end with a hash that names exactly what arrived. We proved it with a real 80 MB push, and it's signed off.
Build On a Data Layer Where There's No Second Copy to Reconcile
If you build on NAOMS, your reads now come from exactly one place. This week we migrated the last legacy memory and identity tables onto the single signed record everything else already uses, deleted the originals, and added a guard so they can't come back — removing a whole class of "which copy is right?" bug from under your feet.
We Deleted the Last Place Your Data Could Quietly Drift
Your memories and identity no longer live in old side-tables that could fall out of step with the truth. This week we migrated the last of them onto the single signed record everything else already uses — and deleted the originals.
Changing Your Key Without Invalidating Your Past
Replacing the key that signs your history should not cast doubt on everything you already signed with it. This is how the boundary marker that keeps your past valid works, what happens when that marker is filled in with a placeholder instead of a fact, and the tempting repair we wrote up and then declined to ship because it was unsound.
Installing Code You Didn't Write, Safely
Installing a plugin means running code you didn't write, on your machine, with your data — and an app store asks you to just trust it. You can install safely here without trusting a marketplace at all: your own chain authorizes the plugin, and a signed proof of exactly what it contains is checked, on your machine, every single boot.
What recrypt gave us that we did not build
The encryption that lets you share data without ever exposing it is now the real thing on your devices, not a stand-in — and it compiles cleanly on desktop, Android, and iOS. We spent the week swapping out a placeholder that had been quietly passing every test, and that swap is the milestone.
Access You Earn: When the Trust Graph Rewards Contribution
Most systems let you in by checking who you are. We're building toward something different: access you earn by what you've actually done — standing recorded in a trust graph, not a score on someone's server. Here's what's genuinely shipped (the trust graph itself) and the honest gap to what's still only designed (contribution tracking and the gate that would turn standing into access).
Empty Fixtures Hide More Bugs Than They Catch
If you build on NAOMS, you can now run one command and fill any package with realistic, production-shaped data — so the bugs that only show up at real scale surface in testing instead of in front of a user. We shipped this week: `naoms dataset seed <profile>` pours that data in at the lowest layer and the whole stack lights up like production on demand.
A Main-Loop Hang Should Be Unbuildable
The scariest way software fails is the silent freeze — still "running," still answering health checks, but doing nothing while everything queues behind it forever. We're working toward making that freeze impossible to even build into the daemon. This week shipped two real slices of that goal, not the finished guarantee.
Your Files Arrive From Everywhere at Once
Open a big file and it streams in from every trusted device that has it at once — verified piece by piece, never dragged through the chat layer, and never fetched until the moment you actually ask for it.
What Happens When the AI Agent Just Ignores the Rule?
An AI agent can forget, mis-state, or try to route around a check — so NAOMS trusts the agent only where it alone knows its intent, and enforces every other rule on the server whether the agent cooperates or not. Two layers, five levels of seriousness, and an honest answer to 'what if the agent ignores the rule?'
What your vault password becomes
You type a password and your vault opens. That pause is not slowness — it is a deliberately expensive calculation, and the same expense is what a machine guessing your password has to pay again for every guess it gets to check.
Hunting the gaps a green suite hides
A test going green doesn't mean the work is done — it can pass right over a gap nobody pointed a test at. You can run a deliberately adversarial 'test-critic' pass that assumes your suite is hiding something and goes looking for it.
Share a Slice of Your Chain — and Have That Boundary Actually Hold
You can hand a peer one branch or a subset of files from your chain and trust that they get exactly that — no more. The boundary is enforced at the moment the bytes leave, default-deny, so it can't be routed around.
Outgoing, Not Incoming: Where the PII Gate Belongs
A gate that keeps personal data out of shared files belongs at the exit, not the entrance: it inspects the artifact in its final form, right before it leaves, and it knows exactly which identifiers are sensitive and which are public by design. Two lessons that generalize well past test data.
One Noun, One Verb: Cleaning Up the naoms CLI
When a CLI grows to ~75 flat commands, every one you can't predict is one you have to look up. Here's how we collapsed ours into 44 noun-verb families — so you learn a handful of nouns and guess the verbs — kept every old command working, and proved it with a 508-entry sweep. The three moves transfer to any tool you maintain.
A Daemon That Never Blocks Itself
The local process every client talks to runs on a single cooperative loop, and it holds one promise: when it is slow, it is the machine that is busy, never the process fighting itself. Here is how that promise is stated, what it takes to keep, and the management channel that stays reachable either way.
Many Kinds of Chain, One Engine
Your personal record, your vault of secrets, a group, a friendship, a shared repository — they look like very different things. They turned out to be one append-only signed chain, configured differently for each. The payoff: a feature built for the chain is built for every chain, once, correct everywhere.
When the Axioms Got Teeth: Wholeness as a Checker Gate
A principle you only write in a doc is a suggestion you make to your future self. This is the week one of ours became a gate that fails the build — and the three commits that show the hard part isn't building the gate, it's handling the gate being wrong.
From Memory Packs to Aqua: Making Our Data Provable
When you package up a slice of your knowledge to back up or hand to someone, they shouldn't have to trust our format to check it's genuine. So anything that leaves your device now leaves in a format anyone can verify on their own — a change a friend who builds that format pushed us toward. Here's the story of what we kept, what we added, and what we gave back.
Deleting 8,300 Lines: When AGENTS.md Became Policy
We deleted ~8,300 lines of bespoke rule code and lost nothing — because 142 rules an agent must follow stopped being little programs and became readable definitions a single engine reads. The line count is just how you notice the rules became something you can audit.
Benchmarking When the Answer Isn't a Number
Some of the most important things a system does — did it recall the right memory, is this summary faithful, did it answer the actual question — have no numeric answer. Here's how to score them automatically with another model as the judge, where to still pin plain code, and how far you can trust a model grading a model.
One Screen to Find and Enroll Every Role
Instead of hunting across a different screen for every kind of role, you get one place to see what roles you could take, take them, check what you hold, and hand them back — because finding a role and enrolling in it are really one task.
The Agent Can't Skip the Rules — Even If It Wanted To
The rules that govern our AI facilitator aren't advice it's trusted to remember — they're a gate it has to pass before it can act at all. Skip the check, and its hands stay locked. So 'follow the rules' stops being a hope and becomes something the system enforces mechanically, every single move.
Don't Write an Integration Test — Use One
When an end-to-end test fails and you can't tell where, you don't have to build a new probe under pressure. You can take the integration tests already on the bench and run them as a microscope — descend the ladder until one goes red, then read what it prints. Here's the method, in fourteen words.
A Forged Message Can't Reach Your Group
Messages spread between members with no central server, the way a rumor moves through a room — so anyone could try to slip in a forgery. You're protected because a message earns nothing by simply arriving: it has to pass five checks, in order, before it can change a single thing you see.
Why We Don't Defer: The Rule Born This Week
Deferral feels like planning and reads like progress, which is exactly why it's dangerous. This week a single owner directive turned 'we'll get to it later' from a habit into a rule. Here's the rule, why it exists, and how to apply it yourself.
An API Key the Daemon Forgets Between Requests
A cloud provider's API key is a secret. The usual mistake is to read it once at startup and hold it in memory for the life of the process. We don't. The key lives in the vault, gets fetched the instant a request needs it, and is never kept as process state — and the whole provider surface stays hidden while the vault is locked.
The Difference Between a Tool You Open and a Tool You Live In
A terminal app you visit is one thing. A terminal app you live in is another. Here is what the second one actually demands — an attention queue, honest status, and a model picker that refuses to lie about what a tool can do.
A Self That Has to Wake Up Before It Can Act
When your identity is just sitting there on disk, it is asleep — encrypted, inert, unable to do anything. The program that runs your identity literally cannot sign on your behalf until you prove you are present: a face, a touch, a passcode. Awakening is not a formality the system performs; it is a gate only a real human can open. Here is what 'asleep' actually means, why waking requires consent, and what stays locked until you do.
One Authoritative Answer to 'Who Consented to What About Me?'
'Who has consented to what about me?' should have one authoritative answer in one place — not something you reconstruct by scanning every actor's permissions. This is the model that made consent a single, signed, per-subject fact with a real lifecycle, and why routing every grant and revoke through one door is what keeps it honest over years.
One Door for Every Model You Run
Local model runners and cloud providers each speak their own dialect. We put one abstraction in front of all of them, and a router that picks a backend by what you're trying to do and what your hardware can take — so the rest of the system never has to know which engine answered.
Why Secure Group Chat Deserves Its Own Home
Durable one-to-one chat shipped this week; secure group chat got set aside as its own line of work. Here's why group messaging deserves its own home rather than being grafted onto a chat feature — and what 'MLS-like' is reaching for, honestly flagged as a direction, not yet an implementation.
Plan With the Big Model, Work With the Local One
A capable cloud model is good at planning and delegating. A small model on your own machine is good enough to do most of the actual work — and it runs offline, for free, under your control. So we split the roles: the cloud model facilitates, local models do the labor, and 'use local first' is a rule, not a preference.
Don't Give an AI a Weaker Copy of Your Controls — Give It the Real Ones
Most AI assistants are bolted on: the model hands you text and you do the work. Here we did the opposite — exposed the daemon's actual controls over a standard protocol so a capable model can plan, delegate, and act through the same governed, signed tools you do, with a dozen sessions sharing one daemon and each keeping its own identity in the record.
Why Gossip Must Never Move Your Big Files
Gossip protocols are the wrong pipe for a video stream or a photo bundle, and the reason is structural, not a tuning problem. Here is what gossip is for, what content-addressed transfer is for, and why confusing the two melts your mesh.
Three Kinds of Sync, One Engine Underneath
Three very different relationships need to stay in sync: the devices you own, the people you know, and the groups you belong to. It would be tempting to build three systems. We built one engine and gave it three faces. Here is why those three faces must never be confused — and what the single engine underneath actually does.
When a Group Becomes an Authority
A group of people who already trust each other is exactly the kind of thing that can credibly vouch — 'this member holds a valid credential,' 'this service is supported here.' This is the story of the design that turned a hive into an issuer: one conversation, one load-bearing decision, and the on-chain machinery it shipped with.
The Kernel Is the Brain, the Plugins Are the Senses
Every feature in NAOMS — even the one that installs other features — plugs into a small core the same way, and each can only touch what it declared up front. You get a system you can audit before you trust: read a feature's manifest and you know exactly what it can do, because the runtime won't let it do more. This is a tour of that architecture and the philosophy it encodes.
One Locked Room for the Whole Call, Not One Per Pair
When several people join one encrypted call, there is exactly one locked room for the whole call, and exactly one host who opens it and lets everyone in. Here is why that has to be the shape — grounded in the invitation fan-out that shipped 2026-04-21 and the single-owner rule that followed.
Browser-to-Browser Calls, No Server in the Middle
We're building voice and video calls that go straight from your browser to theirs, with no media server in the middle that could see who you talk to and when. This piece lays out the design as we set it down; the pieces are landing, and we flag exactly what's shipped and what's still on the way.
No Single Key
Your private key is the one thing that, if stolen, lets someone act as you. We split it so no single copy can ever sign alone — it takes a quorum of your devices to approve the most identity-critical actions. Here's how it works, what ships today, and what's honestly still in test.
Proving Who You Are to a Program on Your Own Machine — With No Shared Password
Two programs on your one machine don't automatically trust each other — and they shouldn't, because your keys and memory are at stake. Here's how the terminal client proves it's really you to the local node, without any password ever crossing the connection.
What `naoms check` Actually Checks: A Tour of the Ratchet
Every time a mistake bites us, we teach our checker to catch the whole class of it so it can never come back silently. Here's a plain tour of how that works, and how one April day added a rule that closed a bug for good.
Teaching a Checker to Fix Its Own Findings
Our checker stopped just pointing at problems and started fixing the boring ones itself — so the tooling does the work twice over instead of you. Here's how it draws the line between a fix a machine should make and one only a person should.
One Door In
Every change to your data is a signed entry in an append-only log, and the picture you see is derived from that log by replaying it. Routing every change through that one audited door is what gives it a receipt — here is how it works, and the week we shut the side window that let writes skip it.
The Pack Arrives: Moving Real Code Between Two Machines That Trust No Wire
Code can travel directly between two machines with no server in the middle, arrive provably unaltered, and still be refused to anyone without the right to read it. Here's the first time we pushed a git repo peer-to-peer that way — and why a refused read counted as success.
How to Download a File You Can Actually Trust
Learn the one idea that makes a downloaded file trustworthy no matter who sent it: name it by its content, then re-check it on arrival. We walk it through with a real peer-to-peer model download. (How it worked in April 2026.)
One Credential Pattern to Wire Them All
Who's allowed to do what is messy in most systems — a new permission list for every feature. We built one signed, portable credential instead: any feature can declare it, your community grants it, and anyone can check it. Here's the design, and the one part that's still partial.
Ship a New Kind of Record Without Writing Code to Store It
You used to have to write code teaching the database how to store each new kind of entry. Now the entry describes itself, one general engine files all of them, and the code that knew about every kind of thing is gone.
The Green Check Nobody Owns
Most "verified" badges just mean a company decided to vouch for you. Here's a green check with no owner: a group of independent peers checks one fact about you, co-signs a credential anyone can verify, and learns as little about you as possible doing it.
Why Your Data Model Shouldn't Be a Silo
Communities won't have to keep reinventing the same data shapes in a hundred incompatible silos. We're building a way for one community to find, verify, and deliberately adopt the data models another has published — with the governance to do it safely. It's in active development, not yet finished.
Prove You're Over 18 Without Showing Your Birthday
We're building a way to prove a single fact about yourself — "over 18", "owns this handle" — while revealing nothing else and never phoning home to whoever issued the credential. Here's the architecture and the ethics guardrails, and an honest note that the first phase stands in a simulation for the real math.
When Tests Aren't Allowed to Lie
A skipped test that still shows green is lying to you. Here's the one-line rule you can copy into any project so a test fails loudly when the thing it depends on quietly goes missing.
One Source of Truth, No Second Database to Drift From
Your data now lives in exactly one place that can't quietly disagree with itself. We deleted two separate databases' worth of habits — Neo4j and 879 scattered raw queries — and made the one signed record of truth answer every query directly, with guardrails so the old habits can't creep back.
One Endpoint to Rule Them All
Every message between your devices comes through a single authenticated door, and a message that is not a sealed, signed envelope is not carried at all. Here is how that transport works, how it replaced four separate doors that had grown up alongside each other, and the one test we shipped still failing — on the record.
Share a Memory by Wrapping a Key — Not Re-Encrypting a Single Byte
When you share a private memory, sharing is instant and your data never gets copied or re-encrypted — we wrap one tiny key for the person you're letting in. The payoff: even a fully stolen database reveals nothing, because the keys that open it were never stored there.
No by Default: How Four Independent Gates Decide Who Sees Your Data
In NAOMS, nothing is shared unless a signed, audit-logged grant says yes. Your data starts out reachable by no one. To see anything, someone has to clear four independent checks — and any one of them can say no, and any one can be pulled back later. Every yes and no is written to a tamper-evident log. Here's how "no by default" stops being a slogan and becomes a data structure.
Trust Lives on the Edge, Not the Person: Building a Graph That Can't Be Gamed
Nobody can claim you trust them without your signature, and no single number can be farmed to fake your reputation. Here's how we model trust as directional, two-signed relationships between people instead of a score — the edge shape, the consent rule, the friend-count cap, and the early work that lets two separate instances draw their first edge between strangers.
Memory That Only You Can Read: Encryption That Travels With Each Thought
Here's what protects your memories: each one is locked individually with a key only you can derive, and it carries everything needed to unlock it even with no service running. That per-memory choice is also what lets you share a single thought without exposing your whole database. The deep dive walks through how.
One Being, One Vote: Proof of Unique Being Without a Gatekeeper
How do you keep one person from minting a thousand fake identities when nobody is the gatekeeper? We walk you through the design we worked out — math on the social graph, humans vouching for humans, and the one defense that can't be faked: time. Note this is our thinking on paper, not yet running code.
Trust Is Directional: The Relational Trust Graph
Most apps reduce trust to one number stamped on a person. NAOMS doesn't — here, how much you trust Alice is your relationship with Alice, which has nothing to do with how much she trusts you. See why that single choice changes how trust spreads, how it's queried, and why it fades if you don't tend it.
Why Your Data Can Always Be Rebuilt From Scratch
Here's a quiet superpower: everything you see on screen can be thrown away and rebuilt perfectly from one honest record. NAOMS never writes to the thing you read from — writes go to an append-only log, and the screen is rebuilt from it. That's why it can't quietly lie to itself.
The River Remembers: Building a Workflow Engine That Survives a Crash
What happens to a half-finished agreement between two people (or an agent and a person) when the machine crashes? In NAOMS's March-2026 workflow engine, nothing is lost — the river remembers where it was and picks back up. Here's how we made the position durable.
One Idea Under Everything
Want the one idea that makes NAOMS able to prove what it claims? Every change — your identity, a permission, joining a group — is a signed record, chained to the one before it so nobody can quietly rewrite the past. This is the foundation everything else rests on.
Sync, Don't Replace: Reading NextGraph
Curious how we decide what to borrow from other projects? Here we spend a day reading NextGraph — an encrypted, decentralized sync engine — very closely, and land on a four-word rule: sync, don't replace. You'll see what we kept, and the one place we chose differently.
Why We Adopt Protocols and Skip Blockchains
Wondering whether NAOMS is 'a blockchain'? It isn't. We keep the parts that make your history tamper-evident — signatures and hash-linked chains — and skip the global ledger everyone has to agree on. Your records answer to you, not to a network vote.