Validation run 2026-09-20¶
Run of 2026-09-20. Scenario outcomes, platform coverage and measurement limits for the 1.0.0 server on the reference route class. The operational account of the run (how it was driven, how the devices and vaults were arranged, what happened on the access path) is held privately by the maintainer and is not part of this record (requirement 11).
Operator¶
The maintainer, with agent assistance for the steps that need no human. The operating account is private.
Route¶
The reference route (docs/validation.md "Routes"; the generic deployment
guidance is docs/kubernetes.md). The deployment's configuration is private.
The connectivity and TLS checks the scenarios require passed.
Devices¶
Platform coverage of this run, by role. Hardware, OS versions and the device arrangement are private.
| Role | Platform | Obsidian | Plugin |
|---|---|---|---|
| desktop | macOS | 1.13.7 | 1.0.1 and 1.0.2 from the community directory |
| phone | iOS | not recorded during the run | 1.0.1 from the community directory (Settings -> Community plugins -> Browse) |
Server: obsyncd 1.0.0, release commit 0bb69ee.
Scenarios¶
Every scenario in docs/validation.md, in its own row. Silence is not a
pass.
| Scenario | Result | Evidence |
|---|---|---|
| production-path install | pass | both devices installed the listed 1.0.1 through Settings -> Community plugins -> Browse; the phone's card read "Version: 1.0.1 (currently installed: 1.0.1)" |
| V1 setup on the first desktop, recovery phrase shown | pass | the setup token accepted, the 24-word phrase shown once and confirmed by three words, status idle; the dashboard, opened from the desktop plugin, showed the account, its devices, both storage volumes with their free space, and a scrub that had completed a full pass |
| V2 pair a second device from the desktop | not proven | the phone was paired by one-time code and approval on the desktop, the approval prompt naming the platform, within about two minutes of the claim. The scenario names an iPad and a Windows device, neither present in this run, and the dashboard's Devices page with its platform and country columns was not read, so the row does not claim the scenario. No capture of this step is published |
| V3 edits both ways | not proven | both edits synced: a note written on the desktop was listed on the phone at the first look, about thirty seconds after the write and not observed earlier; a line appended on the phone was in the desktop's file within ten seconds, measured by a 3-second poll of the file. The pass condition is three seconds, which neither observation resolves, so the row does not claim it; two devices, not the four the scenario names |
| V4 rename and move a populated folder | not attempted | |
| V5 offline conflict on two devices | not attempted | |
| V6 a 2 GiB image on macOS | not attempted | |
| V7 a 20 GiB archive, killed mid-upload | not attempted | |
| V8 delete and restore from history | not attempted | |
| V9 revoke a device | not attempted | |
| V10 restart the server mid-sync | not attempted | |
| V11 fill the blob volume to the watermark | not attempted | |
| V12 scrub with one blob corrupted by hand | not attempted | |
| V13 off-LAN sync from the phone over cellular, over the private path | pass | the phone had Wi-Fi off and completed the pairing and both edits above over the private path |
| V14 dashboard from a phone browser | not attempted | |
| V15 Compose path from scratch, phone paired over the LAN | not applicable | this run is the reference route; the 2026-09-14 run covers Compose |
| V16 native credential persistence across restart | not attempted | |
| native update | not attempted | both devices installed 1.0.1 fresh into new vaults |
Captures¶
No capture of this run is published. The maintainer holds the run's captures privately; every row above states what was observed, so the row stands on its own.
What was not validated¶
Not proven: V2 and V3, whose observations are preserved in their rows but whose pass conditions name devices this run did not have or a bound it did not measure. Not attempted: V4 through V12, V14, V16, and a native update. Not applicable: V15. The iPad and Windows had no device in this run, so nothing here speaks for them. Platform coverage: one macOS desktop and one iOS phone; iPad, Windows, Android and Linux had no device in this run.
Privacy evidence¶
- From the desktop, before the device run:
/readyzanswered 200 in 0.23 s withCache-Control: no-store,X-Content-Type-Options: nosniff,X-Frame-Options: DENY,Referrer-Policy: no-referrer; an unsigned/v1/devicesanswered 401; plain HTTP on the TLS port was not served. - By design (
docs/protocol.md) the vault key crosses the network only inside the device-sealed pairing envelope. This run did not read the server's log; what it observed is the plugin's own sequence on both devices: the claim, "Waiting for approval on the other device", the approval prompt naming the phone, and the phone paired. The 2026-09-14 run read the corresponding server log lines for the Compose route.
Findings¶
None against the server or the plugin. The private path in front of the
server produced connection failures that the plugin reports as a TLS error
or as a name that does not resolve; their generic failure classes and fixes
are on the mobile troubleshooting page (docs/troubleshooting.md). The
operational account of what was changed is private.