← KADAI Deutsch
KADAI · as of 3 October 2026 · shown on the seed machine, valid for every machine

What gets pulled and started, when and where

Three periods in the life of a KADAI machine: the one-time first boot (the ceremony), every later boot (the rule), and ongoing operation up to shutdown. Colors show the direction: pull, push, start, human.

pull - from the repo host / Nextcloud onto the machine push - from the machine to the repo host start / trigger - inside the machine human - input or manual step

1 · First boot - once, the ceremony

The seed image is generic. Only the ceremony turns it into your machine: it generates its own keys, in the security chip where it has one, fetches the kernel repo, unlocks the master identity with your passphrase and enrolls itself in the recipients list. On a running Ubuntu the assistant from the start package (start/) does the same; it also enters the deploy key itself, through a token that only the master identity opens. Step 4 then falls away.

You Machine (Seed-VM) repo host · kadai-kernel Nextcloud kadai/seeds/*.qcow2 fetch image, create VM VM boots from the seed 1 Login kadai / kadai kadai-setup starts (console) 2 generated locally, from randomness: sync key (ssh) + age key, in the chip or as files 3 Add deploy key(package: the assistant does it) Deploy Keys (write) 4 me.md.age · scripts git clone ~/kadai (repo copy) 5 Master passphrase unlock master-key.age in RAM only 6 decrypt kernel → me.md add own key to .kadai-recipients; re-encrypt kernel and keyring password 7 enroll commit install units: kernel sync, autosave, hourly push, compile linger on → section 2 applies from now on 8
The machine identity (step 3) comes into being from nothing, on the machine; your personal identity already lives in the repo. Steps 6–7 marry the two: from then on the machine is a full recipient and never needs the passphrase again. The only step outside the machine is the deploy key (4); on the package path the assistant takes it over.

2 · Every boot - the rule

From the second boot on, everything runs without a ceremony. The order is enforced: the kernel is decrypted before Plasma starts; the desktop is reconciled before you unlock the lock screen.

repo host System (root) Your services (kadai) Plasma · screen You 1 UEFI → systemd-boot → Linux 2 NetworkManager: DHCP 3 SDDM: autologin kadai systemd --user starts 4 kadai-kernel.service age -d → me.md (plaintext) me.md.age · spec git pull (merge), then push 5 Plasma session starts Before= enforces the order 6 “Welcome, Jan - kernel loaded” 7 kadai-compile.service reconciler: spec vs. actual read actual state via DBus apply only the difference 8 lock screen (autostart) 9 Your desktop: Activities, widgets Password
Thanks to linger, step 4 already runs at boot, not only at login; the ordering Before=plasma-workspace.target guarantees that Plasma (5) starts only after the kernel has been decrypted. The reconciler (7) is idempotent: if the desktop is already right, it does nothing. All you see of this is 8 and 9.

3 · Operation & shutdown - what flows back

Whatever you change during the session flows back through exactly one channel: the repo with kernel, keyring and vault. Every ten minutes a local save, without network and without a key; it goes out at login, logout and hourly, over the sync key that asks for no presence. Other machines receive it at their next boot or their next hourly push, which then pulls first.

repo host This machine Nextcloud Other machines kadai-kernel-autosave.timer · every 10 min me.md changed? → encrypt to all recipients → commit, locally auto-save commit Login, hourly, logout / shutdown: kadai-kernel-push.timer, ExecStartPost, ExecStop → push; rejected → merge per file → push .kadai-storage.sh offload / restore / pin on demand; a placeholder stays local; every move is logged kadai-storage/… on next boot: git pull → decrypt → greeting with the new state build VM, future ones
Saving and pushing share the same check (SHA-256 of the plaintext): only real changes produce commits - otherwise the non-deterministic encryption would produce phantom commits every ten minutes. If a push is rejected because another machine got there first, git merges per file with a driver of its own: the kernel per entry, the keyring per entry, the vault not at all, the other version is kept next to it. The git history thus doubles as the log of which machine knew what, and when.

Where things live

The question “does it travel with me?” is answered by location: only what lives in the repo reaches every machine.

LocationWhatTravels?
Your headthe master passphrase (lab value - not printed here)yes - that is its purpose
Repo · kadai-kernel (own Forgejo server)me.md.age (kernel, encrypted to all machines), .kadai-recipients and .kadai-revoked, master-key.age, keyring.kdbx with keyring.pass.age (system accesses), vault.kdbx (your passwords), desktop-spec.json, all scripts, bootstrap.shyes - to every machine
Machine, localage machine key and sync key (in the security chip, otherwise as files), decrypted me.md, observation logs (sync, suggestions), autologin/lock configuration, everything in Plasma the spec does not coverno - deliberately not (keys) or not yet (logs, configuration)
Nextcloudseed images under kadai/seeds/; offloaded files under kadai-storage/seeds: for everyone · files: restorable on demand
DerivedActivities, colors, panel widgets - generated by the reconciler from the specrebuilt on every machine
The boundary between “local” and “in the repo” is the job of the next build-out stages: autologin and lock in bootstrap.sh, more desktop properties into the spec, applications as a declared package list, observation logs as a synced layer of their own. The Nextcloud access moved in October 2026: from a local file into the keyring, which travels. What you want from the system belongs in the repo - what the machine is stays local.