Version 0.105.0

Uploading a name a file already has now asks, instead of quietly numbering the new one.

Until now the drive renamed the arriving file to `report (2).pdf` without a word, so somebody uploading a corrected version of their own file ended up with both and no way to say which one was current. There are two answers, keep both under a new name or replace, and when several files arrive at once one answer covers the rest. Replacing removes the old file once the new one is stored, not when you click, so a failed upload cannot take the old file with it. It does not yet hand the old file's storage back: the new file buys its own space.

The command-line tool takes --on-collision on put and push, and puts what it replaces in the trash.

The tool had a stored setting but no way to say what this one run should do, so an agent that wanted to replace a file had to change the account setting first. The flag is read before anything is encrypted or paid for, and a stored answer from a person still wins over an agent asking for the destructive one. The tool trashes rather than erases, because the erase endpoint is closed to API keys on purpose. A file it replaces stays restorable for 30 days, and keeps using its space until `nmts sweep` clears it.

A request whose field types are wrong now comes back in the same error shape as everything else.

Those requests are refused before any of our code runs, and the refusal came back as plain text instead of the error object every other answer uses — so anything reading the error code had a second, undocumented shape to handle. The wrapping is done in one place, so routes written later are covered too. The explanation inside is unchanged: it is what tells a developer which field was wrong.

A file commit that names an empty storage address is refused instead of stored.

It was accepted, and the row it made could never be downloaded, recovered or written into a recovery list by anybody. No client this service ships has ever sent one. Storage addresses are otherwise still checked only for length, on purpose: guessing wrong about what a real one looks like would refuse a file whose storage is already paid for.

The public storage figures could be raised by somebody who stored nothing. The counting is corrected.

One stored object was counted once for every file that named it, so an outside security assessment raised the cumulative figure by 211 GB in a day on 2026-08-29 — against a service whose whole total that morning was 10.26 GB, none of it actually stored. No file, key or credit was reachable, and nobody's storage was touched; what was wrong was a number published as measured fact. Each object is now counted once on both figures, and the day that was inflated is recomputed from the records that produced it. How large an object is still rests on the uploader's word, because only the storage network can settle that.

A week's free-trial places came back when a winner erased their account. The week now remembers.

The week's meter was counted from the grant records, and those are removed with the account that holds them — so one person could take the same place again and again, while the applicants refused that week had lost theirs. Account erasure is unchanged and stays unconditional; the count now lives on the week itself and names nobody. It does not stop a different person applying with a new account, which is what the human check and the weekly budget are for.

Anyone signed in could switch on the service's own health alarm and leave it on. That is closed.

The alarm says our own records disagree about which stored object holds which bytes, and it is worth acting on because on a healthy service it never fires — but a request could simply assert the disagreement, and once written it stood even after the file was thrown away. A record that contradicts the same account is now refused, and the count reads live files belonging to one account. Two accounts naming one object is still allowed, because that is how a shared file reaches its recipient.