I'm in favor of seeing the tackling of small tools that have existing solutions in other languages, to show a new way of doing them.
The focus should be on making that tool as small and clear as possible, while having a surprising amount of features.
A dialect which let you intermix specification with triggers of some added code to run along with the backup would be an good example. So that you're not just making wildcarded-file lists...but also if there is a GROUP! in the middle of that file list (or whatever) then it knows to run code it if anything in the block of patterns has changed.
Maybe what's in the GROUP! generates some kind of "derived file", e.g. if the files it detects a change in is source code, it might trigger a compilation process and add the resulting executable to the backup.
Doing a good job of something like this is best if you have a streaming hash mechanism. So you can get a fingerprint of files without loading them all into memory at once.
Fortunately we have all of our hashes (and ciphers) in streaming form now. Unfortunately, we have no exposure of that streaming implementation yet.
So for the moment, you'll have to read files in memory to hash them. But that will improve in the Someday(tm) time period.
The place to really focus on here isn't the wire protocols or encryption kind of stuff, but the code itself. How do the new patterns of expressions in PATH! and TUPLE! help you?
What do these backup dialect rules like, and how do you cross the domain of a normal script that happens to have a backup portion in it? Like what if I want my program to leverage backing up or mirroring folders as part of the implementation...tracking differences in its own files?
If you can design a dialect that is useful there as well as an independent tool, then that is best.
