obsync 1.1.6

obsync 1.1.6

What changed

Added

• A native Rust management CLI with kubectl-style command groups, readable
  human output, explicit JSON, schemas and offline capability discovery.
  Local contexts use bounded snapshots, exact plans and durable apply receipts.
  Default OS settings and context add/list/use/remove aliases shorten setup;
  terminal changes ask for confirmation, while agents retain exact plans.
• Verified native archives for Linux amd64/arm64, macOS arm64 and Windows amd64.
  Installation verifies a private immutable directory. After verified uninstall,
  a newer package can reuse the same path; uninstall preserves contexts.
  No Node runtime ships or is required.

Server authentication, native setup, device administration and MCP follow in
later slices. Export/open is deferred with #317 and returns unsupported.

Install or update

In Obsidian: Settings -> Community plugins -> Browse -> Self Hosted Private Sync,
or Check for updates if it is already installed. Obsidian takes the plugin
files from this Release.

The server is a separate upgrade and nothing forces it: deploy the image below
BY DIGEST, keeping both volumes, and the journal replays into the new binary.

Supply-chain evidence

Artifact	Reference
Image	ghcr.io/snaraj/obsync:v1.1.6@sha256:0aa283067859cea4e2529f8832d578e68cae5bd6ee316bd909569ae28c6c80de
Chart	ghcr.io/snaraj/charts/obsync:1.1.6@sha256:3be1d6e3f8ecfd0d6159f8e687eab36ffc2582fd2366efd48eb02f1f1c26a7ed
Plugin	obsync-plugin-1.1.6.zip (sha256:342551bbcb1579b6261768af6ab572e5d6d34d87bfb3643bef48e6c53c4c1995)
Server (linux/amd64)	obsync-server-1.1.6-linux-amd64.tar.gz (sha256:f03b342f449235914cbcd79165f3515c0255c34360ea572a224d836c662d9d2e)
Server (linux/arm64)	obsync-server-1.1.6-linux-arm64.tar.gz (sha256:9ab1b4acfacee1ce64d3161727460e8b1b6f876002bff740e00b0043f00f3437)
Native CLI (linux-amd64)	obsync-cli-1.1.6-linux-amd64.zip (sha256:cb5455bd52a26d08386cd306cec62f1bebdb0e91dd1ba79c6e274424721d1d25)
Native CLI (linux-arm64)	obsync-cli-1.1.6-linux-arm64.zip (sha256:0f69e2722d4b39217c9355ad8350dcfe2ee094a4ee70fb5db61c8ae940464536)
Native CLI (darwin-arm64)	obsync-cli-1.1.6-darwin-arm64.zip (sha256:7339b17ca47828ac7e2e47026f2b24b427ec42b53e9172b20c92a8d86a056db1)
Native CLI (windows-amd64)	obsync-cli-1.1.6-windows-amd64.zip (sha256:02d6fe4c4192da5164f73e359de0b307a7a3c6aa753a726d625e630cde8599fd)

Image and chart are signed with keyless Cosign by this workflow identity.
The plugin files, server archives and native CLI archives carry this workflow's build provenance (gh attestation verify).

Publication evidence: obsync-1.1.6-release-manifest.json (sha256:e10847d49541a81252e3f8bd0d978fce798d37cc21ce73c94b5d3f945156201b).

obsync 1.1.5

obsync 1.1.5

What changed

1.1.5 fixes the issues left open when 1.1.4 was released (#238 to #241, #244
to #248, #253) and those found while testing it on real computers and an
Android emulator. Two people typing in one note on a busy computer now keep
each other's words (#227). Pairing a new device gains a key exchange of its
own that a copy of the code cannot open or fake, and needs 1.1.5 on both
devices; your server keeps an account's only device for seven days after a
recovery key is registered. In testing, changes from other devices sometimes
stopped arriving on a computer while it read idle. One cause is found and
fixed: closing obsync's settings in Obsidian 1.13 (#302, #307). For any
other, 1.1.5 says what the changes wait for, so that a report can find it
(#276).

Update the server first, then every device. A 1.1.5 device keeps syncing
with a 1.1.4 server, and a 1.1.4 device with a 1.1.5 server; the notes below
say where a mixed pair behaves differently. Pairing is the exception: to pair
a new device, the server and both devices need 1.1.5.

Before you update

• Pairing needs 1.1.5 everywhere. A 1.1.5 device pairs only with
  another 1.1.5 device, through a 1.1.5 server. It refuses a code made on an
  older device, and a claim from one, and says to update that device: the
  older pairing lets anyone who saw the code open your vault key. Devices
  already paired keep syncing across versions.
• Volume sizes. The server now refuses to start, naming the variable,
  when OBSYNC_BLOBS_CAPACITY or OBSYNC_JOURNAL_CAPACITY is not larger
  than its free-space reserve (OBSYNC_FREE_WATERMARK, by default the
  larger of 5% and 2 GiB). A 1 GiB or 2 GiB journal is the usual case.
  Declare more (the guides use 4GiB for the journal, or
  storage.journal.size: 4Gi in the chart), or, with docker run or
  systemd, lower OBSYNC_FREE_WATERMARK below the size you declared; the
  chart and the Compose file do not expose it. Up to 1.1.4 such a server
  said it was ready and refused every write to that volume (#289).
• Pairing needs the server updated first. Through a server older than
  1.1.5, Pair a new device on a 1.1.5 device makes no code and says to
  update the server.
• Forget and the new device count need a 1.1.5 server. An older one says
  it is too old to forget and changes nothing, and still counts revoked
  devices. A device still on 1.1.4 lists a forgotten device as revoked
  (#247, #268).
• Going back to 1.1.4 on a device erases the new notification settings,
  which are back at their defaults when you update again, and drops what
  1.1.5 had still to finish: a renamed Sync folder's removal
  not yet sent (#265); where a note went while it was outside Sync folders,
  so 1.1.4 publishes it as a new note, as it always did (#239); and notes
  1.1.5 was still bringing back after you added a Sync folder (#281).

Your notes stay safe

Two people typing in one note keep each other's words, even on a busy
computer and with a third device showing the note. Up to 1.1.4 the last
words one person typed could land in a conflict copy. A device now sends
what you typed before it merges, remembers the history it has been shown,
and no longer counts the wait for its own late save toward giving up on
merging. With three Obsidian instances each frozen for 45 s while two of
them typed, runs that made a copy went from 2 in 10 to none (#227, #278).
obsync also times its guard against other plugins from a version it really
wrote into the note, so your own late save on a very busy computer no longer
pauses the note (#278). Update every device: one still on 1.1.4 can still
make such a copy. Words that went into one are in <note> (conflict from …)
beside it (Troubleshooting, "Words typed on two devices at once went into a
conflict copy").

A phone stopped in the middle of a download never sends the empty file it
left. Android can finish writing a downloaded note but leave it empty, and
obsync writes it again (#242). If Android closed the app between the two,
the next start sent the empty file: the note became empty on every device,
or an empty conflict copy appeared. The next start now recognises the
unfinished download and writes the version over it, so the other device's
text stays. A note you empty on purpose still syncs as empty. Seen on
Android (#248).

A phone never trashes a folder for a note deleted elsewhere. When
another device deleted a note and a phone held a folder under that note's
name, the phone moved the whole folder, and everything in it, to the trash.
It now refuses, as a computer does, says so once, and keeps the folder and
its notes. Android and iOS (#284).

Notes from your other devices show in Obsidian at once, even on a busy
computer. Up to 1.1.4, on a Mac whose file-event service was overloaded, a
note obsync downloaded could be on disk and synced but missing from
Obsidian's file list, search and quick switcher until a restart, and a note
renamed or deleted elsewhere could stay listed under its old name. obsync
now tells Obsidian itself about the notes and folders it writes, moves or
deletes, and search, backlinks and other plugins see a note's new words as
soon as they land. A note open in an editor shows them at once, and its
search entry catches up at your next edit there: obsync never reloads an
editor you are typing in. Computers only; nothing to do (#253, #267).

Leave on a phone no longer counts notes your other devices already have.
Obsidian on a phone can keep an old size for a file obsync downloaded, so
Leave listed synced notes as changes the server never received, and every
check read them again. The phone now asks its storage about such a file
(#245).

Pairing, recovery and your devices

Pairing a new device is safer, even if someone saw the code. Besides
the pairing code, the two devices make a one-time key exchange, and your
vault key travels sealed under both, so a copy of the code alone no longer
opens it. The code also carries a fingerprint of the key the device that made
it will use, and the six-digit match code both screens show is made from
both devices' keys, so someone who saw the code and sits between your
devices and your server cannot make the two screens agree. Approve only when
they do. Both devices and your server need 1.1.5: a device running an older
obsync is refused with the words to update it, whichever device made the
code, because the older pairing lets the code alone open your vault key.
Keep typing the code into the other device rather than emailing or messaging
it. The device that made the
code says "paired" only once the new device has kept the key and started
syncing, and tells you plainly if it did not; a new device that starts
syncing the second it signs in is no longer reported, ten minutes later, as
not started (#290). Devices already paired are not affected.

Your notes stay private on a network that inspects your traffic, and a
test now proves it. On a work laptop, or behind a VPN that decrypts
traffic, that network can see that you sync, how big your files are and
when, but never your notes, their names, your vault key or your recovery
words. A new test records a whole session as such a network sees it and
finds nothing readable. A device's secret for your server does cross the
network when you set the device up or pair it, so do both on a network you
trust (Troubleshooting, "Pairing on a network you don't control").

Your server keeps an account's only device for seven days after a
recovery key is registered, including right after you set up a new
account. Leave on that device says why and offers Leave on this device
only; or pair another device first. Every other device leaves as before.
A recovery key registered before 1.1.5 keeps the older rule, and a 1.1.4
server applies no hold.

A device that finds a different recovery key on your server warns you.
The warning stays until you dismiss it, and at the top of Show sync
status and of obsync's settings until it is resolved. Revoke any device
you do not recognise, then ask whoever runs your server to run
obsyncd recovery reset plan and then obsyncd recovery reset apply with
the server stopped. Your device then registers its own key by itself, and
your notes stay encrypted throughout (Recovery, "Another device set a
different recovery key").

The same reset lets an owner with no working device back in. It also
replaces the setup token: the old one stops working, and obsyncd setup-token prints the new one after the next start. With it and your 24
words restored on a device, Setup or recover enrols that device once.
Without a reset, an account with no recovery key still refuses, and its
message now names both ways in: pair from a device that syncs, or ask for
the reset. The recovering device may still run 1.1.4 (Recovery, "Getting
the owner back in after a clear").

Revoked devices no longer crowd your device list. In Settings, Devices,
and on the dashboard's Devices page, the devices that sync come first, and
the revoked ones wait behind one row, such as "12 revoked devices", that
Show opens. Each revoked device offers Forget, which asks first and
takes it off the list for good. Forgetting destroys nothing: the device
still cannot sync and says so, your notes stay, and the versions it wrote
keep its name. To bring it back, pair it again. The device count on the
dashboard's Overview and in Check now counts only devices that can sync
(#247, #268).

A dashboard sign-in link still opens once, within five minutes. Obsidian
may write the link it opens to its own log; the dashboard's security notes
now say so, and why a copy opens nothing once used or after five minutes
(#270).

Notices and the status

You choose how much obsync tells you. In Settings, obsync,
Notifications, from the command palette, or with
obsidian obsync-private-sync:notices (Obsidian 1.12.2 or later): ...

obsync 1.1.4

obsync 1.1.4

What changed

1.1.4 fixes the issues that were open when its scope was set on
2026-09-27 -- found by people running obsync and by a review of the whole
plugin and server -- and those found while testing it on real computers,
phones and CI runners until then, with three found after (#242, #243, #252).
One is better but not fixed: two devices typing in one note for a long time
can still, on a very busy computer, move one person's line into a conflict
copy, which keeps it (#227, below). Issues found after the scope was set
wait for 1.1.5 (#238 to #241, #244 to #248, #253). Among them: on a Mac whose
file-event service is overloaded, Obsidian may not list a note obsync
downloaded until it catches up or restarts (docs/troubleshooting.md, "A
note that synced does not show in Obsidian").

Update the server and every device; each works with the other's 1.1.3
meanwhile, and the notes below say where a mixed pair behaves differently.

Before you update

• Docker Compose asks how much space obsync may use:
  OBSYNC_BLOBS_CAPACITY (such as 200GiB) and OBSYNC_JOURNAL_CAPACITY
  (such as 4GiB). Until both are set, Compose refuses to start and names
  the missing one.
• The Helm chart no longer guesses your ingress peer or storage class. An
  install that relied on the old defaults sets ingress.peers and
  storage.*.className; until then it fails closed instead of deploying.
  The memory request rises from 64Mi to 128Mi (the limit stays 1Gi). Its
  two platform annotations (<domain>/deployment-ready,
  <domain>/volume-capacity) now appear only when you set
  platform.annotationDomain. A platform whose policy reads the keys
  releases up to 1.1.3 rendered sets it to their prefix,
  platform.snaraj.dev, in the same change that selects 1.1.4; the 1.1.3
  chart refuses the new key, so it cannot go in earlier.
• If you copied the Kubernetes guide's TLS front, give its proxy_pass
  name a trailing dot (obsync.obsidian.svc.cluster.local.): without it,
  nginx can fail to start where the cluster's search domains are tried
  first, as in an IPv6-only cluster. In a dual-stack or IPv6-only cluster,
  also uncomment its listen [::]:8443 ssl; line (#226).
• Behind a proxy or tunnel, the server believes forwarding headers only
  from addresses in OBSYNC_TRUSTED_PROXY_CIDRS (in cloudflare mode, the
  private networks when it is empty). A connector on a public address must be
  listed there, or every request answers 421. A /0 entry stops the server at
  start.
• If you copied obsync's nginx configuration, copy it again, or make its
  two lines read listen 8443 ssl http2; and error_log stderr;. The old
  file does not start on nginx 1.24 (Ubuntu 24.04) or under systemd (#215).
• obsyncd export takes the key from --key-file <file|->, a regular file
  with mode 600. --key still works and warns; it goes in a later release.
• Custom request headers (formerly Edge service-token headers): a line
  saved by 1.1.3 that a request cannot carry now stops each request with a
  message naming it, instead of being dropped without a word (#183).
• Pairing: update the server as well as the plugins. Only a 1.1.4 server
  removes a device that was approved but never collected the vault key (#153).
• Going back to 1.1.3 on a device drops two things 1.1.4 keeps in the
  plugin's data file: a pending folder selection (#185) and deletions held for
  your answer (#162). A held deletion is then published at the next start
  unless the share rule holds it.

What the status bar tells you

The status bar is one steady icon. It no longer jumps while you type:
a check when this device is up to date, a turning wheel while it syncs, a
cloud struck through while the server does not answer, an alert when sync
needs you, and a pause sign for a paused note. Hover it for the words; click
it for Show sync status, which stays current and offers the next step.
Every command ends in "(obsync)", so the palette finds them all (#156).

Phones and tablets show the same icon in the header of the note you have
open; tap it for Show sync status. A problem that needs you is also said
once in a notice. Android, iOS, iPadOS (#209).

The status tells you what is really going on. Receiving or sending many
notes reads syncing with a count that goes down, a device starts on
"checking for changes", and "offline — retrying" clears as soon as the
server answers (#158).

A note waiting for your typing is named. "syncing 1 file" goes on
", waiting for unsaved changes in" and the note's name, and Show sync status
says its newer version follows once that typing is saved (#252).

A refusal says what it is, the first time. A removed device, a wrong
clock, a full server or a proxy answering instead of obsync each say what
happened and what to do, and clear by themselves once fixed; if Obsidian
started while one was so, it says to select Sync now once it is fixed,
because nothing tries a refused start again on its own. Repair no
longer sends you to check your network, and after a new vault key an unsent
edit is sent once under the new key with one notice (#155, #160, #177).

Check, the device list and Sync now answer quickly and in plain words.
No more 0 unreachable: network=… after a minute's wait (#182).

An untrusted server certificate is named as one. Check, the status, Show
sync status, setup and pairing say "This device does not trust your server's
certificate, so it refused the connection" and point to the troubleshooting
entry with each device's steps. Sync keeps retrying and resumes once the
certificate is trusted. Seen on desktop; phones are matched by their own
wording for the same failure (#201).

A certificate for another name, or out of date, is named too. Check,
the status, Show sync status, setup and pairing say which it is and what
to do, instead of "nothing answered" and the struck-through cloud. Sync
keeps retrying. Seen on desktop; phones are matched by their platforms'
documented wording, not yet seen on a device (#229).

A device kept out by your server's edge says so. Before, only a first
pairing said why. The status, Show sync status and Check now say the
request did not come through the edge, and to check the Server URL, the
Custom request headers and the route to the server, in pairing's own
words (#228).

Settings no longer shows an old outage, and your devices are named, not
numbered. Each opening of Settings reads the device list itself, and "not
answering" goes by itself once the server answers. Show sync status and the
Pairing row name this device ("iPhone 5DMY"); the long device id stays,
smaller, in Show sync status for support (#152).

Faster

Sync picks up again the moment your network, the app or a new server
address comes back. The next attempt goes at once instead of after a pause
of up to a minute, or five minutes for a VPN (#134, #186, #195).

Your edits reach your other devices sooner. A note you are typing in is
sent about 150 ms after the editor saves instead of 0.9 s (another app's
writes keep the longer wait), a small edit takes two requests instead of
three, and the start no longer waits for its report to the server (#195).

A note you type while a big file moves now arrives in about a second.
Uploads no longer move in lock-step batches, and note-sized pieces have room
of their own. Versions over 32 MiB download beside other changes and are
written only once complete and still the newest; Show sync status says
"Downloading ". On the test fakes, 58 s became 0.3 s up and 62 s
became 0.2 s down; on a real iPhone a note arrived ahead of a 128 MiB file's
first piece (#196).

Large uploads run about twice as fast and do half the work. A file is
read and encrypted once (256 MiB: 44% less CPU), and 32 MiB instead of 8 MiB
may be on the wire: 71 → 134 MiB/s at 20 ms round trip. On a link that is
itself the limit the gain is small (200 Mbit/s: 20 → 23 MiB/s). If Obsidian
closes in the middle of a large upload, it may send up to 33 MiB again when
it reopens (up from 8 MiB) (#196).

Stopping sync no longer waits out a download. Leave, Save and quitting
end at the next piece instead of after up to 24 MiB. Nothing half-downloaded
is written (#196).

Adding a device to a large vault is many times faster. A 10,000-note
first sync rewrote obsync's data file 10,010 times (13.8 GB of writes) and
took about four minutes on the test fakes; it now writes it 10 times and
takes about 7 s in 175 requests. A phone holds at most 8 MiB of prefetched
notes, a computer 32 MiB (#194).

Copying a vault onto a new device no longer uploads it all again. A
copied vault of 1,000 notes published 668 versions and 650 deletions; it now
publishes none. A note the server also names waits at most ten minutes for
the device to catch up (#194). A device paired again after your other
devices edited while it was away holds those notes as it last saw them;
pairing takes each as the earlier version it is and uploads nothing, so it no
longer asks whether to add them to the server's vault either. All platforms
(#194, #141).

Attachments are recognised too, not uploaded again. A device paired
again after Leave, or a vault copied onto a new device, recognised its
notes but not its files over 8 MiB, such as photos, PDFs and recordings: it
published each one again under a new id, and your other devices retired one
of the two, which could leave a file's history under the retired copy. Such
a file is now recognised by reading it once and comparing it, piece by
piece, with the version the server holds; nothing is uploaded or
downloaded. A file that differs by one byte is kept beside the other, as
before. On a phone, a file above its per-file limit is not read to check it
and is handled as before. All platforms (#232).

An idle vault stays quiet. 4 requests instead of 3,186 per idle hour at
10,000 notes: repair ...

obsync 1.1.3

obsync 1.1.3

What changed

Turning obsync off and on during an upload no longer loses track of your
files, or deletes one. When you turned obsync off and on again in Community
plugins while a big file was uploading, the session you turned off went on
waiting for its upload and, a minute or two later, saved its older records
over the new session's. obsync then uploaded files that were already synced as
if they were new, and a 1 GiB file vanished from the computer that made it,
while the other computer kept it. Now only the newest session writes obsync's
records; one that was turned off stops and writes nothing more. A file whose
record was lost anyway -- a phone force-quit in the middle of saving it -- is
recognised at the next start as the one this device already uploaded, with no
new copy on the server. And when another device settles two copies of one
file, a device still tracking the retired copy keeps the file if the kept
copy holds the same bytes. Devices before 1.1.3 still apply that settling as
an ordinary deletion. Same on desktop and mobile (#181).

A server restored from a backup gets back what your devices did after it.
When the server was rebuilt from a volume backup, the changes made after that
backup stayed on the devices that made or received them. A new or reinstalled
device got the old vault. The others read idle, then showed "Server repair
could not verify a retained file ... check connectivity" for good. Each device
now notices that the server went back in time, when it reconnects or when its
repair pass finds a version gone. It re-sends the notes, renames and deletions
the server lost, and says once: "The server was restored to an earlier state;
this device re-sent N changes." A note another device changed on the restored
server is merged or kept beside the re-sent one, never replaced. A deletion is
re-sent only by a device that made or received it; each remembers its last
1000. A change made before a device updated to 1.1.3 is re-sent only when the
server lost the whole note. Same on desktop and mobile. (#145)

Moving or renaming a folder outside Obsidian no longer deletes its notes on
your other devices. A folder renamed in Finder or another file manager while
Obsidian was open reached the other devices as deletions: its notes vanished
there and, when the new folder was still synced, came back a second later as
new files with their history left behind; when it was outside Sync folders on
this device, they stayed deleted, with no word on either device. A deletion
now waits half a second for the rest of what Obsidian reports. A note whose
bytes are in the vault under a new name inside the selection is published as
the move it is, history and all; one outside the selection stops syncing from
this device but stays on the others, and one notice says how many notes left.
The same holds for a folder moved while Obsidian was closed, which could delete
a small folder on the other devices or leave a "Deletions held back" warning
whose Confirm button would have deleted notes that were right there: that
warning no longer counts a note found in the vault under another name, lets go
of one that turns up again within 30 seconds, and Confirm never deletes one
found under another name. A note you really delete is still deleted everywhere, half
a second later. Same on desktop and mobile: the check compares the names,
sizes and times Obsidian already holds in memory, and never opens a file
outside your selection (#139).

Held-back deletions wait for you, and a deletion is checked again before it is
re-sent. On a device set to sync selected folders only, the "Deletions held
back" check counted every note the device had ever recorded, including notes
outside those folders, so 12 of 20 selected notes gone while Obsidian was closed
were deleted on your other devices without a question. It now counts only the
notes in the folders this device syncs, and the notice gives that number. Once
deletions are held back, Sync now no longer sends them when some of the notes
come back: notes that return are let go of, the rest wait for Confirm
deletions, and Sync now says they are still waiting. And a deletion whose first
send got no answer was sent again tens of seconds later without looking again, so
a note restored in the meantime, or brought back by another device's edit or
rename, was deleted anyway and left split in two on the server. It is now checked
against the vault first and dropped when the note is back, and the device that
deleted it says why the note came back. Your other devices no longer claim to
hold "changes this device has not uploaded yet" when a note was deleted
elsewhere from an older version: they say the version they have is already on
the server and kept. Same on desktop and mobile. (#172, #173)

An edit that races a deletion stays as one current note. The kept edit now
incorporates the deletion into its history instead of leaving the deletion as
a second current version forever. Later saves do not meet that deletion again,
and a successful settlement shows no notice. Startup upload and restoration of
the kept edit wait for each other, so their race cannot leave two versions of
the same edit. Another device's unseen edit is still preserved for the ordinary
conflict rule. Same on desktop and mobile. (#178)

A note you are typing in stays when another device deletes it. When a
note was deleted on another device while you typed in it here, it vanished
from under your cursor: the tab turned into "No file", neither device said a
word, and what you had typed in the last second or two, and everything you
typed after it, went nowhere. Now a deletion does not remove a note that is
open in an editor here while it holds typing that is not saved yet, or while
this device has sent an edit of it in the last 10 seconds. The note stays, is
sent again so it comes back on the device that deleted it, without a repeated notice; what you type next follows it everywhere. A note nobody has typed in
here for longer than that is deleted as before, open or not. The deletion remains in history and successful restoration is quiet. Same on desktop
and mobile. (#146)

A note deleted on another device goes where your "Deleted files" setting
says. Since 1.1.0, on a computer, a note deleted on another device was
removed for good: it was in neither Obsidian's .trash folder nor the system
Trash, whatever Settings → Files and links → Deleted files said (found in
the 2026-09-24 scenario run). It now goes, under its own name, to the system
Trash, to the vault's .trash folder, or away permanently, exactly as that
setting says; if the system Trash refuses it, it goes to .trash, never
nowhere. The same holds for the old copy obsync clears away when another
device renames a note or when two notes collide and one is moved aside, so
your bin can now hold a copy of a note that is still in the vault under its
new name. Phones and tablets were never affected. A note removed this way on
1.1.2 or earlier can be brought back with Restore from history: search for
its name and select Restore a copy on its last version.

Two devices typing in one open note end up with the same note. Typing in
one note on two devices at once used to merge once or twice, then save nearly
every version the other device sent as a conflict copy, stop merging with
"resolved it more than 5 times in a minute", and leave the two devices holding
different text under one name, with a dozen copies or more on each, while both
said obsync: idle. Now text typed on different lines is merged, and
both devices end on the same note holding both texts, with no conflict copy.
When both devices add text at the end of the same line, their shared addition
is kept once and the different additions are joined in the same order on both.
Continued typing before text received from the other device also merges while
keeping the line's original characters. Shared merge ancestors are combined
first so text already present on both sides is not added again.
Changes that replace the same existing text still conflict: every device keeps
the same version as the note, and the other goes into one conflict copy that every
device holds, named after the device that wrote it, the time in UTC and a short
id. Nothing typed is lost, and the two notes never stay apart. A save made
while another device's version is arriving is never written over, and the
status bar no longer reads idle while a note is still being settled. Incoming
updates wait while this note has unsaved text or you have typed in it during
the last ten seconds, then retry automatically. Other notes keep syncing.
Attempts refused while you type no longer consume the merge limit.
Overlapping attempts wait at that limit while the editor is busy.
This prevents Obsidian's own external-change merge from rewriting an editor
while obsync is reconciling the same text. Delayed
upload receipts no longer put an older version back into the device's records.
Merges and editor uploads wait for one another's receipts before choosing
parents, including an upload that finishes while a merge is being prepared.
Adjacent line edits no longer need an unchanged line between them to merge.
Continued additions to neighboring lines remain independent after a shared
merge. A third device receiving both people's edits tracks their progress
separately, so it does not mistake their typing for a rewrite loop.
A freshly paired device no longer recreates resolved historical conflicts
when the server's file view has trimmed older parent links. Older feed entries
do not consume the loop limit, and one person can stop
typing while the other continues an independent edit. Repeated replies to
obsync's own output still reach the same limit. Identical merged versions
share their own content as the base for your next edits. This
prevents slow connections from splitting newly typed text into false conflict
copie...

obsync 1.1.2

obsync 1.1.2

What changed

An old deleted twin cannot erase a newer note. When catching up on history,
obsync checks that an identical note is still the server's current version
before retiring this device's independent copy. An edit arriving during that
check stays on its own identity. If a newer local identity arrives while that
check is waiting, it is kept too: the final identity check and replacement
now happen together, with no wait between them. The keeper's identity is saved before the
old identity is retired, so restarting preserves that decision. A full server
encountered during automatic chunk repair remains a visible error instead of
being reported as offline. (#131, #129)

Sync resumes by itself when the server becomes reachable again. Until now a
device that opened Obsidian while its server could not be reached -- a laptop
waking before Wi-Fi, a phone away from the home network, a server restarting --
stopped with obsync: error and stayed stopped until someone ran Sync now.
It now keeps trying on its own: 5 s after the failed start, doubling to every
5 minutes, for as long as Obsidian is open, and at once when the device reports
its network back. The status bar and the settings Connection row say
obsync: offline — retrying while it waits, and go back to idle the moment a
start gets through. Nothing needs pressing when you return; Sync now only
makes the next attempt happen now.

The status bar says so from the first request that gets no answer. A
device that could not reach its server used to read obsync: idle for about a
minute and a half, the time the plugin spends retrying one request, before
offline — retrying appeared; measured on real devices in the 2026-09-23 run.
It now switches at the first unanswered request and goes back to what it said
before at the next answered one. An error that needs you is never covered, and
a device that is not paired still reads not paired. The background repair
check no longer mistakes a missing server for damage either: while offline it
used to flash error — Server repair could not verify…, sending people to look
for a problem that was only the network; it now waits for the next check.

Obsidian opens at once when the server cannot be reached. Opening Obsidian
away from a server it could not reach held the whole app on "Loading plugins…"
for as long as the plugin kept trying to connect -- over three minutes on an
iPhone and 88 to 119 seconds on desktops in the 2026-09-24 run -- with
"Reload app in Restricted Mode", which turns every community plugin off, as the
highlighted way out. The plugin no longer makes Obsidian wait for the server:
the app opens, the status bar reads offline — retrying, and sync starts when
the server answers.

Restarting Obsidian no longer deletes empty folders on your other devices.
The plugin could start its first sync while Obsidian was still listing the
vault, compare against that empty listing, and conclude that everything was
gone: every empty folder was then deleted on your other devices (into their
trash), and every note was listed under Deletions held back with a
Confirm that would have deleted it everywhere. Notes were only saved by the
checks that hold back a mass deletion. This happened on 1.1.1 too, on some
restarts and not others, more often in bigger vaults. The first sync now waits
until Obsidian has finished listing the vault.

The sync status window reads on a phone. A long State line, such as an
error, squeezed the labels beside it to one letter per line; labels now break
only between words.

A refusal at start is still a stop. When Obsidian starts, a revoked or
unapproved device, a signature the server rejects, a clock too far off, a server
that has run out of space, or a vault key that does not open the vault's records
still show obsync: error — <reason> and are never retried by a timer: those
need you, and knocking again would not change the answer. The plugin tells the
two apart by what the server said, not by the wording of a message. A device
that is already running when one of these refusals arrives still reads
offline — retrying in this release; that is #155.

Same on every platform. Desktop and mobile use the same timer and the same
online event. On a phone, a pause that runs out while Obsidian is in the
background fires when the app returns to the foreground.

Each scheduled retry, each retry run, each resume and each stop writes one line
to the developer console (engine decision=retry_scheduled ...,
decision=retrying, decision=resumed, decision=stopped reason=start_failed),
so a device that is not syncing says why.

Two devices that start with the same notes keep one of each. A vault copied
to a second device by hand, or moved over from another sync tool, no longer
turns every note into a conflict copy of identical content at first sync. A note
whose bytes are the same on both devices, at the same name, settles on one file
with no copy, whatever order the two devices publish and pull in; a note that
differs by even one character is still kept twice, as a conflict copy
(Conflicts). The comparison reads nothing and downloads
nothing: identical notes already share chunk ids. The files on disk are never
written, moved or deleted to settle the pair -- the duplicate is retired on the
server. A device older than 1.1.2 still copies identical content, so update
every device; the copy it makes can simply be deleted. Each settlement writes
one decision=converged line naming the id that kept the name and the id
retired (#131).

Same network, step by step. A new guide,
Same network, step by step, shows every screen of the
most common setup: one computer at home runs the server and the phone syncs
over the same Wi-Fi, with no tunnel, VPN or domain. It covers the computer's
firewall, and the iPhone certificate install screen by screen, which the old
one-line instruction got wrong: an AirDropped certificate lands in Files and
is installed from Settings, General, VPN & Device Management. It is the path
recorded in the 2026-09-23 run.

Install or update

In Obsidian: Settings -> Community plugins -> Browse -> Self Hosted Private Sync,
or Check for updates if it is already installed. Obsidian takes the plugin
files from this Release.

The server is a separate upgrade and nothing forces it: deploy the image below
BY DIGEST, keeping both volumes, and the journal replays into the new binary.

Supply-chain evidence

Artifact	Reference
Image	ghcr.io/snaraj/obsync:v1.1.2@sha256:cd7ddf64f4d5fd598182ea934a901b47b3d26f6cab61b083cf745b036eaf3afe
Chart	ghcr.io/snaraj/charts/obsync:1.1.2@sha256:e045376fec504c8add6b9381db90c267935e4108ebbb81d54fefde2d29dbb556
Plugin	obsync-plugin-1.1.2.zip (sha256:984953a0206712a8ff022ef942be176c5e7a612ba93931f786282757ebb9de78)

Image and chart are signed with keyless Cosign by this workflow identity.

Publication evidence: obsync-1.1.2-release-manifest.json (sha256:fc7fc8579ede11c42a3042df319efa627e64f81cd3e2b1cce78738af85132d61).

obsync 1.1.1

obsync 1.1.1

What changed

The setup guide is one press away, and it says which setups are proven.

Added

• Setup guide, the first row of the plugin's settings on every platform, and the
  command Open the setup guide open the project's guide in your browser. The
  address ships with the plugin and the plugin itself sends nothing there;
  Obsidian's help link for the plugin now opens the same page.
• Choose your setup: every way to run and reach the server, what
  each needs, and whether CI or a recorded validation run proves it.

Changed

• The README opens with the setup guide.

Install or update

In Obsidian: Settings -> Community plugins -> Browse -> Self Hosted Private Sync,
or Check for updates if it is already installed. Obsidian takes the plugin
files from this Release.

The server is a separate upgrade and nothing forces it: deploy the image below
BY DIGEST, keeping both volumes, and the journal replays into the new binary.

Supply-chain evidence

Artifact	Reference
Image	ghcr.io/snaraj/obsync:v1.1.1@sha256:fe9629c6d9693e1988b5869c9a1116a514ccd7113bba9c1e2ef77c67ecf8609e
Chart	ghcr.io/snaraj/charts/obsync:1.1.1@sha256:f87cb92ccfeca5a1a2cccede058941b6a1952b4507cd94e430856769eb0d0ff3
Plugin	obsync-plugin-1.1.1.zip (sha256:5d7a6a2b202b91fe9e65c00032221dcbaa548dc68c16c34ef12e9c96f44e818e)

Image and chart are signed with keyless Cosign by this workflow identity.

Publication evidence: obsync-1.1.1-release-manifest.json (sha256:2f140beb2ab4b08f0bc8b48b0b5dffb2e633a5afec2d74225abc0bfa3b6caef2).

obsync 1.1.0

obsync 1.1.0

What changed

Folders sync now -- an empty one reaches your other devices, and a deleted
one leaves them. That is a new kind of record, so a device still on 1.0.x
refuses each folder with one notice and goes on syncing its notes. Update
every device that syncs the vault, and read "Two folders that differ only in
capitalisation" below if one of your devices shows two.

This release also carries everything the 1.0.7 work fixed, which had not been
released on its own; those entries are further down, under "Also in this
release", unchanged except where 1.1.0 changed them.

Folders

An empty folder now reaches your other devices, and a deleted folder leaves
them. Until now a folder existed on a device only because a note inside it
did: two empty folders made on a computer never appeared on a phone at all,
and deleting a folder removed its notes everywhere but left the empty tree
standing in every other device's file explorer. Folders are now synced in
their own right -- created, deleted and renamed, in both directions. The
server still cannot read any of it: a folder is stored the same way a note
is, as something only your devices can open.

A folder is only ever removed when it is empty on that device, and empty
means empty to the filesystem: a hidden file, a note you do not sync, or
another plugin's data all keep it, and no file is ever taken to make a folder
go. A folder obsync has a record for is removed only by its own deletion
arriving, so an empty folder you keep on purpose does not vanish when its last
note is deleted somewhere else.

What a device still on 1.0.x does. It does not know this kind of record,
so it refuses each one: one notice per folder, no file written, nothing
deleted, and its notes keep syncing throughout. On 1.0.6, the newest 1.0.x,
that notice reads "obsync refused a change from another device: it does not
name a plain file inside this vault (version). Nothing was written. File id
..." -- those are the words to search for if you see it. It stops as soon as
that device is updated. This was proved against the decoder shipped in 1.0.0
through 1.0.6, copied into the test suite from the released tag rather than
described; the function that does the refusing, parseManifest, is
byte-identical at all seven of those tags -- sha256
8aa8a2df240bcd8ffba197fc9b2e238bb9b727ef0416007eb526a3082e8aa4de of it at
each, which plugin/test/fixtures/decoder-1.0.x.mjs says how to re-derive.

Two folders that differ only in capitalisation. A folder renamed by
capitalisation alone -- Team docs to team docs -- was published as NEW
notes by versions before 1.1.0, because the computer that made the rename sees
one folder where a phone sees two. Devices that tell the two apart received
the new names and were never told to retire the old ones, so they ended up
showing both: one live folder and one that never changes again. From 1.1.0
such a rename is published as the rename it is, and the device receiving it
renames the folder itself.

Be precise about what renames it, because that is what decides whether two
devices ever agree. On a computer, Team docs and team docs are ONE
folder on the disk, and renaming a note inside it cannot change how the folder
itself is spelled -- the operating system finds the folder by either spelling
and leaves the name it keeps alone. So the folder's own record is what
re-cases it, and obsync publishes that record BEFORE the notes underneath
move. A device receiving it renames the directory, carries every note under it
with the rename, downloads nothing, and publishes nothing back. Before this
release the receiving device took the new spelling into its records while its
disk kept the old one; its next scan read that difference as a rename and
published it back, the other device did the same in reverse, and the two
traded one rename every thirty seconds, re-downloading every note under the
folder each time, for as long as both ran. If you saw a folder's notes gaining
versions endlessly, that was this.

This works when the folder you renamed is the only one that device syncs,
and on the devices whose filesystem folds capitalisation. If you chose
folders under "Sync folders on this device", the folder you selected is
published in its own right, so re-capitalising it reaches your other devices
as the one rename it is. That one shape -- the renamed folder IS the selected
folder, which is the usual shape on a phone -- was the one this release nearly
shipped broken: the rename went out as note moves with no folder record behind
them, every device that folds case refused them and told you to update a
device that was already up to date, and every later edit you made in that
folder was refused there too. A device RECEIVING such a rename for the folder
it syncs follows it -- on a Mac, on Windows, on an iPhone, where the two
spellings are one folder on the disk: it keeps syncing under the new
capitalisation and you do not have to select it again. On Linux and on
Android they are TWO folders, so that device does not follow the rename: it
keeps your folder under the old spelling and quietly stops receiving what you
put in it elsewhere, until you rename it there to match. Nothing is lost
either way, and Troubleshooting says how to settle it.

And a folder that only LOOKS like that rename is left alone, with a
notice. A device that keeps Team docs and team docs apart can hold both
-- which is exactly what a capitalisation-only rename made before this release
leaves behind -- and by the name alone, a device syncing just one of them
cannot tell that second folder from a rename of the one it syncs. obsync
follows such a folder only where it really is that rename, which is where the
other device retired the old name first; otherwise it leaves your folder and
your selection where they are, keeps syncing what you chose, and tells you
once, naming both spellings. Following it would have moved that device onto
the folder you did not choose: what the other device put in yours would have
stopped arriving, and your own edits would have come back there as conflict
copies.

An empty folder re-capitalised while Obsidian was closed no longer
disappears. obsync finds that rename when it next starts, and it used to
announce the new folder before announcing that the old one was gone -- so a
device that folds case renamed the folder and then obeyed the removal, which
on such a device names the very folder it had just renamed. Nothing was inside
it to keep it, so it was deleted there, and then here. The two records now go
out in the order the rename happened in, and no device removes a folder its
own vault spells differently from the record asking for it.

If the server refuses the folder record, obsync says so. The notes under a
folder being re-capitalised wait for that record, because no device can apply
them without it. obsync attempts the record three times; if all three fail it
tells you once, sends the notes anyway -- where the other device refuses them
and says why -- and publishes the folder again the next time it starts.
Nothing is lost and nothing is deleted while that is true.

If the rename comes from a device still on 1.0.x, there is no folder
record to send, so the notes arrive asking for a folder spelled a way this
device does not show. obsync refuses those moves rather than guessing: the
notes you already have stay exactly where they are -- nothing of yours is
written over, moved or deleted -- and you are told once per folder. A note
CREATED on the other device meanwhile is not a move and is not refused: it is
written here, in the folder this device shows, and the difference in spelling
is not published back. Update the other device, or rename the folder here to
match, and both devices agree again -- including the edits made there while
the two disagreed, which the folder record brings down with it as it settles
the spelling. Not letting one note's version rename a folder full of other
people's notes is what makes the refusal the safe answer meanwhile.

If a device of yours already shows both, there is a recovery, and its order
matters: do not delete the stale folder first. On a device that folds case
the old spelling IS the live note's own entry, so a deletion of it published
from elsewhere can take the notes you are keeping. Update every device, open
each one and let it sync once -- a device that folds case will quietly drop
the records naming the old spelling and tell you so once -- and only then
delete the stale folder, on the device that shows two. The full steps are
under "Two folders that differ only in capitalisation" in the troubleshooting
guide. The last step is yours on purpose: no device can prove the others have
been updated, and a rename leaves a note's size and date exactly as they were,
so nothing later can tell the abandoned copy from the live one.

An empty folder left under an old spelling can stay or go as you like.
Nothing in this version deletes a folder that holds anything.

Notes, and the ways they were lost

A note another device renames is renamed here too, instead of being
re-downloaded and thrown away. Applying a rename used to write the note
under its new name and send the old name to the system trash -- so every
rename made on one device left a full copy of that note in every other
device's trash, which on a phone is somewhere you can barely reach. It is now
one rename: nothing is downloaded, nothing is trashed, and the note keeps its
identity. That is true of a rename that changes only capitalisation as well --
it used to rename the entry and then fetch and rewrite the whole note anyway,
which on a phone was the note's full size in data for a change of name. A
rename arriving over a note you have changed here and not yet uploaded is
still kept as two notes, exactly as before.

**obsync no longer tells your other devices to delete everything when it
loses sight of a folder....

obsync 1.0.6

obsync 1.0.6

What changed

Three things 1.0.5 got wrong, all found on real devices after it shipped, none
of them losing a note. Update every device that syncs the vault. Two are
fixed here; the third is half fixed here and finished in 1.0.7, and this entry
says which is which.

1. Editing the same note on two open devices could loop. You would see a
stream of "obsync merged concurrent edits to ..." notices on both devices, one
a second or faster, and the note's version history growing without end. The
note's text was correct on both devices the whole time, and it never changed
again after the first pass. The cause: two devices combining the same pair of
versions produce the same text but two different version ids, so each saw the
other's result as something new to combine, forever. Now a device checks
whether the incoming version's content is the content it already has; if it is,
there is nothing to publish, both devices pick the same version to carry
forward by a rule they compute identically, and one of them publishes the
single entry that closes it. There is also a hard stop: more than five
resolutions of one note within a minute and the device stops combining that
note, keeps both versions side by side as it does for any conflict it cannot
merge, and tells you once. Once both devices have 1.0.6, editing one note on
both settles in a single round. When two devices did reach the same combined
text independently, one of them still publishes a single entry to close the
split -- that is deliberate, and it is one entry, not a stream. With more than
two devices editing at once, more than one of them can publish that closing
entry from the same starting point; in testing those settled too, without a
loop.

2. Two notes created under one name kept making conflict copies — half fixed
here, finished in 1.0.7. When two devices each created a note under the same
name while one was closed, 1.0.5 kept both, as it should, and then every later
edit wrote another (conflict from ...) copy on the other device. Part of that
was this: a copy already on disk was recognised by its size and timestamp
rather than by its content, so the same version could be copied twice under two
names, and a version could be announced as copied when it had not been written
at all. A copy is now recognised by its content, which a vault's own
bookkeeping cannot change, and that half is fixed in this release. One case
still makes a second copy on purpose: a note too large for obsync to carry a
single whole-file fingerprint -- roughly 8 MB and up -- cannot be compared that
way, so its copy takes the next free name rather than risk replacing something. The other
half is that the two notes still compete for the one name; giving them settled,
separate names on every device is planned for 1.0.7 and is not in this release.
Until then: rename one of the two notes and the copies stop.

3. A hidden .obsync-restore-<id>.tmp file could be left in your vault. On
desktop, after obsync wrote a conflict copy, the working file it used to write
that copy safely stayed behind next to the note. It is a plain copy of the
note's text, inside your vault folder, never uploaded, and Obsidian hides it.
Any left by 1.0.5 are safe to delete. 1.0.6 removes its own working file
whether the copy succeeds or fails.

In every case seen, notes were safe. In the loop as it was reproduced --
two devices, one note, one edit each -- every device ended up with the same
text, and no note content was lost in any of the three problems above. What the
loops filled was your server's history, and on a server with a storage limit
that could have used the limit up, which stops syncing for the whole vault
until space is freed. The extra history entries are ordinary versions and your
server's own retention removes them in time.

Update every device that syncs the vault — a single device left on 1.0.5
can still start a loop. If one is running right now, quit Obsidian on one of
the two devices: stopping one participant can allow outstanding work on the
other to drain. Update every device before resuming.

Install or update

In Obsidian: Settings -> Community plugins -> Browse -> Self Hosted Private Sync,
or Check for updates if it is already installed. Obsidian takes the plugin
files from this Release.

The server is a separate upgrade and nothing forces it: deploy the image below
BY DIGEST, keeping both volumes, and the journal replays into the new binary.

Supply-chain evidence

Artifact	Reference
Image	ghcr.io/snaraj/obsync:v1.0.6@sha256:45583060c2ba1323fb65c70817b5e3048c01269d71520991bb928040ac9dcee6
Chart	ghcr.io/snaraj/charts/obsync:1.0.6@sha256:204b5078cc17f20c7457e6eab03e53e40c86b10930509f221e1e9669e9c79e3b
Plugin	obsync-plugin-1.0.6.zip (sha256:4675461aa509714b397c2af1240008c953ad067a3daf69d495e7370e3f25902e)

Image and chart are signed with keyless Cosign by this workflow identity.

Publication evidence: obsync-1.0.6-release-manifest.json (sha256:c9a5423b925ab40005706aeaa1e9b8bbc6baa3f2ee3f44b56621152fc4dcf5d8).

obsync 1.0.5

obsync 1.0.5

Known issues in 1.0.5, and the releases that fix them

Found on real devices after this release shipped. In the cases we reproduced,
none of these lost note content. Items 1 and 3 are fixed in 1.0.6 (pull request #112, in review now);
item 2 is fixed in 1.0.7 (issue #113), which follows immediately. Update every
device that syncs the vault as each release appears.

1. Editing the same note on two open devices can loop. When two devices
that are both open edit the same note at nearly the same time, each merges the
other's edit correctly, and then they keep sending the same merged text back
and forth: a stream of "obsync merged concurrent edits to ..." notices, one a
second or faster, and the note's version history grows without end. The note's
text was correct on both devices throughout the case we reproduced. To stop
it: quit Obsidian on one of the two devices, or close that vault window;
the other device may still publish a few more versions before it settles.
Update every device before opening the vault on both again. Until then, avoid
editing one note on two open devices at the same moment. Fixed in 1.0.6 (#112).

2. Two notes created under one name keep making conflict copies. When two
devices each create a note under the same name while one of them is closed,
1.0.5 keeps both, as it should, but the two then compete for that name: every
later edit of that note on one device writes another (conflict from ...)
copy on the other. Content is kept; the copies pile up. Workaround: rename
one of the two notes; the copies stop. Fixed in 1.0.7 (#113).

3. Writing a conflict copy can leave a hidden temporary file named
.obsync-restore-<id>.tmp in the vault folder on desktop, one per copy. It is
a plain second name for the same note, inside your vault folder, never
uploaded. Delete it. Fixed in 1.0.6 (#112).

The fix for the offline-edit loss below stands and is unchanged.

What changed

A note you wrote or edited while Obsidian was closed could be replaced by
another device's version when you opened it again. Update every device that
syncs this vault. That is the whole release; nothing else changes.

What happened. In 1.0.0, 1.0.1, 1.0.2, 1.0.3 and 1.0.4, if you edited a
note while Obsidian was closed on one device, and the same note also changed on
another device in the meantime, opening Obsidian again replaced your version
with the other device's within a few seconds. Writing a NEW note while the app
was closed did the same when another device happened to create a different note
under that same name. No (conflict from ...) copy was written and nothing was
moved to the trash. A note that changed on only one device was never affected,
and a note you wrote while the app was closed with no counterpart on another
device was uploaded correctly.

Content lost this way cannot be brought back. This is not like 1.0.4's
deletions, where the note's content was still on the server and Restore from
history could return it. Here the replaced text had never left the device --
obsync had not uploaded it yet -- so the server never held it, and neither
Restore from history nor the dashboard nor your operator's backups can
produce something that was never sent. If Obsidian's own File recovery
(Settings, Core plugins) was on, its periodic snapshots of that note are the
one place left to look.

What happens now. When a version arrives from another device for a note
this device has changed and not yet uploaded, obsync keeps your file exactly as
it is, writes the other device's version beside it as
<note> (conflict from <device>, <date>).md, tells you it kept both, and then
uploads yours. Where the two sides only added lines in different places, they
are merged into one note, as concurrent edits always were. A conflict copy is
never written over something already at that name either, so a copy you have
opened and edited is kept and the new one takes the next free name.

obsync recognises a note you have changed by its size and its modification
time, compared with what it recorded when it last uploaded that note — the
same check it has always used at startup to decide what to upload. An edit that
leaves both of those exactly as they were is invisible to that check, on this
release and on every earlier one.

Why every device. The device that loses the edit is the one that was
closed, so updating one device protects only that device. Update them all.

Install or update

In Obsidian: Settings -> Community plugins -> Browse -> Self Hosted Private Sync,
or Check for updates if it is already installed. Obsidian takes the plugin
files from this Release.

The server is a separate upgrade and nothing forces it: deploy the image below
BY DIGEST, keeping both volumes, and the journal replays into the new binary.

Supply-chain evidence

Artifact	Reference
Image	ghcr.io/snaraj/obsync:v1.0.5@sha256:25f23d08e7093db432f0fbdd4eb3a2b30f3f17daf584fe538ec3831824587275
Chart	ghcr.io/snaraj/charts/obsync:1.0.5@sha256:e4848758d9a0cd9d4206d8008ee708be08a703b0164a2f84214a72f593a24f4c
Plugin	obsync-plugin-1.0.5.zip (sha256:e92538081f59c6088b03f5c8508f1a7b2cacfba9bfd28c88a147aa8f8d85e84e)

Image and chart are signed with keyless Cosign by this workflow identity.

Publication evidence: obsync-1.0.5-release-manifest.json (sha256:5d344d2d6f2b67d173ec3fd965a5e90310a433ab88bf6c647de775e6658a1569).

obsync 1.0.4

obsync 1.0.4

What changed

Renaming a note or a folder could delete it, on every device. Update every
device that syncs this vault, and do not rename anything until you have.
That is the whole release; nothing else changes.

What happened. In 1.0.0, 1.0.1, 1.0.2 and 1.0.3, renaming a note -- through
the inline title, through the file explorer, or by moving it into another
folder -- reached the other devices correctly as a MOVE, and then the device
that applied that move published a DELETION for the note it had just moved.
Every device obeys a deletion, the one that did the renaming included, so the
note left the vault everywhere within seconds of being renamed. Renaming a
folder did the same to every note inside it. A note nobody renamed was never
affected, and no note was ever deleted on its own.

Your content is not lost, and the server never had it in the clear. A
deletion here is a marker, not an erasure: the versions before it stay on the
server under the retention its operator set (by default at least ten versions
per file and everything from the last thirty days), and they are still
encrypted with your vault key. To bring a note back, run Restore from
history from the command palette on any paired device, find the note by its
path, pick the content version from before the deletion marker -- markers
themselves cannot be restored, which is why the list offers the version under
it -- and restore it. It comes back as a new file beside that path, named
<note> (restored-...), and nothing existing is overwritten. A note Obsidian
moved to your system Trash or to your vault's .trash folder when it obeyed
the deletion is also still there, with its body intact.

What was wrong. Applying a remote rename means writing the note under its
new name and removing it under the old one. Obsidian reports that removal back
to this plugin exactly as it reports one you make yourself, and the plugin
published it: a deletion for a file that was alive the whole time, one name
over. The plugin already ignored the echo of its own writes; now it ignores the
echo of its own removals too, by the path it is about to remove, and it says so
in its log (decision=echo_suppressed event=delete). A deletion you actually
make is untouched by this and still reaches every device, including one you
make on a note that was just renamed elsewhere.

Why every device. The device that publishes the wrong deletion is the one
RECEIVING the rename, so a single device left on 1.0.0-1.0.3 can still delete a
note that a fully updated device renames. Update them all, then rename freely.

Install or update

In Obsidian: Settings -> Community plugins -> Browse -> Self Hosted Private Sync,
or Check for updates if it is already installed. Obsidian takes the plugin
files from this Release.

The server is a separate upgrade and nothing forces it: deploy the image below
BY DIGEST, keeping both volumes, and the journal replays into the new binary.

Supply-chain evidence

Artifact	Reference
Image	ghcr.io/snaraj/obsync:v1.0.4@sha256:4946d5d29bcd69bccea510efe5696b67711401ad215147cd907bc115a1b1dc4c
Chart	ghcr.io/snaraj/charts/obsync:1.0.4@sha256:3b10a5202d2244b5c8f5e2863aa8f86f33fa1f38c678e004d77f9b64d1c6f477
Plugin	obsync-plugin-1.0.4.zip (sha256:6391b1f6b75d5f4ca4b6d3332a2f9a7e390e50b8ce2625e3ed9b7764f0ca0d38)

Image and chart are signed with keyless Cosign by this workflow identity.

Publication evidence: obsync-1.0.4-release-manifest.json (sha256:a53c8b4fccf9c6dd7dbf4395de850fe99881920b719e28b1c4ede0c55fe10450).