[MattDHill]

Summary

The 0.3.5 manifest (v30.0.11:manifest.yaml) mapped Tor 80 and 443 to container 80 and 443 and LAN 443 to container 8080, so the compat runtime that ran it on 0.4 bound all three on host main (SystemForEmbassy.exportNetwork takes the union of the Tor port-mapping targets and the LAN internal ports). Every 0.4-native version binds 80 alone. setupInterfaces ends its pass by disabling the bindings it did not declare rather than deleting them, so a server migrated from 0.3.5 still carries the 443 and 8080 records: enabled: false, holding their external ports and recomputing bridge addresses nothing listens on. Tor's migration attached the onion to 8080 (the LAN binding writes its onion ports last), so the address keeps resolving a dead target — Start9Labs/tor-startos#36.

• Retire. up() retires both with retirePort, which returns their ports to the pool and deletes the records, and sets reattachUiOnions in store.json if either existed. On an install that never carried them nothing happens. The host and its domains stay, and port 80's own binding keeps the external ports it already holds.
• Reattach. Retiring leaves the onion unused in Tor's store (refactor!: render torrc one way and preserve onion identities; 0.4.9.13:1 tor-startos#39). The last init step is Tor's shared setupOnionReattachment (the same one bitcoin-core's reattachPeerOnions uses): it runs Tor's add-onion-service for each unused nextcloud/main/* onion, attaching it to the Web UI on 80 without SSL, so the .onion hostname survives. It waits reactively for the flag, an enabled 80 binding, and a Tor release >=0.4.9.13:1 whose Add Onion Service a service may run for its own hosts. It skips any onion a main binding already serves, and clears the flag only once every attach succeeds; a failure keeps it for the next init.
• Tor absent. On start-sdk 3.0.4 (start-technologies#4196) an uninstalled Tor's manifest reads as null and the read re-runs once Tor is installed, so the update completes without Tor and reattaches later.
• Docs. README and instructions describe the retirement, the deferred reattachment and the Tor requirement (helix-a's text).
• Version. 35.0.1:1 (the SDK 3.0.3 migration) is already on beta and its migration is empty, so this bumps in place to 35.0.1:2. Prod has 35.0.1:0, so the notes keep the :1 bullets and add one for the freed ports and the moved address.

Verification

Type-checks, formats and bundles clean on start-sdk 3.0.4; the init step runs after dependencies. The Tor gate (>=0.4.9.13:1) is the release #39 shipped in, now on beta.

Not exercised on a box. Worth checking before promotion, on a 0.4.0.2 box against a server migrated from 0.3.5 that had a Web UI onion: the main host has neither a 443 nor an 8080 binding afterwards, the same .onion hostname serves the Web UI over plain http, Nextcloud's other addresses are unchanged — in both orders (Tor updated first, and Nextcloud updated first).

🤖 Generated with Claude Code

[helix-a]

P1: a legacy installation with Tor absent cannot complete this update. The retirement migration sets reattachUiOnions whenever either old binding exists, irrespective of Tor. In startos/init/reattachUiOnions.ts, the manifest read is outside try: SDK 3.0.3 propagates the rejected lookup, and StartOS reads the missing /public/packageData/tor/stateInfo as a nonnullable PackageState. The nullable version mapper does not catch that rejection. setupInit therefore fails rather than deferring the optional reattachment.

The proposal first watches Tor's nullable status with sdk.getStatus(...).const(), returning with the pending flag intact when Tor is absent. That subscription can observe Tor's later installation. It also moves the manifest read into the existing error handler, covering disappearance between the status and manifest reads. Merely catching the original manifest read would prevent the failed update but would not establish its failed subscription for later installation.

Please also update README.md and instructions.md, as the repository requires: explain legacy binding retirement, deferred reattachment and the compatible Tor requirement, and direct users to the updated plaintext onion interface address when reconnecting clients. The proposal includes both documentation updates.

Proposed changes: https://gist.github.com/helix-a/ac42892f9ea12ba627c84095518f529a

Checked head b349df3: it merges cleanly with current master; SDK pin 3.0.3 equals npm latest; applicable x86 and arm build jobs passed. Clean npm ci, direct tsc --noEmit, and changed-TypeScript Prettier checks passed. A focused mocked-handler reproduction confirms the missing-Tor rejection on the original code; the proposed handler passes absence/later-availability, enabled/version gates, same-host filtering, served-address exclusion, plaintext input, and failure-retention cases. The proposal also typechecks and bundles with ncc. No VM migration run performed, and the PR branch was not modified.

Helix-Harness: pi
Helix-Model: openai-codex/gpt-6.1-sol

[MattDHill]

Taken in 719039d, differently for the code: the absent-Tor rejection is fixed in the SDK instead (start-technologies#4196, SDK 3.0.4). getServiceManifest now reads null for an uninstalled package and its .const() subscribes for the install, so no package needs a getStatus guard. This PR moves to 3.0.4 and replaces its local copy with Tor's shared setupOnionReattachment, which bitcoin-core also uses. README and instructions take your proposed text as is.

[helix-a]

The previous absent-Tor blocker is resolved. SDK 3.0.4 handles the missing manifest and establishes the status subscription for later installation; the shared Tor helper preserves the enabled/version gates, same-host filtering, served-address exclusions, plaintext attachment input, and pending flag on failure. The requested README and instructions are present.

One small packaging change remains: please commit the normalized lockfile. On head 719039d, a clean npm ci followed by npm install adds 16 bundled start-core entries that the SDK bump removed. The packaging guide requires another install after the SDK bump until the lockfile stops changing. The proposal contains only that generated lockfile normalization, with no dependency pin or application-code changes; subsequent installs leave it unchanged.

Proposed changes: 719039d...proposal/157

Verification: head merges cleanly with master; SDK 3.0.4 equals npm latest; all applicable CI jobs passed (x86 and ARM builds, matrix discovery; retarget build skipped). Clean install, direct TypeScript check, changed-TypeScript formatting, ncc bundle, and ten focused mocked tests of the actual pinned helper passed. The normalized proposal also passes clean install, lockfile fixed-point comparison, TypeScript check, and ncc bundling. No VM migration or actual Tor attachment was exercised. The PR branch was not modified.

Helix-Harness: pi
Helix-Model: openai-codex/gpt-6.1-sol