Build your own Dafeiyu

Build a Dafeiyu with DSH: Plugin to Desktop Runtime

Author
DeepSeekAgent.io Editorial Team
Published
Updated

Do not begin by copying an entire desktop-pet repository. First build the smallest plugin that DSH can install, that displays real state, and that shuts down safely. Add art, native windows, task dispatch, memory, and progression only after the contract works.

This guide presents a durable development order. Exact APIs evolve with DSH releases, so verify manifests and event interfaces against the current DSH source and reference projects.

1. Define the product boundary

Answer four questions:

  1. Does the character live inside DSH Web or in a native desktop window?
  2. Does it only display state, or can users dispatch tasks from its bubble?
  3. Are actions local rules, or does a model generate dialogue?
  4. Does it preserve names, relationships, feeding, and long-term memory?

For a first build, choose an in-Web character, structured state, local actions, and no long-term memory. It avoids a separate process, fixed port, and extra API key while validating the plugin contract.

2. Create the minimal bundle

A complete pet commonly has Host and Client halves:

my-dafeiyu/
├── package.json
├── cordis.patch.yml
├── src/
│   ├── index.ts
│   ├── client.tsx
│   └── shared.ts
├── assets/
│   ├── pet.json
│   └── animations/
└── README.md

Declare the DSH bundle/patch entry in package.json; use cordis.patch.yml to insert the plugin row into a Profile. Do not modify DSH core files or require users to reapply patches after upgrades.

The first version only needs enablement, character rendering, idle animation, a visibility setting, and safe removal.

3. Make the Host authoritative

The Host subscribes to DSH Session and Tool events and normalizes them into a small UI state set:

IDLE → THINKING → WORKING → WAITING
                  ├→ SUCCESS
                  └→ ERROR

The Client should never scrape chat DOM or infer state from bubble text. The Host emits a minimal snapshot: Session, phase, tool family, start time, and whether user input is required.

Cleanup matters too. Dispose subscriptions, timers, native helpers, and pending state when the plugin stops. A pet must not leave orphan processes after DSH exits.

4. Finish the Web character first

An in-Web implementation is the minimum viable product. Place it in an overlay that does not block the composer or primary content. Provide drag position, size, opacity, show/hide, reduced motion, and a concise status bubble.

After an interaction animation, return to the latest real Agent state rather than unconditional IDLE. This is one of the most common pet-state bugs.

5. Add a native helper only for desktop presence

Use a transparent native window only when users need the character over editors and browsers. The DSH Host should launch and own the helper. Send minimized state through host communication; do not create a second API-key or Session database.

Handle transparent always-on-top behavior, multiple displays, DPI scaling, click-through recovery, taskbar boundaries, crash cleanup, and a Web fallback when the helper fails.

6. Test the correct Profile

WebUI commonly uses web; official Desktop uses desktop. Their plugin configurations are separate:

dsh plugin --profile web add ./my-dafeiyu.tgz
dsh plugin --profile desktop add ./my-dafeiyu.tgz

Do not assume a Web installation appears in Desktop. If both Profiles enable a native helper, prevent duplicate characters.

7. Add task dispatch deliberately

A bubble composer may send text to a Session explicitly selected by the user. Do not create a full-access Session automatically or change permission policy in the background.

Show target Session, workspace, busy/idle state, and permission mode. Retain failed drafts and explain whether input queues, appends, or interrupts running work.

8. Add memory and progression last

Separate settings such as position and volume from progression such as affinity and food, and separate both from private facts, relationships, and diaries. Version every save format, use atomic replacement, and retain a backup. Never store user memory inside the replaceable plugin installation directory.

Minimum acceptance criteria

  • install, enable, disable, upgrade, and uninstall do not break DSH;
  • idle, thinking, tool, waiting, success, and failure states are reproducible;
  • multiple Sessions do not fight for the character;
  • interactions return to the latest real state;
  • Web and Desktop Profile behavior is documented;
  • no screen reading or API-key leakage;
  • helper and configuration failures have safe fallbacks;
  • code and character-asset licenses are separate.

Continue with character assets and transparent animation, Session and Tool Call integration, memory and progression, and permission boundaries.

References