bb222e1903f97bc51d4b27e7f645a2bdaaea40f1
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.
Description
full local password manager
Languages
Pascal
46.7%
JavaScript
35.4%
HTML
9.4%
CSS
4.9%
PHP
2.1%
Other
1.4%