This seems pretty useful. Just curious, why is it necessary to load entire files into memory (let alone twice?) - seems like not that much extra work (for claude) to stream the files to disk. Maybe I'm missing some limitation due to the underlying implementation. I agree that it's not necessarily a deal breaker for most common quick file transfers, however, it seems like unnecessarily limiting the scope of the tool if it wouldn't be too difficult to overcome.
The need for loading the file into memory comes down to WebCrypto's AES-GCM being one-shot: crypto.subtle.encrypt calculates a single auth tag over the entire message and there's no incremental/update() API, so the whole file has to be one contiguous buffer.
That feature is also a good opportunity to switch to FileSystemWritableFileStream/Blob for writes, which will reduce the memory requirements when writing files to disk.
This seems pretty useful. Just curious, why is it necessary to load entire files into memory (let alone twice?) - seems like not that much extra work (for claude) to stream the files to disk. Maybe I'm missing some limitation due to the underlying implementation. I agree that it's not necessarily a deal breaker for most common quick file transfers, however, it seems like unnecessarily limiting the scope of the tool if it wouldn't be too difficult to overcome.
The need for loading the file into memory comes down to WebCrypto's AES-GCM being one-shot: crypto.subtle.encrypt calculates a single auth tag over the entire message and there's no incremental/update() API, so the whole file has to be one contiguous buffer.
The fix is chunked AEAD (per-chunk IV+tag), encrypting/decrypting a chunk at a time. It's on the roadmap, just haven't gotten around to it yet: https://gitlab.com/PavelSafronov/engye#large-file-support-st...
That feature is also a good opportunity to switch to FileSystemWritableFileStream/Blob for writes, which will reduce the memory requirements when writing files to disk.