-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Headers #6
Comments
We could use a bitmask matrix to indicate whether a storage format is used to encode something. This would allow skipping certain steps if desired. Then, formats can be referred to by their bitmask. Carbonado 0 means no compression, encryption, stream verification, or error correction. Carbonado 15 would be all of them. If we used a byte in a magic number header, that'd also leave room for future formats. Using a varint instead would futureproof this even more. |
Bitmask for Carbonado formats c0-c15
Verifiability is needed to pay others for storing or hosting your files, but it inhibits use-cases for mutable or append-only data other than snapshots, since the hash will change so frequently. Bao encoding does not have a large overhead, about 5% at most. Any data that is verifiable but also unencrypted is instead signed by the local key. This is good for signed compiled binaries or hosted webpages. Estimated encoding overhead
All formats have a magic number and Carbonado header that includes necessary information for its specific formats. |
Each of the four formatting steps should be configurable as to whether they can be used. They should also be built in as conditionally compiled features.
These options should be tracked, perhaps in a compiletime-generated 4-bit bitmask. This can then be added to the magic number, and also the bech32m filename.
This should also make #5 easier to debug.
The text was updated successfully, but these errors were encountered: