@kinedb/kdmem (0.1.8)
Installation
@kinedb:registry=https://git.kinedb.com/api/packages/kinedb/npm/npm install @kinedb/kdmem@0.1.8"@kinedb/kdmem": "0.1.8"About this package
kdmem: the shared live memory of a team
One central kinedb server (kdmem.kinedb.com) holds the shared state. A daemon on each machine
publishes the state of its Claude sessions. A web page shows all machines and branches.
Install
kdmem is published on the kinedb package registry, never on npmjs (browse: https://git.kinedb.com/kinedb/-/packages). Reading it needs no login. Run this ONE command on each machine. It makes the device key, installs the mod and starts the daemon:
bunx --package https://git.kinedb.com/api/packages/kinedb/npm/%40kinedb%2Fkdmem/-/0.1.8/kdmem-0.1.8.tgz kdmem --user allan@kinedb.com --company kinedb
Use your own address after --user and your company after --company. The number 0.1.8 is the
latest version; the package page names the newest one.
The command asks the server whether the company exists. A company that exists waits for an admin to add the
device, and the device pins the root key of the company. A new company is made by the command itself when the
server allows it (KDMEM_SELF_SERVICE=1; off on kdmem.kinedb.com): the user becomes the first admin, and the
key of the device becomes the root key of the company.
Status: @kinedb/kdmem 0.1.8 is published. The command of 0.1.5 is checked on Linux, macOS and Windows. NOT YET
checked for 0.1.6 to 0.1.8: the full command on macOS and Windows. 0.1.8 adds the messages between sessions, the mod from the
database and the self reload of running sessions (B14); the install of 0.1.8 is NOT YET run on a clean machine. The signup, the lists of signers and the company layer
are checked against the live server by the probe q14-signup-e2e.ts.
What starts the daemon
No operating system service starts it. The install command starts it once. After a restart, the
first Claude session that starts runs the mod hook: it reads the heartbeat file of the daemon
(~/.config/kdmem/heartbeat.json). A live daemon gives no command at all. A stale heartbeat (2
minutes) makes the hook run <daemon file> --ensure once, and that call starts the daemon
detached. One start in a minute at most. The daemon replaces its own code from the signed database.
The daemon does not poll for it: a WATCH on the table kd_assets wakes it when a skill or the code
changes (a safety pull every 5 minutes stays; without a working watch it pulls every 30 seconds).
The mod is a thin shell. A mod cannot evaluate script text (probe 2026-10-18: new Function and eval
fail with "Code generation from strings disallowed"), so it cannot load a script file. Its numbers
(the stale limit, the gap between starts, the check interval) come from ~/.config/kdmem/mod-config.json,
which the daemon writes at its start. A new daemon bundle from the database changes them with no
reinstall of the mod. The mod code itself also comes from the database (B14): bun daemon/assets-cli.ts <env> mod publishes the hooks and the
plugin.json as signed rows mod/.... A mod can load only files inside its own plugin folder, so the daemon writes a marketplace
folder of its own (~/.config/kdmem/mod-market) and runs claude plugin marketplace add|update and claude plugin install|update.
A running session reloads by itself: after each pull the daemon writes ~/.config/kdmem/reload.json ({ mod, skills }). The mod reads
the file every 5 seconds. A changed value makes the mod run the commands reload-plugins or reload-skills ($.command.run, the name
has no slash). Only a session that started before this feature needs one restart.
Messages between Claude sessions (B14)
The mod gives each Claude session two tools: peers (the other sessions) and send (a message to a session by name or session id).
A message reaches an idle session: the mod wakes it with a new turn that names the sender and says that it is not the user.
- One computer. The mod writes
~/.config/kdmem/msg/outbox/<id>.json. The daemon routes it intomsg/inbox/<session>/. The mod reads the inbox every 2 seconds and writes an.ackfile. - Two computers of one user. Put
"messageTable": "kd_messages"into~/.config/kdmem/device.json. The daemon then sends a message for another computer as a row of the table and delivers the rows for this computer. A message that cannot be delivered comes back as a message fromkdmemwith the reason. Without this setting the daemon sends nothing over the network. A message never crosses to another user: the server limits the rows byowner, and the daemon checks the owner again. A message row is NOT signed. - The table. Make it once, as root (
daemon/messages-remote.tsnames the columns):kd_messageswithmkey(key),owner,from_machine,from_session,from_name,to_machine,to_session,body,at,delivery,note, andGRANT INSERT, UPDATE, DELETE, SELECT ... TO MATCH owner. The server refusestextandstatusas column names. - The page. The fleet page has a Messages view: all messages, grouped by session, computer, project or user. Each session row shows how many it sent and received, with a button to its messages.
This folder is NOT copied into a project by setup.ts. It is the product, and it lives here
so that the kinedb repository stays free of it.
| Path | What it is |
|---|---|
daemon/ |
The publisher (agents-publish.ts), the device key and login (setup.ts, device.ts), the signed delivery of skills and code (assets-*.ts, release-sign.ts, code-update.ts), the company admin (company-*.ts). bun test kdmem/daemon/ runs its tests. |
mod/ |
The kdmem-usage mod. claude plugin test kdmem/mod runs its tests. |
.claude-plugin/marketplace.json |
The marketplace that offers the mod. |
skills/ |
The skills that the database delivers to every machine (/fleet-setup). Publish with bun daemon/assets-cli.ts <env-file> publish kdmem skills/fleet-setup. |
site/ |
The fleet page and the admin page. sh deploy-site.sh deploys them. |
deploy-*.sh, provision-server.sh, Caddyfile |
The server side. |
q*.ts, q*.sh |
Probes and end-to-end checks from the design phase. |
DESIGN.md |
The design. |
The daemon and the skills of a machine come from the database, signed with an ed25519 release
key. They never come from a git pull. The private key stays on the owner machine
(~/.config/kdmem/release.key.pem).