bvandeusenandClaude Opus 5.5
2b2ceaa82e
Desktop could not create an attachment at all, and a removed attachment or dismissed preview came back on the next pull. Now: - core: add_attachment keeps the bytes in the blob store and queues the row (schema v10: attachments.uploaded / upload_error). Push uploads it once its note has landed. A refusal that retrying won't fix (too large, id clash, hash mismatch) is recorded on the file and not re-sent every cycle; the editor shows it. - core: removing a synced attachment or dismissing a preview leaves a tombstone in pending_deletes; push sends it as an `attachment`/`preview` delete, and a pull while it waits doesn't put the row back. A pull also keeps files still waiting to upload instead of replacing them wholesale. - server: PUT /api/sync/attachments/<id> (raw body, sha256-checked, idempotent, size-capped) and child deletes in push, which apply regardless of LWW and answer noop for rows the caller can't see. One store_attachment helper for the upload route, the importer and sync. Protocol 5, feature attachment_sync; the client sends neither to a server without it. - server: migration 0031 makes a link preview's insert/delete bump its note, so background-fetched previews and web dismissals reach linked devices. - desktop: Attach and paste-image work offline (raw-bytes IPC command). - SVG is served as a download by the desktop blob scheme too (as #1981 did for the web), and drawn as a file chip on both. - autosync: drop the catch_unwind; release builds abort on panic, so it only ever worked in debug builds. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Inkwell 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 Inkwell 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)
cd desktop/src-tauri && cargo tauri build # -> .deb + .AppImage
App icons are generated and committed: python3 packaging/icons.py draws the
inkwell mark once and renders every web, desktop and Android icon from it,
including app-icon.png and icons/*.png here. The Windows lane derives its
.ico from app-icon.png with cargo tauri icon at build time. 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).