0.1.43

Uploads are much faster, and now tell you how long they'll take

Uploading was three sequential round trips per file, one file at a time. With 435 files queued that's 1,305 serialized round trips — roughly six or seven minutes of pure waiting before counting a single byte of actual content.

For comparison, I measured the client-side work: all the hashing and encryption for a 25 MB file comes to 533 ms. The crypto was never the slow part.

One of the three round trips did nothing. The upload-slot request existed only to be told a random id — which this side can pick itself. Removed.

Uploads now run four at a time. Commits deliberately stay sequential: uploading touches nothing shared, but committing mutates the queue and local state, and those are read-modify-write over one file. Run two at once and one write erases the other, which could drop a queued conflict copy.

Attachments over 4 MB still upload one at a time — four 25 MB buffers in flight is 100 MB held at once, and this runs on phones too.

Progress and ETA

The status bar now reads Uploading 12/196 · about 2m left, with the rate measured over the actual run rather than assumed, since the honest answer depends entirely on your connection.

Nothing is estimated for the first second and a half. An ETA that lurches from "3 hours" to "20 seconds" is worse than no ETA.