The hard questions about Cotton.

For a rare thing: security, speed, and usability without sacrificing one to get the other. Cotton runs on a modern industrial-grade stack without demanding industrial patience. Someone sharing family photos should not need a manual. A power user should be able to run the whole stack, look under the hood, and never hit a toy ceiling. To both, the interface should feel telepathic: obvious actions happen immediately instead of hiding in menus. And files are not thrown into one faceless pile. Photos, video, documents, archives, and work data upload, open, preview, and share in ways native to their format. No hacks, no plugin scavenger hunts, and no compromises as a prerequisite.

In Nextcloud, I can literally change one line in Checker.php on the same disk, make isCodeCheckEnforced() return false, and the integrity check turns itself off (proof). No bypass and no forged report: the checker itself decides there is nothing to check. The checker and the PHP files it inspects are controlled by the same write access. /admin/security in Cotton is not protection at all. It is the board above the checkpoint. Even if nobody opens it, the official image still runs the process non-root, disables .NET diagnostics, and blocks dumps, while a forged database row without a valid MAC is rejected the moment it is used. In Nextcloud, one line in the checker's own source is enough. In Cotton, an attacker has to cross the container and process boundaries, become the running server itself, and seize the key. These are not two versions of the same check. One is a seal on the door; the other is access control at every checkpoint.

RCE literally means the attacker has become the Cotton process and can see its memory. At that level, Nextcloud, Seafile, and every other server lose too: a server cannot hide a secret from itself. The question is not whether a final level of compromise exists. It is how many boundaries must be crossed to reach it and what can be forged without the key. Protection is not there to perform magic after the server has become the attacker. It is there to make sure access to the disk or database alone is not enough. One mode survives even server-side RCE: E2E folders. Their keys stay on the clients, so a compromised server gets ciphertext and nothing more. For ordinary folders, Cotton reduces the attack surface. For E2E folders, it removes the server from the trust model entirely.

Ask a capable cybersecurity graduate to implement streaming file encryption on the standard .NET stack, and they will draw the same design. Not because Cotton is simplistic, but because good cryptography leaves no room for personal style. The format can be custom. The cryptography cannot. HKDF-SHA256 separates the root secret into independent keys; a cryptographically secure generator creates a fresh 256-bit key for every file; AES-256-GCM encrypts the data with 96-bit nonces and 128-bit authentication tags; metadata is bound as AAD; and the per-file key is protected separately by the master key. Nonces do not repeat within a file: a random prefix is combined with a 64-bit chunk counter. Key material is wiped after use. No proprietary magic: just textbook envelope encryption on platform primitives. There has not been an external audit yet, and that is a real limitation. But the absence of an audit does not turn a standard design into a home-grown cipher.

No. Being young means a project does not have a long history yet. It does not make the project automatically unreliable. If young projects are untrustworthy by definition, no mature projects can ever exist: without first users there is no real-world use, testing, or history. Demanding maturity up front is demanding a finished painting before the first brushstroke. If you chose Seafile, would you move your only copy of every file there on the first night and delete the old one? Of course not. Running both systems, testing recovery, and migrating gradually is not a special allowance for a young Cotton. It is how sane migrations to any storage system work. 'Do not make it your only copy on day one' says nothing about Cotton. It only says that migrating without a backup is stupid in any system. GitHub stars are not a verdict either. They are neither an installation registry nor an audit, just the number of account holders who clicked a button. Plenty of self-hosters do not have an account there at all. Look at what can already be verified: the architecture, the changes, the recovery path, and the source. Maturity sometimes means experience. Sometimes it means a stack everyone is afraid to touch. Perl is mature. PHP is mature. Fortran is older still. By that logic, punch cards are unbeatable. Age is a biography, not a quality certificate. Every mature project started at zero. Cotton earns maturity the same way: release by release, user by user.

No. Data is hostage when recovery has never been proven. Plain files on a disk do not revive a dead drive, undo deletion, or beat ransomware. A master key is not a scandal; it is what encryption means. A backup without the key is not a backup. Test the whole system: data, database, key, and an actual restore. Cotton does not wait for a user to discover a broken file: it samples chunks in the background and rechecks their integrity so a quietly dying disk reveals itself first. That is less comforting than recognizing filenames. It is also honest.

Your old Cotton instance died? Point a clean one at the storage and give it the master key; it will restore the database from its own backup. Do not want to run Cotton at all? The format and read path are open: turning the chunks back into files takes a small converter, not an archaeological dig through a proprietary format. No license, cloud service, or author stands between you and your data.

Only when the server confirms a match before upload. That is why Cotton's first setup question is 'For family' or 'With strangers?' Pick 'With strangers' and Cotton accepts the whole file before deduplicating it on the server: no oracle, storage savings intact. Pick 'For family' and the match happens before upload, saving bandwidth too. Same deduplication. Different trust model. Not a vulnerability. Just a setting written in plain English.

I hunt for my own mistakes: I regularly attack my server and catch vulnerabilities before they become GitHub issues. I also have access to specialized cybersecurity AI models, which let me test more attack scenarios and look for what I might miss alone. Security is not a box to tick in a vulnerability tracker: I use Cotton every day and trust it with my own data. If I disappear, open source will not conjure a maintenance team out of thin air, and nobody promises that it will. It gives you the right to continue: the code, build, format, and documentation remain open; Cotton can be forked, fixed, or handed to any developer without my permission. The bus factor affects future development, but it does not take the product or your right to control it away from you. When a closed product's owner disappears, you keep only what they chose to leave behind. Open source is not a prophecy about who will continue. It is the right to continue without permission.

Because Cotton is a file cloud, not an everything-suite held together by plugins. Everything file work actually needs is already built, in progress, or planned. For the rest, focused services are simply better: Grist for spreadsheets, 2FAuth for 2FA, Vaultwarden for passwords, Outline for notes and wikis, and Bulwark on top of Stalwart for mail. Decide who will do the job better: a plugin inside a suite, maintained by one generalist alongside dozens of others, or a standalone product built around that exact problem. Cotton is not trying to stuff the internet into one container. It builds a file cloud.

Because each one solves only part of the job. Seafile has an excellent storage and sync engine. Git also has objects, commits, trees, and snapshots. That does not make Git a good home cloud. Seafile's sync is strong, while its browser, previews, format handling, and free feature set remain thin. ownCloud Infinite Scale is modern inside, but for one owner it is a thin file app inside a heavy enterprise frame. OpenCloud bets on Spaces, federation, and Office, which makes it awkward for home use. Pydio Cells is a corporate collaboration platform where SSO and MFA begin in paid editions for 50 users and up. SFTPGo is transport; Filebrowser is a window onto a folder. Cotton does not have a monopoly on serious storage engines. Its difference is that a complete modern product already exists on top: previews and format-native workflows, deduplication across users rather than only within a library, encryption, E2E, WebDAV, clients, and automatic recovery. Not an engine instead of a product, and not a product sitting on a plain folder - both layers at once.

No. That is a migration, not a broken format. CTN1 predates the mandatory authenticated stream terminator; CTN2 adds it so a truncated file cannot pass as complete. Version 0.4.35 shipped a one-time background transition ahead of the upgrade: it rewrites legacy containers and prepares the instance for 0.5. The README warning and CTN1 check are temporary and will disappear after the upgrade window. A beta could have said, 'start over.' Cotton built a proper, safe bridge between formats instead. That is overkill for a beta. Cotton did it anyway.