Unfortunately, it appears that binary diffs are not supported.
This is a really important aspect for many workflows dealing with large files (like TrueCrypt containers). Contrary to what is stated by the rclone developer [1], at least Dropbox supports binary diffs [2].
For the curious, the rsync algorithm is, at its core, ridiculously small[0] and involves rolling checksums. I just keep wondering why nobody (but Dropbox) bothers to implement it.
That's a really nice resource, thanks for the pointer.
The ideas behind are actually used in multiple places, through the librsync project (https://github.com/librsync/librsync). rdiff-backup and duplicity are 2 known examples, and surely in other projects as well.
It could be done in different ways, but as the FAQ says, rclone wants to keep file/object 1:1 mapping; which is useful in lots of cases; but not if you want to use rclone as a backup tool.
Binary diffs would be useful if you're syncing big files that change often; but then you have the limitations of the object storage implementations and (most of) their APIs. I'm not familiar with all the storage, but in the case of OpenStack Object Storage (swift), you can't upload part of an object.
You could split each file in chunks and then store those chunks, but the 1:1 mapping wouldn't be there (meaning that you need rclone to get your files back).
And it seems to store each file as one object. This should lead to a lot of overhead and additional costs (for e.g. S3 API requests) with a lot of small files.
This is a really important aspect for many workflows dealing with large files (like TrueCrypt containers). Contrary to what is stated by the rclone developer [1], at least Dropbox supports binary diffs [2].
This should be looked into, at least for Dropbox.
[1] http://rclone.org/faq/#why-doesn-t-rclone-support-partial-tr...
[2] https://www.dropbox.com/en/help/8