This machine is the hub
No second machine needed. Import, extraction, recall and backup all happen on this one; a single data directory is everything.
No second machine, no colleague agent. Does this memory still hold? It does: this machine is the hub, and most multi-device features step back on their own. The example below is Dafeiyu, the most popular character in DSH.
Solo is not a crippled build: the everyday memory capabilities are all here. What goes unused is what was built for a second device in the first place.
No second machine needed. Import, extraction, recall and backup all happen on this one; a single data directory is everything.
core belongs to it alone; the world memory covers just the two of you. A new session does not start from scratch, because yesterday is still there.
Pairing, replication, snapshots and cross-machine transcript reads never run on their own. Nothing is broken; there is just no second party to connect to.
Separate two things first: DSH (DeepSeek Harness) is the runtime for agents, and Dafeiyu is the most popular companion character in the community. The desktop pet is the look; the persona is the way of speaking. What reads files and runs tasks is the agent inside DSH; the pet draws its state.
You have one owner and one computer. Its persona is stable and it always talks like that fish; but open a new session and "the cat's check-up on Wednesday" still tends to drop.
Import DSH sessions through the contract and recollect keeps a copy of the memory on this machine. The DSH path uses the repository's tools/converters/dsh_v1.py: it turns sessions into unified events, and if acceptance fails the converter changes, not the core. Next time a new session opens, the agent first reads the conclusion + handle, not the whole chat; to verify, follow the handle back to the original words.
It still has only one agent. No second agent shares its memory, no second machine syncs with it. That is not a defect; the solo case never needed that set.
Last week you said the cat was due Wednesday; yesterday you moved it to Friday. Remember the carrier before you leave[1].
Follow [1] back to that original line; this is only an example.The same stack, only the enabled scope differs. Switch to see what runs and what stays in the drawer.
Solo works the same way: it does not record the chat, it hands back the right memory at a few key moments.
It first sees last night's line, "cat's check-up Wednesday, moved to Friday", and asks about the carrier instead of asking again what you keep.
"Remind me before Friday" goes into core's notebook; the summary enters the next opening on its own, so you never repeat it.
It answers "everything goes through build-release.sh" with [1]; follow [1] back to that day's words instead of trusting its retelling.
This is a state from that moment, not a permanent label; the next day it does not open by pushing for progress.

The case is illustrative only; in a solo setup these actions all happen on this machine.
Get it running first, then decide whether you want a second device. The solo path has no server, no node and no one-time code.
Get the release for your platform and check SHA256 first; the installer does not touch host config and ships no data.
Pick a local directory as --data-dir; the first start is an empty database, and everything lives here.
The DSH session format is the agent-side converter's job; if the converter fails acceptance, fix the converter, not the core.
Give this agent an id and core's key opens to it alone; no hub serve.
Solo removes one layer of network exposure, not one boundary to guard: disk, key, port and model egress are all yours to defend.
hub backup handles a dead disk, not a machine being taken away; do not keep backups and keys on this disk alone.
Each agent's notebook uses its own key; lose the key and the text stays shut, leak it and the text is public. Keys go into no backup and no model; archive them separately.
A solo machine gets scanned too. Listen on this host or a trusted LAN by default; for remote access use a tunnel or a mesh, and never expose the serve port directly.
Only the current turn leaves the machine; keys stay local, and secrets and identity fields are scanned before sending. Without a model, search and replay work as usual.
Fewer devices does not mean fewer boundaries; security comes from configuration, not from being solo.
You can run just one device, but never just one boundary.