Self-Encryption
Self-encryption is the content-processing step that turns input bytes into a DataMap plus encrypted chunks before those chunks are stored elsewhere.
Why it matters
This is the layer that makes uploads content-addressed and client-side encrypted. Higher-level tools such as antd and ant-core rely on it to produce the DataMap and chunk layout used for later retrieval.
How it works
The crate surface revolves around a few core operations:
encrypt(bytes)returns(DataMap, Vec<EncryptedChunk>)decrypt(data_map, chunks)reconstructs the original contentstream_encrypt(...)andstreaming_decrypt(...)support streaming flows for files and large payloads
The implementation uses:
BLAKE3 for chunk hashing
ChaCha20-Poly1305 for authenticated encryption
Brotli compression during chunk processing
Chunk addresses are derived from the encrypted content. That is why the higher-level storage model is content-addressed: if the content changes, the resulting encrypted chunks and their addresses change too.
Important limits from the crate itself:
MIN_ENCRYPTABLE_BYTESis3MAX_CHUNK_SIZEis4_190_208bytes
The crate stores chunk metadata in a DataMap, and the DataMap can be shrunk recursively when it grows beyond the immediate chunk set. In the higher-level SDK and CLI workflows, that DataMap is what turns a set of encrypted chunks back into retrievable content.
Practical example
The crate does not store anything on the network for you. Persisting the encrypted chunks and keeping the DataMap somewhere safe is the caller's responsibility. That is why higher-level tools build on top of it: they handle payment, network storage, and the public/private retrieval choices around the DataMap.
Upstream sources
Related pages
Last updated