Skip to content

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

Open
helix-nine wants to merge 5 commits into
masterfrom
next
Open

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

Conversation

@helix-nine

@helix-nine helix-nine commented Jul 4, 2026

Copy link
Copy Markdown

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:10.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.dockerTaglundog/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 citsc → SDK lint → nccs9pk 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
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).
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).
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant