One word for each thing, defined once.
The site, the docs and the code use the same words. Here is every one of them in five groups, with a link to the page where it does its work.
What a brain is made of.
Four words, and every other term on this page is about one of them.
- brain
The canonical store one account owns: every node, in both areas, served to the sync client over HTTP and to agents over MCP.
on /brain- node
One unit of memory: a path, a body in markdown, and a version vector. The first heading is its title.
on /brain- scope
The group a page belongs to. In the secure area a scope has a key, and a device holding it reads that scope and nothing else. In the open area a scope does not narrow who reads.
on /brain- cockpit
The workspace at my.instibrain.ai where a person sees the brain: the tree, every page, the review queue, and the log of which agent read or wrote what.
on /brain- inbox
The one page every brain ships with, inbox.md. A line, a photo or half a thought goes in from any device, and leaves only by becoming a real page or by deletion.
on /brain- surface
Anywhere an agent or a person reaches a brain from: a laptop running the sync client, Claude or ChatGPT on the web or on a phone.
on the landing page
Who can read a page.
Readability is a per-page setting, and the secure area is what the keys are for.
- open area
The part of a brain our server reads. Pages are stored as markdown, so an agent holding no key can reach them.
on the landing page- secure area
The part of a brain our server cannot read. A page is encrypted on your device before it leaves, path included, and only a device holding the scope key opens it.
on the landing page- key_id
The name of the key a node is encrypted under, or none for an open-area node. A name for a key, never a key.
on /how-it-works- scope key
A random 256-bit key, one per secure-area scope, wrapped once for each device admitted to it.
on /security- node key
The key one node is encrypted under, derived from the scope key, the node id and the epoch. No node has a secret of its own.
on /security- device key
The keypairs a device generates for itself: X25519 with ML-KEM-768 to receive wraps, and Ed25519 to sign membership. The private halves stay in the device's own keystore.
on /security- wrap
A key encrypted for one device's public key. The server stores wraps of scope keys and cannot open any of them.
on /security- epoch
The generation of a scope key that a node key is derived from. Rolling the key starts a new epoch, and every node it covers moves on its next write.
on /security- recovery bundle
One file holding a device's keys, sealed under a passphrase with Argon2id. You keep it off the machine it came from.
on /faq- membership chain
The append-only, signed log of which devices may read a scope. Each entry carries the scope key wrapped for that device, and the sync client verifies the chain from its first entry.
on /security- the Blind Vault
The name of the encryption design behind the secure area. It names the design and nothing else, never a place a page is put.
on /security
Between a file and a node.
What the sync client does on your device, and what it leaves behind.
- sync client
The part of instibrain that runs on your device. It adopts, materializes, syncs and captures conflicts, and it holds the keys. Its command is instibrain.
on /device- adopt
What the sync client does with a markdown file that has no id yet: it asks the brain for a new node id, writes the short header into the file, and pushes it.
on /device- materialize
Turning nodes into local files. The sync client materializes every node your keys open as plain markdown.
on the landing page- cursor
Where a reader left off: a stamp and the last id seen at it. A pull asks for everything after the cursor.
on /how-it-works- tombstone
What a deleted node leaves behind. The row stays and its content goes, so the next pull tells every device the node was deleted.
on /how-it-works- conflict file
When a push returns 409, the sync client writes the server's version beside yours as a .conflict.md file and overwrites nothing. You merge the two, then run instibrain resolve.
on /device
One decision, made in arithmetic.
The server's only judgement on a sync write, and the vocabulary it uses.
- version vector
One counter per writer that has edited a node: a device in the secure area, a credential in the open area. Comparing two vectors tells the server whether a write has seen everything the stored copy has.
on /how-it-works- bump
Adding one to your own device's counter in a version vector, which records one local edit.
on /how-it-works- join
The least upper bound of two version vectors, counter by counter. The vector a merged node carries.
on /how-it-works- dominates
Vector a dominates b when every counter in a is at least b's and one is strictly greater. The one rule the server applies to a sync write.
on /how-it-works- 409
The answer to a sync write whose version vector does not dominate the stored one. It carries the server's vector, so your device can merge. The server never merges a page itself.
on /how-it-works
The AI you bring.
How an agent connects, and what it is allowed to do.
- agent
Your own AI: Claude Code, Codex, Cursor, ChatGPT, or a bot you built. Several can read one brain at once. It is never ours, and sync never waits on it.
on /agent- MCP
The Model Context Protocol. The brain speaks it over Streamable HTTP, so any MCP client reads a brain with no SDK or plugin.
on /agent- brain.read, brain.write
The two permissions a connected agent can hold. Reading is granted at sign-in; writing is a second approval. A third, brain.sync, is never granted to a hosted agent.
on /agent