dsh-history-keeper
Your DeepSeek Harness history comes back — and you can prove it.
Español: README-es.md
Status: pre-alpha (0.1.0 in progress). The engine works:
snapshot,verifyandrestorerun on real DSH logs, validated byte for byte on 8 sessions. Host plugin integration and live sync are the next milestones.
The problem
Your conversations live in one place: ~/.dsh/sessions on a single machine. If that
machine dies, they die with it. There is no copy of why it happened — and no way to
prove the copy you do have is intact.
dsh-history-keeper exists to fix that: capture the history, encrypt it, verify it, and
restore it — byte for byte.
What it will do
| Milestone | Delivers |
|---|---|
| 0.1 | snapshot, verify and restore from a shared folder, with the CLI working without DSH running |
| 1.0 | live sync between machines, per-device manifests, explicit conflict handling, device pairing and revocation |
Try it now (from a checkout)
The CLI needs nothing but Node — no DSH, no git, no external binaries.
export KEEPER_PASSPHRASE='a passphrase of at least 8 characters'
node bin/keeper.js init --store ./vault
node bin/keeper.js snapshot --store ./vault --home ~/.dsh
node bin/keeper.js verify --store ./vault
node bin/keeper.js restore --store ./vault --home /tmp/restored-home
restore reproduces the host's own layout under sessions/, verifies every hash, and
never overwrites an existing log.
Use it inside DSH
Install the bundle, then point the row at your vault in the profile patch:
- insert:
- id: history-keeper
name: dsh-history-keeper
config:
store: C:\Users\you\keeper-vault # required
sessionsRoot: C:\Users\you\.dsh\sessions # optional; defaults to ~/.dsh/sessions
autoSnapshotOnFlush: true # capture after each closed turn
debounceMs: 2000
The passphrase is never written into the patch: export KEEPER_PASSPHRASE (or set
passphraseFile). Then, in a conversation:
/keeper status what the vault holds, what is pending, what this machine is missing
/keeper snapshot capture new session bytes now
/keeper verify check every object, hash and chain
/keeper help
restore is deliberately not available from inside DSH: it writes the live session
store, and a running host would not notice. It stays a CLI operation, with DSH closed —
that is the whole point of a recovery tool.
Minimal setup
Every key is optional. With no config at all, the plugin looks for a store at
~/.dsh/history-keeper, reads sessions from ~/.dsh/sessions, and tells you how to
create the store when it is missing.
Timestamps are stored in UTC (an instant must be unambiguous across machines) and rendered in your local time zone next to the offset.
Design principles
- No external binaries.
node:only — nogit, noage, nothing to install. - Fail closed. No key, no sync. A conflict never writes. Encryption never degrades to plaintext.
- Never overwrite, never delete. Restore only creates; anything that already exists and differs is set aside.
- Append-only and verifiable. Every object is immutable and named by content; the chunk chain lets anyone audit integrity, even without the key.
- Copies per device, never a shared mutable file.
- The transport is dumb. A folder (or any provider) only moves blobs: it never parses, orders or merges.
- Auditable by you.
verifyand a readable report — you do not have to trust us.
Privacy
History is encrypted before it leaves the machine, and metadata is encrypted too: file names and sizes do not reveal which projects you work on. Without the key, the store is opaque. There is no server and no account.
Install
Not published yet. When 0.1 ships:
dsh plugin --profile web add dsh-history-keeper
Compatibility
Developed against DeepSeek Harness 0.2.0-rc.2. The bundle declares
engines.dsh so an incompatible host refuses it instead of misbehaving.
Development
node --test "test/*.test.mjs" # unit tests, no dependencies to install
npm run guard # refuses committed session logs
Design notes and roadmap: docs/. Release history, including versions that were
never published and why: CHANGELOG.md.
License
MIT
No comments yet. Be the first to write one.