Range reads through AES-GCM chunks. Per-chunk auth tags verify the slice on the fly. No temp file, no full download. Most self-hosted clouds decrypt to disk first. This one assembles the byte range from the encrypted store directly.
A naive encrypted chunk store has an ugly read path: rebuild the full file into memory or a temporary object, then let the browser or preview tool seek inside that rebuilt copy. That wastes RAM, disk, time, and operator patience.
Cotton assembles a single seekable stream from multiple chunk streams. Seek locates the target chunk by cumulative offsets and switches the underlying chunk stream so reads continue from the correct physical piece.
The same stream shape can serve HTTP Range requests and partial downloads. The product result is simple: large files can be read in pieces instead of becoming a full-object transfer every time.
Video preview generation can point FFmpeg at a range-capable local stream bridge. FFmpeg can ask for metadata and frames through byte ranges without Cotton writing a complete temporary source file first.
Seeking is not just concatenating plain files. Cotton still has to preserve per-chunk AES-GCM authentication, nonce discipline, compression ordering, chunk boundaries, and concurrent range reads without trusting unauthenticated bytes.
Because the abstraction is chunk streams rather than a single local file path, the same logical model can work when chunks live behind filesystem storage or S3-compatible object storage. The backend changes, but the read contract stays stable.
The proof is a concrete read shape: manifest offsets identify chunks, the logical stream seeks to the right chunk, processors read back through the backend, crypto, and decompression stages, and callers receive a normal stream or HTTP Range response.
This is one of the differences between a storage engine and a real file cloud. The file can be large, encrypted, chunked, previewable, shareable, and still readable by slice.
Seekable chunk reads make partial access possible. Browser codec support, FFmpeg availability, file corruption, client behavior, and deployment performance still decide what a specific media file can preview or play.
The interesting part is not that chunks exist. The interesting part is that Cotton can serve useful slices from encrypted chunked storage while keeping the normal storage pipeline intact.
Downloads and preview tools can read slices without rebuilding the whole object first.
Range-capable reads give video players and preview generators the byte access they expect.
Seeking still has to respect per-chunk AES-GCM tags and nonce layout before bytes are trusted.
The stream abstraction can sit over filesystem chunks or S3-compatible object storage.
That is why previews, posters, resume, range downloads, and media seeking belong in the architecture story. The user-visible feature is ordinary playback and partial access; the proof is the seekable encrypted stream underneath.
No. The seekable read path can assemble the requested bytes from stored chunks as a logical stream, so range downloads and previews do not need a full temporary source file first.
FFmpeg can request the parts it needs through a range-capable stream bridge. That helps poster extraction and legacy-video preview paths without preconverting or rebuilding the complete source object first.
It can if implemented carelessly. Cotton's public claim is narrower: per-chunk authenticated storage can still support seeking when the pipeline preserves chunk boundaries, nonce/authentication rules, and processor ordering.
No. Browser codec support still matters. Seekable storage provides the byte-access foundation; native playback or HLS preview support depends on the file type and generator path.