Skip to content

chore: migrate to start-sdk 2.0 and bump SimpleX Chat to 6.5.5 - #7

Closed
helix-nine wants to merge 6 commits into
masterfrom
next
Closed

chore: migrate to start-sdk 2.0 and bump SimpleX Chat to 6.5.5#7
helix-nine wants to merge 6 commits into
masterfrom
next

Conversation

@helix-nine

@helix-nine helix-nine commented Jul 4, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

start-sdk 2.0 migration + SimpleX Chat 6.5.5

Migrates this package to @start9labs/start-sdk 2.0 (requires StartOS 0.4.0-beta.10) and bumps the bundled SimpleX Chat client from 6.5.4 to 6.5.5. Package version 0.2.0:1 → 0.2.1:0.

start-sdk 2.0 migration

  • SDK pin → 2.0.1, TypeScript → ^6, tsconfig.json extends the shipped tsconfig.base.json, Makefile includes the SDK's s9pk.mk (vendored copy removed), reusable CI workflows repointed to Start9Labs/start-technologies.
  • 2.0 API migrations as applicable: sdk.serviceInterface.* → sdk.host.* resolved over the LXC bridge, lazy SubContainer, alerts manifest field removed, and other ### Changed / ### Removed items from the SDK 2.0 changelog.

Upstream bump — SimpleX Chat 6.5.5

  • images.simplex.source.dockerTag → lundog/simplex-chat:6.5.5 (multi-arch amd64 + arm64 confirmed on Docker Hub).
  • Highlights from v6.5.5: initial support for supporter badges, and a fix for files without an extension being saved with a trailing dot. Patch-level upstream change; no state migration required.
  • Release notes updated across all five locales in startos/versions/current.ts.

Test plan

  • CI build is green (npm ci → tsc → SDK lint → ncc → s9pk pack).
  • Install the built simplex-websocket-bridge_x86_64.s9pk on a StartOS 0.4.0-beta.10 server.
  • Start the service; confirm it reaches its health check and its primary interface comes up.
  • Configure/generate an API key and connect a WebSocket client through the bridge with the bearer token; confirm it can reach the headless SimpleX Chat client (send/receive a message).
  • Confirm the running client reports SimpleX Chat 6.5.5.
  • Upgrade path: install the prior 0.2.0/0.1.x build, then upgrade in place to 0.2.1:0; confirm existing profile/data volume (.simplex, media folder) survives and the service restarts healthy.

🤖 Generated with Claude Code

@helix-nine helix-nine changed the title chore: migrate to start-sdk 2.0 chore: migrate to start-sdk 2.0 and bump SimpleX Chat to 6.5.5 Jul 4, 2026
@lundog lundog mentioned this pull request Jul 4, 2026
Merged
helix-nine added 3 commits July 9, 2026 15:18
@helix-nine
chore: bump start-sdk to 2.0.3
4935e97 
Bumps @start9labs/start-sdk 2.0.1 -> 2.0.3 (dependency and lockfile only).

- 2.0.3 fixes a dependency-gated daemon wedging permanently after its
  dependency's readiness flaps: Daemon.term() unconditionally destroyed the
  daemon's SubContainer, so the next start() threw "already destroyed" and the
  daemon never recovered. Adds a non-destroying Daemon.stop() for
  dependency-driven pauses, and serializes pause/resume transitions.
- 2.0.2 runs s9pk.mk's check-deps before packing, not just before install.

No packaging API changed between 2.0.1 and 2.0.3, so no source changes were
needed. Verified with `npm run check` (tsc --noEmit).
@helix-nine
chore: bump start-sdk to 2.0.5
1ad32ee 
Bumps @start9labs/start-sdk 2.0.3 -> 2.0.5 (dependency and lockfile only).

2.0.5 fixes ExVer range operations ignoring the downstream revision:
compareVersionRangePoints and adjacentVersionRangePoints compared the upstream
twice, so two points sharing an upstream but differing downstream (1.0.0:3 vs
1.0.0:15) collapsed into one. normalize() then dropped the lower of the two,
which made packed manifests advertise a canMigrateFrom/canMigrateTo range
narrower than the truth for any package whose `other` versions share current's
upstream. No upgrade path actually broke — StartOS resolves migrations through
the version graph rather than this field — but the manifests were wrong.

No packaging API changed, so no source changes were needed. Verified with
`npm run check` (tsc --noEmit).
@helix-nine
fix: repoint to the renamed bridge image and pin the file-exchange paths
ce455c6 
Two naming mismatches, one of them a silent data-path bug.

1. The image and its source repo were renamed upstream (image revision 6.5.5-2):
   lundog/simplex-chat -> lundog/simplex-websocket-bridge, and
   lundog/simplex-chat-docker -> lundog/simplex-websocket-bridge-docker. The
   GitHub repo redirects; the old Docker Hub repo does NOT — it is frozen at
   6.5.5-1 and gets no further builds. Repointed the pin to
   lundog/simplex-websocket-bridge:6.5.5-2.

   Verified 6.5.5 -> 6.5.5-2 is functionally a no-op for the running container:
   across that range the entrypoint changed only three echoed log strings, the
   Dockerfile changed only an OCI label, and the image configs (HOME, entrypoint,
   workdir, user) are byte-identical. Note the new repo's unsuffixed `6.5.5` tag
   is the -2 build, NOT the same digest as the old repo's `6.5.5` — so the
   explicit revision is pinned to stop the tag shifting underneath us.

2. The file-exchange contract was broken by the 6.5.5 bump and would have shipped.
   The bridge takes its inbound/temp dirs from SIMPLEX_INBOUND_DIR /
   SIMPLEX_TMP_DIR, which this package never set — it relied on the image's
   defaults. Through image 6.5.4 those defaulted to /simplex/{inbound,tmp}, which
   is exactly where our `/simplex` mount (the volume's .simplex/media subpath)
   expects them. Image 6.5.5's "file/profile config rework" changed the defaults
   to $HOME/.simplex/{files,tmp} — outside that mount.

   So on 6.5.5 the bridge writes received files to .simplex/files while /simplex
   points at .simplex/media, which it never touches. A consumer mounting
   .simplex/media/inbound sees an empty directory, and nothing errors. main.ts now
   passes both variables explicitly (/simplex/inbound, /simplex/tmp), restoring
   the 6.5.4 paths — so no data moves and no migration is needed. inbound and tmp
   stay siblings in one mount, preserving the atomic temp->files rename (separate
   mounts would EXDEV-fail).

   This only ever affected 0.2.1:0, which is unreleased (alpha, beta and prod all
   carry 0.2.0:0 on image 6.5.4), so 0.2.1:0 is amended in place rather than
   superseded.

Also records both traps in UPDATING.md — bump from the image tag list rather than
the SimpleX release list, and re-check the image's file-exchange defaults on every
bump — and refreshes the stale image names in README.

Verified with `npm run check` (tsc --noEmit); the new tag resolves via
`docker manifest inspect`.

Note: startos/actions/api-keys.ts has pre-existing prettier drift, untouched here.
@lundog

lundog commented Jul 17, 2026

Copy link
Copy Markdown
Contributor

Heads-up from testing this on hardware: a package packed with start-sdk 2.0.x does not start on my StartOS.

On my box (StartOS 0.4.0-beta.9) a 2.0.x-built s9pk hangs during startup — init runs to completion but the service never proceeds to main. I verified with logging around every init step:

Initializing...
[init-debug] seedApiKeys (kind=install)
[init-debug] setInterfaces: start
[init-debug] setInterfaces: store read done
[init-debug] setInterfaces: bindPort done
[init-debug] setInterfaces: export done
[init-debug] setDependencies: start
[init-debug] setDependencies: read done (mode=null)
[init-debug] all init steps done (kind=install)
   <hangs here — "Starting …" from main never prints>

Reproduced on a clean install (not just update-over), and with the unmodified next branch as well as my own branch — so it isn't package-specific code. It looks like the container-runtime on StartOS 0.4.0-beta.9 doesn't drive the 2.0.x package lifecycle: init is backward-compatible enough to run, but the main/DaemonBuildable handoff (which the start-sdk v2.0.4 notes describe as a breaking setupMain/Daemons ABI change) is never issued.

Is this just something wrong with my box?

In the meantime I've retargeted my feature PR to master on start-sdk 1.5.3 so it can ship on current StartOS; happy to rebase it forward onto the 2.0 line once I figure out the issue.

@MattDHill

MattDHill commented Jul 17, 2026

Copy link
Copy Markdown
Contributor

Correct. SDK 2.0 packages require startos beta.10. It is available from the OS registry now (or by downloading from github actions), and will be published to the main registry later today.

@helix-nine

helix-nine commented Jul 17, 2026

Copy link
Copy Markdown
Contributor Author

Thanks @MattDHill — that matches what I'm seeing, and since this PR is the start-sdk 2.0 migration, beta.10 is exactly its target.

To confirm the lifecycle @lundog flagged actually completes on beta.10, I built this branch's s9pk (start-sdk 2.0.5) and installed it on a beta.10-class host (start-os master, d1e8373, 294 commits past beta.9):

  • main handoff works — no hang after init: Initializing… → Initialization complete. then Starting SimpleX Websocket Bridge! → Launching simplex… → simplex-chat listening → websocat bridge 0.0.0.0:5225 → ws://127.0.0.1:5226 → container ready → Launching websocket…
  • statusInfo: health.websocket = success ("Websocket is ready"), error: null, desired.main: running.
  • Running client reports SimpleX Chat v6.5.5.0.

So the beta.9 hang was the beta.10 requirement you described, not anything package-specific — the daemon/setupMain handoff is issued on beta.10 and the service comes up healthy.

CI is green and this is ready to land once beta.10 is in the main registry. One coordination note: merging #7 moves master to the 2.0 line, which would sit ahead of @lundog's 1.5.3 feature PR (#6). Happy to sequence it whichever way you prefer — merge now, or hold until #6 lands and rebase it forward onto 2.0.

@helix-nine
chore: bump start-sdk to 2.0.6
e211668 
Bumps @start9labs/start-sdk 2.0.5 -> 2.0.6 (dependency and lockfile only).

2.0.6 fixes s9pk.mk failing under `make` in a git repo with no index yet: it
listed $(GIT_DIR)/index as an unconditional prerequisite, but `git init` creates
no index until the first `git add`, so a freshly scaffolded package aborted with
"No rule to make target '.git/index'" before packing. GIT_DEPS now filters
through $(wildcard ...), so a missing HEAD or index drops out of the prerequisite
list instead of halting the build (s9pk pack already handles a commit-less repo).
Build plumbing only.

No packaging API changed, so no source changes were needed. Verified with
`npm run check` (tsc --noEmit).
@helix-nine helix-nine mentioned this pull request Jul 21, 2026
Merged
9 tasks
@helix-nine

helix-nine commented Jul 21, 2026

Copy link
Copy Markdown
Contributor Author

Superseded by #8, which ports the merged 0.3.0 feature release (#6) to start-sdk 2.0. This PR migrated the older 0.2.0 base and is stale against current master (0.3.0).

@helix-nine helix-nine closed this Jul 21, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@helix-nine @lundog @MattDHill