Most users will probably use Cryptomator on top of an unreliable filesystem.
If a silent error gets introduced at the beginning of a Cryptomator encrypted file, trying to read the plaintext file will result in the whole file being junk. On a normal filesystem, only the byte range or block with the error would be affected, but Cryptomator encrypts the file as a single stream, so any error, even a single bit, will be amplified and affect the rest of the file, and Cryptomator will not even realize there is an error that it can report to the user.
- detect silent corruption (perhaps with a per-block checksum), notify user
- minimize damage from silent corruption (limit damage to block, not entire file)
- correct/repair silent corruption (with ECC, parity, redundancy, etc)
The reliability layer could even be a separate project, independently from Cryptomator. If there was an existing FUSE/Dokany project that provided reliability, then Cryptomator could use it to provide a reliable stack: unreliable native filesystem + reliable fs layer + Cryptomator.