r-zakarya
f97e44768a
Measured on the phone, opening a cached vault: 121 ms to read the sealed file, 14 ms to display it - and then 5718 ms decrypting a snapshot it already had. The cause is upstream. A sync pushes unconditionally at the end, and the push is never a no-op: the container is re-encrypted with a fresh salt and IV, so an identical vault produces completely different bytes. On Gitea that is one more commit and a new blob sha, so every other device sees a "new" snapshot and pays a full key derivation to arrive back where it started. It also grew the repository on every sync that changed nothing, which is the history cost the plan warns about. The merged state is now compared against what was pulled, as plaintext - the only place equality is observable - ignoring snapshot_at, which changes by construction. Equal means the push is skipped and the sync still counts as done, timestamp included: having nothing to write is a success, not an absence. The comparison is deliberately strict. A false negative costs one commit; a false positive would silence a push that carried a change and lose it for the other devices. Four tests fix where that line sits, including a modified updated_at (which arbitrates the merge elsewhere) and a tombstone (a deletion that has to propagate). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
