dsh-swarmdrop

dsh plugin --profile web add dsh-swarmdrop

dsh-swarmdrop

Give your DeepSeek Harness agent a

channel to your own devices. It can push what it just produced straight to your

phone, and you can @-reference what your phone sent back — no account, no public

IP, end-to-end encrypted.

The transport is SwarmDrop, driven through

its CLI.

Status: developer preview. dsh itself declares breaking changes, and this

plugin sits on its extension seams. Pin a version.

Pin the dsh line too. The peer ranges target 0.1.0-rc.x; npm's latest

tag on the @deepseek-ai/* packages still points at the older 0.0.1-rc.x

line, so an unpinned install resolves to packages this plugin does not target.

What you get

In dsh · What happens

"send the report to my phone" · The agent calls swarmdrop_send_files; a transfer row appears in the conversation and follows it to completion.

/swarmdrop send ./report.pdf phone · Same, without a model round trip.

@ in the composer · Your inbox — everything your devices sent this machine — as reference candidates.

Your phone sends a file · A row appears in the conversation, and the item becomes referenceable.

The SwarmDrop button at the sidebar foot · Node status and network posture, start/stop, your paired devices, and pairing a new one — without leaving dsh for a terminal.

Settings → SwarmDrop · Everything that needs room: invites and revoking them, the whole inbox, transfer history and its controls, this machine's name and receive directory, bootstrap nodes.

The panel

A dot beside Settings says whether a node is running: green for running, amber

for stopped, grey while the first answer is still in flight. Opening it gives you

• Node — running or stopped, its node id, and one button to change that.
• Network — NAT class, relay reservation, bootstrap, connected peers, listen

addresses. Shown only while a node is running, because every field would

otherwise read "unknown" and say nothing the node row did not.

• Devices — what is paired and whether it is online. unknown is its own

state, not a synonym for offline.

• Pairing — "Add a device" issues an invite and staffs the desk, then opens

a dialog showing it as a QR code for your phone to scan, with the link

behind a copy button for when scanning is not an option. When a device shows

up, a second dialog gives you its name, system, link type and full node id

before you decide — and it opens whether or not the panel is showing, because

a request nobody answers is a device that just times out.

Pairing still requires a person to look at the far side's identity — that has not

been relaxed, only moved. An invite is a one-shot capability that travels as a

link, and whoever presents it first consumes it, so SwarmDrop's node refuses

every inbound request unless someone is at the desk.

The desk stays staffed until you press "Cancel pairing", not until you close

the dialog — copying the link is in order to go paste it somewhere, so the

dialog is always closed mid-pairing, and closing it must not end what the far

side is halfway through. The Pairing section keeps a "pairing in progress" row

with a way back in, and the sidebar dot turns amber-grey, so a desk left staffed

is visible without opening anything.

The QR code is rendered by swarmdrop itself, not by the browser. SwarmDrop

encodes every one of its surfaces through one module, and that module also

decides how many dialable addresses fit on the code and drops the rest — work

that needs the invite's structure opened up. A second encoder in the browser

would quietly produce codes a camera cannot read.

The settings page

The panel is a status light; the page is where the occasional work happens.

Seven sections, each read when you open it and re-read when you ask — never on

a timer, because every one of them costs a swarmdrop process.

• Overview — the panel's facts, unabbreviated: every listen address, the

full node id, every paired device with its identity.

• Invites — what this machine has handed out, and one button to take it

back. An invite is valid for 24 hours, survives restarts, and whoever holds

it can pair, so this is the only way to stop one that leaked.

• Inbox — everything that arrived, where it landed, and exporting a copy

elsewhere.

• Transfers — history, with pause / resume / cancel offered only where the

CLI will accept them.

• Settings — this machine's device name and receive directory. Each value

says where it comes from, and when an environment variable is winning it says

what is being held down — otherwise you would edit a field that does nothing.

• Bootstrap — the relay and bootstrap nodes this machine uses, their

connection state, and the kernel's own words when one will not come up. Your

additions and removals layer over the built-in list rather than replacing it,

so a release that changes the built-in addresses still reaches you.

• About — plugin and swarmdrop versions, and a check for a newer one.

The last two need swarmdrop 0.6.0 or newer; with an older one they say so

rather than showing you an argument-parsing error.

The panel cannot open this page. dsh hands openSection only to

settings.onboarding entries, so a plugin has no way to open Settings on its

own section. The panel expands what it already has in place and leaves opening

Settings to you — which is why anything the page is the only home for has to

be findable from Settings alone.

Install

dsh plugin --profile <name> add dsh-swarmdrop

That is all — the package declares a dsh.bundle, so dsh appends it to the

profile's bundle list and its config layer activates on the next start. Verify

before launching with dsh --profile <name> --dump-config, which should show a

# == dsh-swarmdrop layer.

dsh plugin forwards to pn

…(truncated)