36 lines · 6 KBtext/plain; charset=utf-8
Onset: version control where nobody waits and nothing gets lost. The on command, its core and onset-server.
| 6 | - **Anything can be undone.** `on undo` steps back through what you did (a land included). `on 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 | - **`on 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. Damaged objects on your machine are fetched again from the host; it exits 1 only for damage it can't repair. |
| 12 | - **Written to disk before anything names it:** your machine flushes objects to disk before its database records a save that names them, so a power cut costs at most the last few seconds of edits, never a broken save. |
| 13 | - **Merges never make two of one thing:** two functions with one name, a key twice in one YAML map or JSON object, two methods with one signature. Where git would call that merge clean, Onset calls it a conflict. |
| 14 | - **Landing again is safe:** if a land's answer is lost and you land again, the host answers as the first time; nothing lands twice. |
| 15 | - **`on 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 `on sync`, keeping their own unlanded edits. |
| 16 | - **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. |
| 17 | - **Signed lands:** after `on key`, every land from that machine is signed with its own key; the host checks it against the lander's account, and `on verify` checks it again on any machine. `on settings signed=required` refuses unsigned lands. |
| 18 | - **Taking something out on purpose:** `on 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. |
| 19 | - **The git view is a second copy** of main's history in another system (minus private paths), kept current within seconds. |
| 20 |
| 21 | ## What lands |
| 22 |
| 23 | - **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. |
| 24 | - **Private paths:** `on 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. |
| 25 | - **Approvals:** `on settings approvals=1` makes a land wait until someone other than its owner approves exactly what lands. |
| 26 | - **Nothing can write into `.git` or `.onset` (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. |
| 27 |
| 28 | ## The host |
| 29 |
| 30 | - **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`). |
| 31 | - **Agent sessions stay yours:** what an agent was asked and did, kept with the change it landed (secrets removed), is readable only by the change's owner and people they share the change with; not the project's owners, and never git. On Upstream's host it's sealed on your machine first (a key of its own, wrapped for your machines and theirs), so the host keeps it and can't read it. `on sessions off` stops it, and `on sessions delete` deletes it from the host. |
| 32 | - **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. |
| 33 | - **Sealed folders the host can't read:** `on access vault/ @sam --sealed` encrypts a folder's files on its readers' machines (XChaCha20-Poly1305, with a folder key wrapped for each of their machines' X25519 keys). The host keeps them but never has a key, so it can't show, merge, blame or edit them, and they stay out of git. Conflicts in them are merged on a reader's machine. The host does hand out machine keys, so `on access vault/` lists every machine that has the folder's key by fingerprint, to compare with `on key` on each. |
| 34 | - **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. |
| 35 | - **Self-hosting:** `onset-server` keeps everything in one folder (SQLite and objects). Back up that folder; `on check` works against it too. |
| 36 |