Version 0.90.1
2026-08-22 12:08:13 UTC
Fixed
3If the server cannot clear a deleted file's key, the file stays in your list so the next attempt can finish it.
Deleting has two halves: the bytes, and the key that opens them. When the second half failed — a dropped connection, an expired session — NMTS threw the error away and removed the file from your list anyway, so the row was never in the trash, the 30-day sweep never reached it, and the wrapped key stayed on our server. A failure now falls back to putting the row in the trash, where the sweep does reach it. A file that neither call could clear stays in your list and the screen says the delete did not finish, so trying again completes it.
Downloading the local copy of your recovery list no longer erases the record that a copy is on the storage network.
One field held two different facts: what the newest record was, and whether a copy of the recovery list exists on the storage network. Downloading the zip wrote “local” over it, so the account screen went back to saying the copy was on but no upload had happened since — while a copy was sitting on the network — and the recovery kit printed that the copy had not been created. Somebody reading that could upload a file they did not need, to “make it happen”, and pay for it. The screen now reads the copy's own address rather than the record type.
After a failed signature, the storage-extension screen re-reads the chain before it lets you approve again.
A signature that comes back as an error is not proof that nothing happened: a timed-out request, a wallet extension that disconnects, a phone that goes to the background — in all of those the transaction can be executed while the answer is lost. The screen used to leave its numbers exactly as they were and re-arm the approve button, so a second press bought the same storage period a second time, with real money. Our replay guard cannot catch it, because those are two genuine transactions. The screen now re-reads the storage lease from the chain first, and the approve button stays inactive until that answer arrives — if the first attempt did land, the new end date is what you see.