Zynk CLI

Security and trust

Understand who can access your files and how to protect your account, saved state, and share links.

Direct transfer

Zynk sends files directly between devices using end-to-end encryption.

File transfers

Zynk sends files directly between devices.
Direct sends are end-to-end encrypted between sender and recipient, so the CLI does not expose a separate encryption switch.
A direct send transfers the file to the recipient’s device without first uploading it to cloud storage.

Choosing a recipient

Contacts make targeting easier, but an email address or phone number also works when you need an explicit account target.
A username lets people add you as a contact without learning your email address or phone number, and it cannot be used to sign in.
Own-device sends use the my:devicename prefix (or the --my flag) so a name or short ID is not mistaken for a person.
You do not need peer IDs for normal person-to-person or own-device transfers.

Who can see what

Transfers protect file contents. Your terminal, logs, and saved state can still contain filenames and account details.

Data: Direct-send file contents
Who may see it: Sender and approved recipient devices.
Handling note: Direct sends are end-to-end encrypted and still require the receiver to accept unless auto-accept is enabled.

Data: Share/drop file access
Who may see it: Anyone with an active share link, plus any required password, can download within expiry/limits. Anyone with an active drop link, plus any required password, can upload within expiry/limits.
Handling note: Sharing the link gives another person access within those limits.

Data: Filenames and local paths
Who may see it: Your terminal, shell history, logs, and any local process that can inspect command arguments.
Handling note: Paths can reveal project names, customer names, and folder structure even when file contents stay protected.

Data: Account and device identifiers
Who may see it: Your config, state, command output, daemon output, and routing path.
Handling note: Email addresses, phone numbers, usernames, device names, short IDs, and peer IDs should be treated as identifying data. Share a username rather than an address when you want to limit what a contact learns about you.

Data: Timing and transfer state
Who may see it: Sender, receiver, local logs, and operational routing components.
Handling note: Progress, pending state, and retry timing can reveal that a transfer happened even without file contents.

Data: Local state
Who may see it: Anyone who can read or copy the state directory.
Handling note: State can include identity material and transfer history. Keep it out of source repos and broad synced folders.

Data: Share/drop links
Who may see it: Anyone who receives or can read the active link, plus any required password.
Handling note: Links are access material until removed, expired, or exhausted by their configured limits.

Data	Who may see it	Handling note
Direct-send file contents	Sender and approved recipient devices.	Direct sends are end-to-end encrypted and still require the receiver to accept unless auto-accept is enabled.
Share/drop file access	Anyone with an active share link, plus any required password, can download within expiry/limits. Anyone with an active drop link, plus any required password, can upload within expiry/limits.	Sharing the link gives another person access within those limits.
Filenames and local paths	Your terminal, shell history, logs, and any local process that can inspect command arguments.	Paths can reveal project names, customer names, and folder structure even when file contents stay protected.
Account and device identifiers	Your config, state, command output, daemon output, and routing path.	Email addresses, phone numbers, usernames, device names, short IDs, and peer IDs should be treated as identifying data. Share a username rather than an address when you want to limit what a contact learns about you.
Timing and transfer state	Sender, receiver, local logs, and operational routing components.	Progress, pending state, and retry timing can reveal that a transfer happened even without file contents.
Local state	Anyone who can read or copy the state directory.	State can include identity material and transfer history. Keep it out of source repos and broad synced folders.
Share/drop links	Anyone who receives or can read the active link, plus any required password.	Links are access material until removed, expired, or exhausted by their configured limits.

Routing and metadata

Encryption protects file contents during transfer. Operational data still exists around a transfer, so treat account, device, path, link, timing, and log details as sensitive when sharing diagnostics.

What routing uses

Email addresses, phone numbers, and usernames identify accounts, contact names make targeting easier, and device IDs select devices under your own account.
Peer IDs and device names can appear in identity, device, daemon, and log output.
Share and drop commands create link-like identifiers that should be treated as access material until removed or expired.

What logs can reveal

Logs and terminal output can include account, contact, path, transfer, share, drop, and daemon details.
Review logs before sending them to someone else.
Use --no-color for plain diagnostic output, but do not treat plain output as redacted output.

Identity and state

The config file selects your account. The state directory stores its local identity and transfer history. Check both before moving an installation or changing accounts.

Identity checks

user identifies the account by email address or phone number. A username is refused here because it names an account without proving it.
description names the local device for humans.
See Basics for examples of about and devices.
Use this page to decide how to handle identity and state safely, not as the command reference.

Local state

State stores local identity, transfer state, and history.
Use show-state-dir before moving or backing up state.
Anyone who can read or copy state may learn local transfer history and may be able to reuse local identity material.
Persist state deliberately on servers and containers; do not put it in a source repo or broad synced folder.

Before sending sensitive files

For sensitive files, slow down target selection. The safest send is one where the local account and remote account are both explicit.

Confirm identity first

$ zynk aboutUser ID:        +15551234567Device Name:    Work LaptopPlatform:       macOS$ zynk send +15557654321 ./contract.pdf

Before sending

Run zynk about and confirm the account address and device name.
Use an explicit email address or phone number when a contact label is unclear or shared by more than one person.
Use zynk devices only for devices under your own account, then send with my:devicename (or --my <ID> for the short-ID form).

Trust checks

Verify a new contact or device out of band before sending sensitive files.
Treat contact names as local labels, not cryptographic proof of identity.
When the destination matters more than convenience, prefer the explicit account address over a remembered label.

Transfer approval

Receiving is inbox-first by default. That approval step is the clearest safety feature in the CLI receive path.

Accept with intent

$ zynk pending$ zynk accept --transfer-id 42 ~/Downloads$ zynk accept --from Alice ~/Downloads

Approval controls

pending lists incoming transfers before files are written.
accept chooses what to receive and where it lands.
accept --transfer-id is the safest precise selector when an index is ambiguous.
accept --all and accept --from are deliberate bulk actions. Read the pending list before using them.

Safe receive habits

Accept into a directory you can inspect.
Avoid accepting unknown work into project directories.
Use pending --since or pending --all when reviewing older transfers.

Auto-accept

With auto-accept enabled, incoming files are saved without asking you first.

Interactive auto-accept setup

~/Zynk> setdownloadpath ~/Downloads

Controls

setdownloadpath <PATH> enables auto-accept and saves the folder. autoaccept / aa disables it and clears the saved folder.
auto-accept-path controls where auto-accepted files land.
Removing auto-accept-path disables auto-accept at startup.
Auto-accept applies to incoming file transfers and stays enabled after restart until you disable it.

Safe defaults

Enable auto-accept only when incoming senders and the destination directory are understood.
Keep auto-accepted files out of source repos and executable paths.
Prefer a dedicated downloads directory for unattended receives.

Network exposure

Keep daemon access and saved state private. Incoming transfers require your approval unless you enable auto-accept.

Observe before receiving

$ zynk daemon status$ zynk pending$ zynk accept 0 ~/Downloads

Local daemon access

Daemon mode uses a local socket so one-shot commands can talk to the background process.
Protect your user account and state directory. Local processes can use the socket to control the daemon.
Stop a daemon before switching to a different account or persistence directory.

Network-facing behavior

Discovery and routing can reveal operational metadata such as account/device identifiers, timing, and connectivity state.
Direct sends do not write received files until you approve them with accept.
Auto-accept is the explicit exception: when enabled, incoming files can be written to the configured download path without another prompt.

Shares and drops

Anyone with a share or drop link can use it, subject to its password, expiry, and other limits.

Share and drop controls

$ zynk share ./report.pdf --password <strong-password> --expiry 3dShare ready at <share-url> Share this link to send your files$ zynk share ls --full --verboseID        TITLE        URL           PASSWORD    EXPIRES<id>      report.pdf   <share-url>   Yes         <expiry>$ zynk drop 2g --title "Client upload" --expiry 1wDrop ready at <drop-url>. Share this link with anyone to collect files.$ zynk drop ls --full --verboseID        TITLE           URL          PASSWORD    EXPIRES<id>      Client upload   <drop-url>   No          <expiry>$ zynk share rm all$ zynk drop rm all

Listings show whether a password exists, not the password itself. After removal, rerun share ls or drop ls and expect no entry for the removed link.

Share and drop links

share creates downloadable links, lists links, and removes links.
drop creates upload drops, lists drops, and removes drops.
Both support title, password, and expiry options.
Anyone with an active link, plus any required password, has the corresponding access within the configured expiry and limits.
Listings show whether a password exists, not the password itself.

Safe sharing

Use passwords for sensitive share links and upload drops.
Password values are passed on the command line today, so they can appear in shell history and local process inspection.
Use expiry for temporary access.
Do not treat a forwarded link as tied to the original contact who received it.
Remove old links and drops when they are no longer needed.

Uninstall

Uninstall can remove local identity and history when you agree to remove the config directory. Check paths first, especially when a custom persistence path is involved.

Know what uninstall touches

$ zynk show-state-dir$ zynk uninstall$ zynk uninstall --all

Uninstall behavior

uninstall removes the binary, PATH entries, and config directory with prompts.
uninstall --yes assumes yes for prompts.
uninstall --all additionally offers to remove the auxiliary state directory for daemon logs and lock files.

State warning

The default identity database and transfer history live under the config directory, so removing the config directory can remove them even without --all.
Without --all, auxiliary daemon logs and lock files can remain outside the config directory.
With --all, Zynk offers to remove that auxiliary state directory when it exists and is separate from the config directory.
Custom persistence paths outside the default config directory are reported but not deleted automatically.
Uninstall does not delete files you already received, and it is not account deletion.
Run show-state-dir before destructive cleanup so you know which local state directory is involved.

Recovery

Recovery depends on what leaked: local state, copied links, received files, or account identity. Local cleanup is not the same thing as account revocation.

Contain local exposure

$ zynk show-state-dir~/Zynk> share ls --full --verbose~/Zynk> drop ls --full --verbose~/Zynk> share rm all~/Zynk> drop rm all$ zynk uninstall --all

Local recovery

If a state directory was copied to an untrusted machine, stop using that local identity until the account is reviewed.
Move or remove copied state from shared folders and old backups when possible.
If a share/drop link was copied, list and remove the share or drop, or wait for its expiry before trusting that access is closed.

Account recovery

The CLI docs do not expose an account-wide identity revocation command today.
uninstall --all is local cleanup; it is not account deletion and does not revoke access elsewhere.
For suspected account or identity exposure, email [email protected] with OS, device name, approximate time, and redacted logs rather than editing state files by hand.

Daemon safety

Daemon mode is safest when it is explicit and observable. Keep background state tied to the account and state directory you expect.

Daemon trust

Run daemon mode under the account that owns the Zynk state.
Avoid multiple daemons using the same state directory.
Use daemon status and logs for diagnosis.
Treat logs as diagnostic data and inspect before sharing.

Access controls

Use normal account setup and device verification before changing state by hand.
Use troubleshooting steps for networking problems before changing daemon or state files by hand.
Keep untrusted receives out of directories used by source repos, executable files, or shared folders.