Onset: version control where nobody waits and nothing gets lost. The on command, its core and onset-server.
| 6 | - **Anything can be undone.** `vcs undo` steps back through what you did (a land included). `vcs restore <path> --at "10 min ago"` brings a file back from any earlier save, `--from 41` from any version of main. |
| 7 | - **Landing is never lost to a race.** The host merges each land into main in the order it arrives, so a land is never refused because someone else landed first. When two changes really conflict, the second gets the conflict to resolve and main is unchanged. |
| 8 |
| 9 | ## The project |
| 10 |
| 11 | - **`vcs check`** reads every object your machine keeps and checks it against its ID, and asks the host to check its copy: every version's ID against its contents and the version before it, and that everything main needs is stored. It exits 1 on damage. |
| 12 | - **`vcs rollback --to "2h ago"`** (project owners) puts the whole hosted project back as it was at any time in the last 30 days, and prints a bookmark that reverses it. Workspaces follow on their next `vcs sync`, keeping their own unlanded edits. |
| 13 | - **Every version names the one before it** by ID, so history can't be quietly rewritten, and everything is stored by content hash, so damage shows up as a mismatch. |
| 14 | - **Signed lands:** after `vcs key`, every land from that machine is signed with its own key; the host checks it against the lander's account, and `vcs verify` checks it again on any machine. `vcs settings signed=required` refuses unsigned lands. |
| 15 | - **Taking something out on purpose:** `vcs purge <path> --yes` (owners) removes a file or folder from the whole history and deletes its content, rewrites the git view, and takes it off other machines when they next sync. It can't be undone, and a project can't be rolled back to before it. |
| 16 | - **The git view is a second copy** of main's history in another system (minus private paths), kept current within seconds. |
| 17 |
| 18 | ## What lands |
| 19 |
| 20 | - **Likely secrets are stopped** before they land: well-known formats of cloud, code hosting, payment, chat, AI and package-registry keys, Upstream tokens and private keys, only in lines a change adds. `--allow-secrets` overrides it and is recorded. |
| 21 | - **Private paths:** `vcs access <path> @person @group` makes a folder visible only to them. It's left out of everyone else's workspaces, diffs, logs and API answers, and out of the git view. |
| 22 | - **Approvals:** `vcs settings approvals=1` makes a land wait until someone other than its owner approves exactly what lands. |
| 23 | - **Nothing can write into `.git` or `.vcs`.** A path can't name either folder in any spelling a disk treats as the same (`.GIT`, `.git.`, `git~1`), so a project can't plant git hooks in the folders it's written to. Hosts refuse it, imports leave it out, and vcs never writes one. On Windows, vcs refuses names Windows can't hold instead of writing somewhere else. |
| 24 |
| 25 | ## The host |
| 26 |
| 27 | - **Upstream's host checks everything it's sent**: every object against its ID, every size against a limit, every compressed object as it opens (so a small upload can't claim to be gigabytes). Its parsers are tested against hundreds of thousands of corrupted and random inputs (`core/tests/hostile.rs`). |
| 28 | - **Encrypted at rest:** a project's stored objects are encrypted with a key of its own (AES-256), so storage alone, without the host's secret, reads nothing. The host itself still reads private folders and mine files, since it merges and checks what lands. |
| 29 | - **Accounts, roles and tokens are Upstream's.** The host never stores a token; it asks Upstream who a token belongs to and what that person may do in the repository, and caches the answer briefly. On your machine, the token sits in a file only you can read. |
| 30 | - **Self-hosting:** `vcs-server` keeps everything in one folder (SQLite and objects). Back up that folder; `vcs check` works against it too. |
| 31 |