@kinedb/kdmem (0.1.6)
Installation
@kinedb:registry=https://git.kinedb.com/api/packages/kinedb/npm/npm install @kinedb/kdmem@0.1.6"@kinedb/kdmem": "0.1.6"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.6/kdmem-0.1.6.tgz kdmem --user allan@kinedb.com --company kinedb
Use your own address after --user and your company after --company. The number 0.1.6 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.6 is published. The command of 0.1.5 is checked on Linux, macOS and Windows. NOT YET
checked for 0.1.6: the full command on macOS and Windows. 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. A change of the mod code itself needs the install command once more.
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).