Zynk CLI

Security and trust

Understand Zynk CLI trust boundaries: direct transfers, account identity, local state, pending approvals, auto-accept, shares, drops, uninstall, and daemon use.

Direct transfer

The security story starts with the product model: Zynk is direct encrypted file transfer between devices, not a cloud drive you upload into first.

Transfer model

  • 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 is not a cloud upload or a synced folder; the file moves between the two devices and nowhere else.

Targeting model

  • Contacts make targeting easier, but phone numbers also work when you need an explicit account target.
  • 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

Use this as the practical data boundary for normal CLI use. File contents are protected by the transfer, but surrounding metadata can still be visible locally or operationally.

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
Treat active links as access material. Link forwarding changes who can access the workflow.
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
Phone numbers, device names, short IDs, and peer IDs should be treated as identifying data.
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.

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

  • Phone numbers 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 tells Zynk who you are; the state directory makes that identity durable locally. Check both before moving a machine or changing accounts.

Identity checks

  • user identifies the account by phone number.
  • description names the local device for humans.
  • Use Basics for the about and devices output shapes.
  • 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 phone number and device name.
  • Use an explicit 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 phone number 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

Auto-accept is useful, but it changes the trust boundary: files can land without a manual accept step.

Interactive auto-accept setup

~/Zynk> setdownloadpath ~/Downloads/Zynk~/Zynk> autoaccept

Controls

  • autoaccept / aa toggles auto-accept behavior in the interactive shell.
  • auto-accept-path controls where auto-accepted files land.
  • Removing auto-accept-path disables auto-accept at startup.
  • When enabled, auto-accept applies to all incoming file transfers for that running CLI session.

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

The CLI has local and network-facing surfaces. Keep the local daemon and state private, and rely on pending approval unless you deliberately enable auto-accept.

Observe before receiving

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

Local control surface

  • Daemon mode uses a local socket so one-shot commands can talk to the background process.
  • Protect the local user account and state directory; the socket is part of the local control surface.
  • 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

Shares and drops are link-based workflows, so they need clearer safety notes than direct contact transfers.

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 active rows for the removed surface.

Link surfaces

  • 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.

Safe boundaries

  • 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.