bvandeusen
d77a79859c
A self-hoster should not need an account on someone else's forge to get the app
for their own notes. The Fabled-Git instance is private — which is why
`install.sh` already cannot fetch for anyone but the operator — so a release page
is no use as a distribution point. The server holding the notes is something the
person already trusts and already reaches.
It also keeps the pair in step by construction. Client and server negotiate a
sync protocol version before linking, so a server that also serves the client
cannot hand out a phone it is unable to talk to.
**Two files, and both must be present**: `thoughtsync.apk` and a
`thoughtsync-android.json` sidecar carrying `{version_name, version_code, size,
sha256}`. The sidecar exists because an APK keeps its version in a binary AXML
manifest, which Python cannot read and which is not worth putting `aapt` on a
Quart server to reach. CI writes it beside the APK, where the values are already
known — including the digest, computed over the same bytes it uploads, so a
phone can tell a truncated download from a complete one before handing it to the
installer. Not a trust anchor; the signature is that.
**Under DATA_DIR, not baked into the image.** Baking charges ~55 MiB to every
self-hoster including everyone who never touches Android. `/var/thoughtsync` is
already the mounted volume that holds attachments, so a build dropped there
survives container recreation.
**Absence is an ordinary state, not an error.** No APK means the key is absent
from `/api/config` — absent rather than null, so a client testing for it cannot
confuse "this server has no client" with "this server predates the field" — the
web UI hides the card instead of offering a button that 404s, and the metadata
route answers 404. A server whose owner does not use Android is not misconfigured.
**A mismatched pair also counts as no client.** If the sidecar's recorded size
does not match the file on disk, the two did not arrive together; serving one
build while advertising another is worse than serving none, because the phone
would compare versions against a promise the bytes do not keep. That makes the
copy order in docs/android-distribution.md load-bearing, and it is written down
there: APK first, sidecar last.
**The version is public, the bytes are not.** An updater has to be able to ask
"is there something newer?" cheaply and before it has done anything; 55 MiB is
not for anyone who can reach the port. `login_required` already accepts either a
session cookie or a device bearer token, so the browser and a linked phone both
work with no second auth path.
The Android lane now publishes both files to the same rolling `dev` release the
desktop bundles use, reusing `publish-release.sh` — its nullglob asset list was
already built for several jobs in separate workspaces publishing to one release,
which is exactly this. Signed builds only: publishing an unsigned APK would offer
people something they cannot install over what they already have.
Nine tests, DB-free like the rest of the suite — this lane runs no Postgres, so
the advertisement is asserted through `advertisement()` rather than through
`/api/config`, whose other half needs a database. Both routes ARE exercised,
because neither opens a session.
ThoughtSync desktop (Tauri v2)
Local-first desktop client. The window loads the shared Vue 3 frontend from
../frontend; the Rust core (src-tauri) owns the on-device store and the opt-in
sync engine (built out across the M10 milestone). Works fully offline; optionally
syncs to a self-hosted ThoughtSync server.
Layout
desktop/
src-tauri/
Cargo.toml
build.rs
tauri.conf.json # frontendDist -> ../../frontend/dist, devUrl :5173
capabilities/default.json
src/
main.rs # thin shim -> lib::run()
lib.rs # tauri::Builder entry point
The Vue frontend is the sibling ../frontend package, shared with the web
build. On desktop it is backed by a local data source via
frontend/src/adapters/ (M10.3) instead of the server REST API. frontend and
src-tauri are siblings, not nested, so the beforeDev/beforeBuild
commands cd "$(git rev-parse --show-toplevel)/frontend" to resolve regardless of
the CLI's working directory.
Prerequisites
The toolchain (Rust + Node + WebKitGTK 4.1 + tauri-cli) is provided by the
ci-tauri CI image. For local dev: install Rust + Node, cargo install tauri-cli,
and the Tauri v2 Linux system deps — see CI-tauri/Dockerfile in the CI-runner
repo for the exact apt list (libwebkit2gtk-4.1-dev, libgtk-3-dev, librsvg2-dev,
libayatana-appindicator3-dev, libxdo-dev, patchelf, ...).
Dev
cd desktop/src-tauri && cargo tauri dev
beforeDevCommand starts the Vite dev server (port 5173) in ../frontend.
Build (Linux)
cargo tauri icon "$(git rev-parse --show-toplevel)/frontend/public/icon.svg"
cd desktop/src-tauri && cargo tauri build # -> .deb + .AppImage
App icons are generated from the frontend's icon.svg via cargo tauri icon
(not committed; CI does this before cargo tauri build). Bundle targets: deb,
appimage (Linux-first; Windows/macOS later, no code changes expected).
Status
Scaffold (M10.2): boots the shared Vue UI in a native window. Until the local data
adapter lands (M10.3 + M10.5) the app has no server configured, so it shows the
login screen without a working backend — full offline functionality arrives with
the local SQLite store (M10.4) + adapters/local.ts (M10.5).