Submitted by An SBX container is composed of a collections of blocks with size submultiple/equal to that of a sector, so they can survive any level of fragmentation. Each block has a minimal header that includes a unique file identifier, block sequence number, checksum, version. Additionally, non-critical info/metadata are contained in block 0 (like name, file size, crypto-hash, other attributes, etc.).
If disaster strikes, recovery can be performed simply by scanning a volume/image, reading sector-sized slices and checking block signatures and then CRCs to detect valid SBX blocks. Then the blocks can be grouped by UIDs, sorted by sequence number and reassembled to form the original SeqBox containers.
This was submitted to us by the author of the project, so hopefully she or he can answer possibly questions in the comments.
From MarcoPon. Have You included in design considerations the kind of noise that occur on ‘air’ packets?
Congratulations on this ‘back to basics’.
Keep it simple, Keep it strong. Use At least 2 different tech for hashes, for every contained element. Have you considered -as as companion tool- user set, flexible redundancy -injection?
Stay away from encryption. Leave It to another predigesting tools.
Agreed. But I’m playing with adding a simple XOR with a password/pad (or something like that), as a way to hide SBX blocks (at least at some level).