A patch release: four fixes, one flag, and a note when a newer bitbang
exists. Nothing changes about how you start a listener, and 0.5.0 command
lines keep working.

All but one of these came from @lars18th, who has been running 0.5.0
against real hardware and writing up what he found.

The file browser offered uploads it could not do

Without -files-upload the file browser still showed an Upload button, a
drop target, and a "drop files here" hint. The listener refused the POST
either way -- api/upload answers 404 unless uploads are on, so nothing
was ever writable -- but you could pick a file and get nothing back
explaining why.

The button, the drag-and-drop, and the hint now appear only when the
listener accepts uploads. They start hidden and appear once the page hears
back, so a slow answer shows no button rather than a button that does not
work. (#37)

Leaving an interactive shell took five seconds

Typing exit in a shell session left the connector sitting there for
five seconds before it quit. Every session, regardless of how much output
there was.

Before sending the exit frame the listener waits for the shell's output to
end, so that nothing written just before exit is cut off. In PTY mode that
wait could never finish: the listener holds the pseudo-terminal's slave
end open for the terminal's lifetime, so a read on the master side never
ends no matter how long ago the shell exited. Every session ran the
five-second timeout down and was then cancelled.

The slave end is now closed once the process has gone, which is what lets
the read finish on its own. The last of the output and the exit code still
arrive.

Measured on one machine, five runs each, the same shell doing the same
thing: 5005ms before, 2.7ms after. The old figure was the timeout plus
about four milliseconds of real work, so what went away was the waiting
and nothing else. (#31)

cp takes a saved device name

connect nas worked and cp nas:/file . did not -- cp could write no
device-table entry and could not read one either. Now it reads:

bitbang connect <url> -name nas     # save it once
bitbang cp nas:/photos/x.jpg .      # then use the name
bitbang cp ./report.pdf nas:/inbox/

Same case-insensitive lookup connect uses. Anything that is not a saved
name is read exactly as before. (#32)

-noqr

bitbang serve -noqr

Prints the banner, the version, and the URL, and no QR code. The QR was
printed to pipes and log files as well as terminals, and the whole startup
block is reprinted on every reconnect, so a listener running as a daemon
on a flaky network accumulated them in its journal. (#34)

A newer bitbang says so

A listener has been told about a new release since 0.5.0, in the reply to
a registration it was already making. Connectors were not: connect and
cp had no equivalent message to carry it, so they never mentioned an
update however old they were.

The client half is in 0.5.1. It works on the same terms the listener's
does: the signaling server states the same table to everyone as the
connection opens, the client sends nothing -- not its version, not what it
is, not an extra request -- and decides locally whether it has anything to
say. The notice goes to stderr, so bitbang cp <url>:/file - still writes
only the file to stdout.

It needs the matching signaling server to say anything at all, and that is
a separate deploy -- ours and yours both. Against a server without it,
connectors stay quiet, which is what they did before.

bitbang serve now takes words for what it serves, access links let one URL
reach less than the next, and there are Windows and macOS binaries for the
first time.

Upgrading from 0.4.7 means changing your command line -- see Breaking
changes below.

Access links

A listener can hand out URLs that reach less than it does, each with its own
expiry, each revocable on its own. The terms live in ~/.bitbang/<program>/links.json:

[
  {"label": "ana", "grant": "files", "expires": "2026-09-01T00:00:00Z"},
  {"label": "ben", "grant": "files /srv/photos"},
  {"label": "dev", "grant": "shell forward 127.0.0.1:5432"}
]

A grant is written in the same words serve takes, and can only narrow what
the listener already serves -- so a link is not limited to picking
capabilities. It can name a subdirectory of the share, a subset of the forward
targets, or a single command for the shell.

Revocation and expiry reach sessions that are already open: the connection
closes and the holder is told why. An expired code is retired rather than
paused, so renewing mints a new one and the URL you already sent stays dead.

bitbang link ls|edit|rm|qr manages the table from outside. Pressing Enter at
a running listener opens a console that does the same thing live, mints links
with add, and walks you through a grant a question at a time.

Capability words

serve names what it offers instead of carrying a flag per mode:

bitbang serve                                    everything
bitbang serve shell files ~/share
bitbang serve proxy nas.lan:8096,pi.lan:80
bitbang serve forward 127.0.0.1:22 files ~/pub

One rule holds it together: a positional says what is served, a flag says
how. proxy a:80 and files /srv are what; -files-upload and
-proxy-client-ip are how. A target therefore has exactly one spelling, and no
flag repeats it.

Naming targets restricts them. serve proxy nas.lan:8096 reaches that and
nothing else, and the browser's address box is disabled rather than offering a
box whose answers get refused.

TCP forwarding

connect -L forwards a local port to any host the listener can reach, the way
ssh spells it:

bitbang serve forward 127.0.0.1:22
bitbang connect <url> -L 2222:127.0.0.1:22
ssh -p 2222 you@localhost

forward is its own capability, so a listener can be a wire and nothing else
-- there is no shell to escalate to. Naming targets restricts what it will
dial, and a link can narrow that further.

Terminal sharing

bitbang share publishes the tmux session you are in as a pair of URLs, one
that can type and one that can only watch. Needs tmux, so Linux and macOS;
Windows can open share URLs but not host one.

Also

• Bring your own TURN. -ice-servers points the listener at your own relay,
  and the server hands it to whoever connects, so ours is never involved.
• Windows and macOS binaries. Previously Linux only. Windows shells run on
  ConPTY.
• A pinned command is pinned. serve shell /bin/login runs that and refuses
  a connector asking for something else, so it works as a second factor.
• Head-of-line latency. The send queue was allowed to grow to 8MB, which is
  standing delay for everything sharing the channel. Bounded at 1MB: a ping
  during a bulk transfer went from ~70ms to ~8ms.
• connect -nosave leaves nothing in the device table. connect -norelay
  refuses STUN/TURN so a connection fails rather than quietly relaying, and
  -v now says which path it got.
• An ephemeral listener marks its URLs, so connectors do not save a credential
  for an identity that disappears when it exits.
• A listener says out loud when a URL reaches more than it looks like: a shell,
  or forwarding with no targets named.

Breaking changes

A removed flag is an error, not a setting that quietly does nothing, so an old
command line fails at startup rather than serving something you did not ask
for.

Two behavior changes worth naming. A command after shell used to be a
default that a connector could replace by passing its own argv; it is a pin
now, with no flag to enable. And a command of more than one word must be
quoted -- serve shell "tmux attach" -- because every word takes exactly one
argument.

Identities and devices.json from 0.4.7 carry over unchanged.

Fix PIN vulnerabilities