Merge origin/main into claude/spelunk-tunnel

Port forwarding took host schema version 8 first, so the Spelunk route moves to 9 and is written after the forwards. A host may carry both.
This commit is contained in:
jaap-jan committed 2026-09-28 21:38:09 +02:00
commit 689ba6c1bf
44 files changed
+3187 -75

No files matched your search

+49 -7
View File
@@ -44,7 +44,7 @@ Three consequences worth knowing before you read further:
The reasoning behind each major decision is recorded in [`docs/adr/`](docs/adr/), starting with
[the E2EE trust model](docs/adr/0001-e2ee-trust-model.md).
The desktop client's interface was built from a design covering more product than exists yet — file
The desktop client's interface was built from a design covering more product than existed at the time — file
transfer, teams, saved snippets, port forwarding. Everything that design asked for and this build has not
got is written down in [`docs/design-import-gaps.md`](docs/design-import-gaps.md), with the layer each
piece would land in and what the interface shows in its place. Nothing was rendered with invented data to
@@ -426,6 +426,32 @@ What is not here: transferring a directory, dragging between the panes, and rout
bastion — the last needs jump hosts the connection layer has not got. All three are in
[`docs/design-import-gaps.md`](docs/design-import-gaps.md).
### Forwarding ports
A host can carry **port forwards**, added under PORT FORWARDS in its editor, in the three kinds OpenSSH has:
**local** (`-L`, a port here reaching a machine the remote can see), **remote** (`-R`, a port on the remote
reaching back to one this machine can see) and **dynamic** (`-D`, a SOCKS proxy here whose connections leave
from the remote). They are saved in the host's encrypted payload, so they sync, merge and are shared with the
host, and they start with every terminal opened to it, on either head. The session sidebar lists them under
FORWARDS with the state of each, and the status bar counts the ones listening; on the phone the same list is a
sheet off the terminal's bar.
Three things about them are worth expecting rather than discovering.
**Everything listens on localhost, and there is no setting for it.** A forward is a field any member of a
shared keychain can fill in, and one bound to every interface would hand the remote's network to anybody who
can reach your machine for as long as the terminal is open. A remote forward asks the remote for its loopback
too; whether the remote honours that is its own `GatewayPorts`.
**A forward lives as long as its terminal.** It runs over that tab's connection, so closing the tab, losing
the connection or reconnecting stops it — a reconnect starts the host's forwards again on the new session. A
second tab to the same host runs the same forwards, and they fail there because the ports are taken; the row
says so, and the terminal is unaffected. Any row can be switched off and on while its session is up.
**No byte counts**, which the design draws: SSH.NET keeps none, so a number there would be invented. The
phone runs forwards too, listed behind a `⇄` in its terminal's bar, but cannot edit them yet; see
[The Android head](#the-android-head).
### Reaching a server through Spelunk
A server managed by Spelunk runs Spelunk's agent, which keeps a connection open to Spelunk. DodoSSH can use
@@ -671,8 +697,9 @@ its host if it has one and back into the box if it does not.
**A connected phone shows one bar and then the terminal.** The header, the session strip and the bottom
bar are collapsed while a shell is up, and a single 35-pixel row replaces them: back on the left, the
sessions as pills, and a `+` on the right offering the three connections this application can make — a
shell, a host's files over SFTP, or a bucket. The system back gesture does what the arrow does, and lowers
that menu first if it is open.
shell, a host's files over SFTP, or a bucket. Beside the `+`, for a tab whose host has port forwards, a `⇄`
opens them; see below. The system back gesture does what the arrow does, and lowers either sheet first if
one is open.
Widening the rail moved the desktop window's minimum from `880x560` to `1016x574`, which leaves every
screen exactly the width it was designed against.
@@ -740,10 +767,25 @@ What it does *not* yet do is use the extra width inside a screen: the host list
size. Two columns needs the row model to change — the list is headings and hosts in one sequence, and a
heading has to span — which is shared with the desktop and is its own piece of work.
**Port forwarding is not built anywhere**, and the phone's More screen says so in a paragraph rather than
leaving a gap. The v2 design draws a whole screen for it; nothing in the SSH layer forwards anything, so
every control on that screen would have had no effect. See
[`docs/design-import-gaps.md`](docs/design-import-gaps.md).
**Port forwarding runs here too, and is edited on the desktop.** A host's forwards start with every
terminal the phone opens to it, as they do on the desktop. The terminal's bar grows a `⇄` for a tab that has
any, carrying the number listening in green, or turning red when one could not start; it opens a sheet
listing the tab's forwards with their route, their state, the reason a failed one gave, and a tap on each to
switch it off or on — the desktop sidebar's FORWARDS section, over the same rows. The v2 design's whole
FORWARDING screen is not drawn, for the reason the desktop has none: a forward belongs to a host and runs
with a session, and both already have a place. What the phone has not got is an editor for them — its host
form has no PORT FORWARDS section — so they are added on the desktop and arrive with the host; the More
screen says so in a paragraph.
Forwards ride the **keep-alive** a shell already has. A forward runs over its tab's connection, so the
foreground service that holds a shell open in the background is holding its forwards open too, and nothing
else needs to: the service is never started for a forward alone, because there is never a listening forward
without a live shell. What forwards change is the notification, which counts them beside the shells —
`1 shell connected · 2 ports forwarded` — because a phone in a pocket holding ports open is something its
owner should be able to see. Local and SOCKS forwards listen on the phone's own loopback, which every app on
the phone can reach; that is what makes one useful here — a database client on the phone reaching a server
behind the remote — and it is the same exposure the desktop's localhost has to its own processes. See
[Forwarding ports](#forwarding-ports) and [`docs/design-import-gaps.md`](docs/design-import-gaps.md).
It is deliberately **not** in `DodoSSH.slnx`. Putting it there would make the `android` workload and a full
Android SDK a prerequisite of `dotnet build DodoSSH.slnx` for everybody; it has its own CI job instead, which