Content-addressed chunks. Streaming AES-GCM with per-chunk auth tags. Compression before encryption. Manifests over filesystem or S3. One pipeline from HTTP to disk — no cross-runtime glue, no plugin layer, no patchwork.
The browser hashes chunks in a worker, uploads them in parallel, and only retries missing chunks after interruption. Small and large files follow the same route, so the system does not need a special fragile path for big uploads or a full-file memory buffer.
Cotton separates the layout graph from stored content. A visible file is a database-backed abstraction over manifests and chunks, not a single loose object sitting in a user folder. Folders, nodes, file versions, snapshots, manifests, and chunks each have clear jobs, which makes navigation, restore, deduplication, and cleanup predictable.
The storage backend only needs a small contract: write data for a key and read it back. Filesystem storage can place chunk blobs under hash-derived segments, while S3-compatible storage can use the same logical keys. Listing and delete support make verification and cleanup richer, but the core model stays simple.
Data is compressed before encryption and then written to either filesystem or S3-backed storage. Compression, encryption, and backend persistence are not optional afterthoughts; they are the normal ingest path, built around streaming buffers instead of loading the full object.
Reads are assembled from chunks into a byte stream without rebuilding a whole file first. That is why downloads, previews, media seeking, range requests, share pages, and WebDAV can all ride the same storage design.
Snapshots record references rather than copying the whole tree. Restore can switch layout state without turning rollback into a giant background copy job, while garbage collection still has a clear retention contract.
Background manifest hashing, storage consistency checks, preview work, token cleanup, and temp cleanup are part of the product path. Operators get explicit warnings instead of discovering silent storage drift later.
The architecture page is not asking visitors to trust a diagram. The product proof is visible in the storage vocabulary and page surface: chunks, manifests, snapshots, versions, range reads, WebDAV, previews, and integrity checks all point back to the same model.
Cotton fits best when you want a file cloud whose internals explain the product instead of fighting it. The same architecture that makes large files practical also makes recovery, sharing, previews, and cleanup easier to reason about.
A chunk-first storage engine is more deliberate than mounting a folder and calling it a cloud. If you mainly need a broad app suite or direct filesystem semantics, a groupware stack or simple file server may fit better.
Cotton is not a folder tree with a web skin. Upload, read, preview, share, restore, verify, and cleanup all depend on the same content model: chunks, manifests, layout records, and explicit references.
Folders, nodes, and visible files are layout state. Stored bytes live behind manifests and chunks.
Chunks and manifests make deduplication, idempotent upload, verification, and reuse part of the normal model.
Range responses, video seeking, and preview extraction can assemble byte ranges without rebuilding whole objects first.
Snapshots, shares, versions, backup artifacts, manifests, and live files all need to be visible before reclaim is safe.
The visible file tree can move, restore, share, and version while content identity stays stable underneath. That is why the same architecture keeps showing up in performance, previews, snapshots, WebDAV, and integrity checks.
The model is more explicit than a plain filesystem wrapper. Cotton needs metadata correctness, background verification, and careful reclaim logic because the database is the source of truth for live references.
No. Cotton uses a content-addressed storage engine with chunks, manifests, layout records, snapshots, and background verification. It can still expose WebDAV for compatibility, but the internal model is not a plain folder tree on disk.
It makes duplicate content safe to reuse, interrupted uploads cheaper to resume, snapshots less copy-heavy, and integrity checks more direct.
No. The architecture makes snapshots, versions, restore, and cleanup more coherent inside a live instance. Full server loss still needs tested backups and a restore plan.