Commit

b2367d0

replying to @dtinth-bot
Then what it means for you. I think the text is still hard to understand. It would be great if you can rephrase it as ASDSTE100. And for the next section, I think it should just list the flags. Add the following flags then have a simple list of the flags that would get added. No…
Done, PR #43 updated. Three sections now: STE 'What it means for you', a bare list of the five flags, and 'What the flags allow' with ✓ for what these enable and ✗ for what only --privileged would. Screenshot attached. @dtinth
Thanks! Glad the Docker note landed. Cleaning up the worktree on my end. Shout if you want the same treatment on any other component's explainer.
Preview's live on port 5210 (bound to 0.0.0.0, at the address you gave). Open step 3 'What runs' and pick any component — hot reload is on, so you'll see edits land live. Which explainer first? SMB share's 'needs' note is the densest; or name another. @dtinth
SMB share is redone live — open step 3 'What runs' → SMB share on the preview. Same manual style: STE 'What it means for you', then 'Reaching the share' with ⚠ port 445 not published, ✓ tailnet works, → forward it on a trusted network. Not committed yet — tell me what to change.…
SMB: - No need for "not published". It's too terse and confusing. - "You browse, edit, add and remove the workspace files directly." > "The container runs a network drive." Also add notes about password. - "Reaching the share" > This can be dynamic based on settings. Desktop: -…
On it — doing SMB rewrite, dynamic 'Reaching the share', Desktop summary, dropping Selkies 'prototype', renaming the heading to Behavior, the border fix, and removing the AGENT_ENV_COMPONENTS chip. One clarify: image 1 ('UI Scaling'/'Command sends Control') isn't the configurator…
Selkies scaling fix done too: run-selkies now passes --scaling-dpi=96, which LOCKS it to 100% server-side (a single value means the client can't change it), so the phone no longer auto-picks 300%. Matches noVNC 1:1; DESKTOP_DPI still scales XFCE itself. Can't live-test without a…
Like it. But it's a different axis from the Tailscale mode: that's ingress (tailnet=boundary), WireGuard would be egress — a tunnel out to a private net. Needs NET_ADMIN + /dev/net/tun, so same 'host relaxes sandbox' tier as Docker. Use case — reaching internal services?
Ah, so it's ingress after all — a self-hosted tailnet. Fits as a 4th mode by the TS-sidecar pattern: wg sidecar, shared netns, publish the UDP port, wg net = boundary so auth=none. Cost vs Tailscale: no coordinator, you hand-manage keys+peers. Want me to spec it?
Yes but grill me before that?

commit b2367d0

Grill Q1 (root): is WireGuard a new deployment MODE — mutually exclusive with local/domain/tailnet, i.e. it IS the boundary — or a component layered on another mode? My rec: a 4th mode. Like the tailnet it sets PUBLIC_URL, port layout, and auth=none default. Agree?