r-zakarya bb222e1903 perf(android): saving no longer pulls the vault it already holds
The crypto is down to about 135 ms, so the wait was never the crypto: the
log says HTTP 200 in 3244 ms for 266299 bytes. Every save fetched the whole
vault, decrypted it, patched it, and sent it back.

The fetch existed to be sure of modifying the latest published version. The
sha proves that better and for free: publish against the snapshot in hand,
and if another device published in between, Gitea refuses with a 409 - then,
and only then, pull for real. The retry loop was already written for exactly
that.

The snapshot kept is the one RECEIVED, never a re-serialisation of TVault:
that would drop everything the phone does not read - attachment bodies, the
avatar, tombstones - which is the invariant PMA.VaultPatch exists for. It
goes at lock, with the rest of the plaintext.

Note this makes the 409 path load-bearing, and it has still never run. It is
now what guarantees a save cannot clobber another device.

The PUT still carries the whole container; that is inherent to the format.
2026-08-21 15:00:46 +01:00
S
Description
full local password manager
24 MiB
Languages
Pascal 46.7%
JavaScript 35.4%
HTML 9.4%
CSS 4.9%
PHP 2.1%
Other 1.4%