clidmsg

Overview ¶

Package clidmsg cmd/skywire-cli/commands/dmsg/attach.go c4-vis-cli `skywire cli dmsg attach` — inspect and exercise a local visor's dmsg relay acceptor (pkg/visor/init_dmsg_relay_local.go).

Attaching is how a standalone dmsg process stops holding dmsg server sessions WITHOUT changing its key: it gets one session, to the visor beside it, over a unix socket, and its streams are forwarded over that visor's sessions and transports. This command is the two checks an operator needs before trusting that path:

skywire cli dmsg attach                 # what is on the other end of the socket?
skywire cli dmsg attach --sk <key>      # would MY key be admitted?

The first needs no identity at all — it reads the acceptor's hello and hangs up — which is deliberate: verifying a socket must not mint a key, and a deployment that has paid for hundreds of throwaway identities does not need another source of them.

The end-to-end path with real traffic is the --attach flag on the standalone tools: `skywire cli dmsg curl --attach <socket> dmsg://<pk>:80/...` fetches over the visor's sessions under the caller's own key.

Package clidmsg cmd/skywire-cli/commands/dmsg/cat.go c4-vis-cli `skywire cli dmsg cat` and `skywire cli dmsg cat listen` subcommands. Splice stdio with a remote peer over either dmsg or the skywire router.

Client form : `cli dmsg cat <pk>:<port>` — opens a stream, copies

stdin → stream and stream → stdout, exits when
either side EOFs.

Listen form : `cli dmsg cat listen <port>` — accepts one inbound

stream (after a whitelist check), then splices
stdio. One-shot by design; multi-conn into the
same stdout would interleave bytes meaninglessly.

The client form has a standalone-dmsg fallback so it works without a local visor; the listen form does not — listening requires the dmsgscp whitelist, which the visor owns.

Package clidmsg cmd/skywire-cli/commands/dmsg/chat.go c4-vis-cli dmsg-only chat. Run when the local visor is down (or absent) so operators can still reach a support channel.

The visor-app skychat (cmd/apps/skychat) uses the visor's identity and the visor's dmsg.Client — its main strength is sharing the same PK operators publish in service-discovery, but the cost is "if the visor is broken, skychat is broken too." This command sidesteps that: it stands up its OWN dmsg.Client with a separate secret key, listens on a dmsg port for inbound chat, and dials peers directly over dmsg for outbound. No visor RPC, no route-finder, no skynet.

Wire format mirrors the visor-app skychat post PR #2504:

[4-byte BE length][JSON envelope]

where the JSON shape is {"sender","message","ts","network"}. Two skywire dmsg chat instances can talk to each other; cross-talk with visor-app skychat works if the visor-app side is also on the post-#2504 framed protocol.

Why a TUI rather than send/listen subcommands like dmsgcurl: the expected use is interactive — an operator opens it, types a few messages back and forth with support, closes it. send/listen would force the operator to manage two terminal windows. Same reasoning as `skywire cli skychat chat`.

Package clidmsg cmd/skywire-cli/commands/dmsg/chat_tui.go c5-cli-dmsg

The screen of `cli dmsg chat`, drawn with progkit: the conversation, a line to type into, and the recipient to pick first when none was given. In websh the line is a real text field and the conversation selectable text.

Package clidmsg cmd/skywire-cli/commands/dmsg/connect_all.go c4-vis-cli

Package clidmsg cmd/skywire-cli/commands/dmsg/converge.go c4-vis-cli

Package clidmsg cmd/skywire-cli/commands/dmsg/curl.go c4-vis-cli

Package clidmsg cmd/skywire-cli/commands/dmsg/diag.go c4-vis-cli

Package clidmsg cmd/skywire-cli/commands/dmsg/iperf.go c4-vis-cli cli dmsg iperf <pk>:<port>` and `skywire cli dmsg iperf listen <port>` — bulk throughput measurement over a dmsg stream.

Client form : opens one stream, pumps zero-filled buffers from

memory (not /dev/zero, which adds a Go-fs read at
every kernel boundary) for --duration, prints the
final goodput along with periodic rolling samples.

Listen form : accepts one inbound stream, drains it into a

black-hole sink, prints the same shape of samples
from the receive side. One-shot like dmsg cat listen.

Both sides emit lines on stderr at --interval cadence so an operator running `dmsg iperf <pk>:<port> --duration 30s --interval 1s` sees ~30 sample lines plus a final totals line, like classic iperf. The wire itself is just bytes — no length framing, no type tags, no envelope. Sender writes, receiver reads. That keeps the measurement as close to the raw transport as possible: any overhead in the printout is from go's runtime and the operator's kernel, not from the iperf shim.

Why a dedicated command vs. piping /dev/zero | dmsg cat:

• cat adds an extra goroutine pair and a stdin/stdout splice; iperf bypasses that for tighter byte accounting.
• cat's "exit when either side EOFs" semantics fight the time-bounded test pattern operators want for throughput.
• rolling-sample stderr lines + a totals line are conventional for throughput tools; you can't easily get that out of `cat`.

Standalone-dmsg only in this first cut: the client bootstraps its own dmsg.Client just like `dmsg cat` with --transport dmsg. A future patch can add a VisorIperf RPC for the auto/skynet paths once we've validated the standalone shape.

Package clidmsg cmd/skywire-cli/commands/dmsg/port_hits.go c4-vis-cli

Package clidmsg cmd/skywire-cli/commands/dmsg/probe.go c4-vis-cli

Package clidmsg cmd/skywire-cli/commands/dmsg/pty.go c4-vis-cli

Package clidmsg cmd/skywire-cli/commands/dmsg/root.go c4-vis-cli

Package clidmsg cmd/skywire-cli/commands/dmsg/scp.go c4-vis-cli `skywire cli dmsg scp` subcommand. Drives the dmsgscp client against either a peer's dmsgscp Host or the local visor's (loopback over its own dmsg PK).

Direction is inferred from which argument carries a `PK:` prefix. The PK is 66 hex chars — long enough that the regex can't false-match a normal filename.

Package clidmsg cmd/skywire-cli/commands/dmsg/sessions.go c4-vis-cli

Package clidmsg cmd/skywire-cli/commands/dmsg/smb.go c4-vis-cli

Registers the standalone (dmsg-only) SMTP→dmsg bridge as the `smb` subcommand of `skywire dmsg`, so a single skywire binary can launch it without requiring a separately-built top-level binary. The visor-side in-process bridge has its own control surface at `skywire cli mail`; this subcommand is for hosts that don't run a visor.

Package clidmsg cmd/skywire-cli/commands/dmsg/sub.go c4-vis-cli

Registers the standalone UDP→dmsg bridge as the `sub` subcommand of `skywire dmsg`, so a single skywire binary can launch it without requiring a separately-built top-level binary.