KineDB Labs
https://kinedb.com
Repositories Projects Packages Members
1

@kinedb/kdmem (0.1.9)

Published 2026-10-18 12:04:27 +00:00 by skadefro

Installation

@kinedb:registry=https://git.kinedb.com/api/packages/kinedb/npm/
npm install @kinedb/kdmem@0.1.9
"@kinedb/kdmem": "0.1.9"

About this package

kdmem: the shared live memory of a team. One command sets up a machine.

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.9/kdmem-0.1.9.tgz kdmem --user allan@kinedb.com --company kinedb

Use your own address after --user and your company after --company. The number 0.1.9 is the latest version; the package page names the newest one.

The command asks the server whether the company exists. A company that exists adds a NEW person by itself (B14): the server makes the user, adds it to the company and attaches the key of the device, so nobody approves anything and the setup ends with state: APPROVED. The device pins the root key of the company. The e-mail address is NOT proven: anyone who knows the company name can join. The operator turns this off with KDMEM_AUTO_JOIN=0. An address that already exists is never joined this way, because a key must not go onto an existing account. An admin of the company adds that device on /manage (Devices tab). 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.9 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.9: the full command on macOS and Windows. 0.1.8 added the messages between sessions, the mod from the database and the self reload of running sessions (B14). 0.1.9 adds the join of a new person with no admin step; the install of 0.1.9 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). It gives a third tool, context: it tells Claude the tokens used, the window size, the percent and the tokens left. Claude cannot see this itself. 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 into msg/inbox/<session>/. The mod reads the inbox every 2 seconds and writes an .ack file.
  • 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 from kdmem with the reason. Without this setting the daemon sends nothing over the network. A message never crosses to another user: the server limits the rows by owner, and the daemon checks the owner again. A message row is NOT signed.
  • The table. Make it once, as root (daemon/messages-remote.ts names the columns): kd_messages with mkey (key), owner, from_machine, from_session, from_name, to_machine, to_session, body, at, delivery, note, and GRANT INSERT, UPDATE, DELETE, SELECT ... TO MATCH owner. The server refuses text and status as 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.

Files that sessions edit (B14)

The mod records each file that a session edits (the tools Edit, Write, MultiEdit and NotebookEdit) as a claim. A claim is live for 30 minutes after the last edit. The daemon sends the claims to the table fleet_files and gives the claims of all computers of the user back to the mod.

  • A read or a search. When Claude reads a file, or runs a Bash, Grep or Glob call that names a file that another live session edited, the mod adds a note after the result. The note names the session and the computer, and tells Claude to use the send tool. A function is not tracked: only a file.
  • An edit. The first edit of such a file is refused. The refusal gives the same note. The same edit again passes: Claude has then agreed with the other session, or it has decided to go on. The mod never blocks twice.
  • The same file. Two claims are the same file when the path is equal, or when the repository and the path under its root are equal (another computer, or a worktree).
  • The files. ~/.config/kdmem/files/<session>.json (the mod writes it) and files-all.json (the daemon writes it).
  • The table. bun daemon/setup-fleet.ts makes fleet_files (the columns are in that file) and the grants, as it does for the other two.
  • The page. The fleet page has a Files view, grouped by session, computer, project or user. A file that two sessions edit has a shared with N chip. A user who sees more than one company gets a list in the top bar to pick the company to watch.
  • Companies. fleet_files is a fleet table: it has the columns company and dept, and a company reads and writes only its own rows.

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).

Details
npm
2026-10-18 12:04:27 +00:00
3
UNLICENSED
91 KiB
Assets (1)
kdmem-0.1.9.tgz 91 KiB
Versions (14) View all
0.1.13 2026-10-23
0.1.12 2026-10-23
0.1.11 2026-10-18
0.1.10 2026-10-18
0.1.9 2026-10-18