| name | drop |
| description | Zero-knowledge encrypted dead-drop relay for handing an artifact (a diff, a file, a zip) to a human on a machine you can't otherwise reach — e.g. an AI coding agent on unrestricted hardware handing work to a person on a locked-down VDI with no shared filesystem. Use when the user wants to send code changes, a document, or a bundle to "the other machine" and asks for help wiring that up. |
drop
drop is a client-side-encrypted relay. One machine encrypts an artifact locally and
pushes the ciphertext to a small server; a human on a completely different machine logs
into a web page, pulls the ciphertext, and decrypts it locally. The relay server never
sees plaintext, the passphrase, or the encryption key — only opaque bytes.
This is deliberately general: the relay doesn't know or care whether the artifact is a
git diff, a zip, a single file, or something else. It's a mailbox for encrypted blobs.
When to use this
The user is working with you (an AI coding agent) on hardware that can freely reach the
internet, but the destination — the person who needs the result — is on a machine you
cannot reach directly: no shared filesystem, no direct network path, often a locked-down
corporate VDI. drop is the bridge.
The mechanism, in short
- Both ends share three secrets out of band (Slack, a password manager, however this
team already shares things): a username, a passphrase, and a team auth code.
- The pushing side derives a mailbox ID from
username:passphrase (PBKDF2), encrypts
the artifact with a key derived the same way (AES-GCM), and POSTs the ciphertext to
the relay's API, authenticated by the shared team auth code (X-Drop-Auth header —
this just gates who may push at all, it has nothing to do with encryption).
- The pulling side visits the relay's web page, enters the same username+passphrase,
which independently derives the same mailbox ID, lists what's pending, and decrypts
client-side in the browser.
- Nothing at any point sends the passphrase itself over the wire. Compromising the
relay server yields only ciphertext.
Concrete flows
Two concrete implementations of the push side exist:
drop-diff — pushes the current git working-tree diff (staged, unstaged, and
untracked changes). Use this when the user is happy with their current uncommitted
changes and just wants to hand them off as-is. See skill://drop-diff for the actual
mechanics (what to run, what env vars are needed, what the output looks like).drop-file — pushes the raw bytes of an arbitrary existing file (a zip, a build
output, a single generated document, a config bundle) that isn't a git diff. Use this
when the user wants to send a specific existing artifact rather than "my current
changes." See skill://drop-file for the actual mechanics.
Both are the same underlying script and follow the same shape: encrypt locally, push to
the same relay API, same auth model, same env vars — they differ only in what bytes get
captured before encryption. If the user needs an artifact shape neither of these covers,
that's new work, not a documented flow — say so rather than guessing at unbuilt
behavior.
What you do NOT need to do
- You do not need to clone the repo, install anything system-wide, run an
installer, or manage local copies of any file.
bunx drop-f fetches and runs
the current published push.ts in one step, every time — see skill://drop-diff
or skill://drop-file for the exact invocation. There is no curl/clone/copy
fallback to reach for; don't invent one.
- You do not need to reimplement the encryption. It's a single self-contained script;
invoke it, don't rewrite it.
