This release follows the Cloud tester report through publishing, attachment limits, cross-device sync, and backup recovery. Updating a public note is easier to find, slow publications get time to finish, incoming changes reach the open app sooner, and restoring a backup updates the editor as well as the files. Release PR: #774.
🐛 Fixes
- Publishing gets time to finish. Publishing or updating a note with attachments can now run for up to five minutes. If the connection fails before the app can confirm the result, the dialog explains that uncertainty and keeps any existing public link available. It does not claim the latest edit is live or automatically create a second share.
- Update a public note from Cloud Settings. Settings → Cloud → Published notes now has Update note, which uses the latest note content, including unsaved edits. Refresh list checks publication status; it does not publish your private edits. The labels and explanation make those actions distinct.
- Incoming edits arrive sooner. While the desktop is active and online, a lightweight check looks for remote changes every five seconds. It fetches metadata, avoids overlapping automatic runs, and backs off after failures. The slower full-vault scan remains in place.
- Restoring a backup refreshes the open note. A restore could put the correct files on disk while the editor kept showing the newer text. Open notes now refresh to the restored contents. Delayed file reads also stop short of replacing a newer read, a local save, or unsaved edits.
- File-limit errors use the right units. Cloud limits now use decimal MB: a 10 MB limit means 10,000,000 bytes. Oversized-file guidance explains that the file must be reduced or removed before sync can complete.
How to check locally: use a disposable linked vault. Edit a published note and choose Update note in Cloud Settings; verify the same public link shows the latest text. Change a note on another device and leave the desktop open to receive it. Create a backup, change the note and an attachment, add another file, then restore: the old content should return and the newer file should disappear without reopening the note.
🧰 For contributors
- Sources:
f569626a(publishing, limits, incoming sync),d997f373(restore and read-order guards), and104416f5(2.50.0). All eight workspace versions and lockfile metadata agree; dependencies are unchanged. - Validation: 4,386 automated tests passed, with five skipped; all seven workspace typecheck tasks, the desktop build, and packaged CLI validation passed. Five restore/read-order regressions failed before their fixes and passed afterward. All seven PR checks passed.
- Real macOS Electron testing against production Cloud verified 8.1 MB, 8.7 MB, and exact 10 MB uploads by hash; oversized-file recovery; interrupted-upload recovery; publication updates and unpublish; conflicts; and backup restore. Incoming text appeared in one measured run after 5.068 seconds. This is an observation, not a latency guarantee.
- A controlled HTTP server verified a committed publication response delayed for 31 seconds. Production publishing completed normally. Later native iPhone and Android testing verified an eight-file restore with matching hashes across all three apps. Disposable Cloud resources were removed.
- Released September 14, 2026 from merged PR #774. The published macOS download passed signature, Gatekeeper, notarization, and packaged-app launch checks. All 25 release assets and all four updater manifests were verified. Live desktop UI coverage was on macOS.
Local-first and keyboard-first, as always.