- Shipped
- 9 Agosti 2026, 17:57 UTC
- Author
- kamo
- Commit
- 40abddc
Sending the same video to three people meant three full uploads. Dedup collapsed them into one stored object, but only once each transfer had finished — so the saving was storage, never the member's time or bandwidth. The composer now asks before it sends. A size probe first, because identical content must have an identical byte count: it rules out a match for almost every genuinely new file at the cost of one small request, so hashing is only paid for when it can pay off. Only then are BLAKE3 and SHA3-256 computed and offered to the server, which attaches the stored content directly. A miss falls through to a normal upload. Hashing streams. The existing helpers call file.arrayBuffer() once per hash, so a file is resident in memory twice over — fine for a document, fatal for a 3 GiB video. The new one walks the file in 4 MiB slices feeding both hashers, so peak memory is one chunk at any size, and yields between chunks because SHA3-256 is pure JavaScript and would otherwise freeze the composer for minutes. Dedup is an optimisation and never a gate: any failure in the probe, the hashing or the link falls back to uploading, which is always correct. The panel names the pause so it does not read as a stall.