KDAI · technische Übersicht · Stand 1. September 2026

KDAI unter der Haube

Die Grundidee: Ein KI-orchestrierter Desktop — nicht installiert, sondern instanziiert. Grundlage ist ein Persönlichkeits-Kernel: eine kleine, verschlüsselte, versionierte Selbstbeschreibung, die an beliebigen Orten instanziiert und fortgeführt werden kann — auf jedem Rechner, in jeder VM, notfalls im Browser. Jede Instanz kompiliert daraus denselben Desktop, compile(me.md, Umgebung) → Desktop, und was sie lernt, fließt in den Kernel zurück: ein System, das der Person folgt statt der Maschine.

Diese Seite erklärt, wie: das Datenmodell, die Schlüsselarchitektur, die vier Protokolle, die Steuerung über git als Control-Plane — und das Threat-Model mit seinen heutigen Lücken. Alles hier Beschriebene läuft, sofern nicht ausdrücklich als Design markiert (validiert August 2026, Plasma 6.6 / Ubuntu 26.04).

1 · Datenmodell: der Kernel

Eine Markdown-Datei (me.md) mit YAML-Frontmatter. Fünf Sektionen mit explizitem Vertrauensgefälle: identity und facts (verbindlich) · preferences (weich) · rules (unverletzlich ohne Zustimmung je Sitzung) · episodic (aktuell, möglicherweise veraltet). Jeder Eintrag trägt eine stabile ID ({#r-001}) und eine Provenienz-Zeile — wann, von wem (Mensch, KI, Maschine). Das Frontmatter reserviert eine DID (did:kdai:…, bislang ohne externe Registry). Sektionen sind als MCP-Ressourcen (me://rules …) adressierbar gedacht — der eine Engpass, an dem Regeln durchgesetzt und Zugriffe protokolliert werden.

Das Invariant: Der Kernel speichert Bedeutung, nie Konfiguration. „Vormittags fokussiert, minimale Ablenkung" — nicht „Panel unten, Widget X". Plattform-Backends übersetzen; deshalb ist derselbe Kernel auf Plasma, in einer VM oder in einem Chat-Client brauchbar.

2 · Schlüsselarchitektur

MaterialTypEntstehtLiegtZweck
Master-Identitätage X25519einmal, bei der Gründung (Browser oder vertraute Maschine)nur passphrase-verschlüsselt (scrypt) als master-key.age im Repo; Klartext nie persistentWurzel der Autorisierung: entschlüsselt den Kernel, nimmt neue Geräte auf
Passphrasemenschliches Geheimnisbei der Gründung gewähltausschließlich im Kopf; wird bei Eingabe direkt an scrypt verfüttertWächter der Master-Identität — bewusst austauschbar (später FIDO2/Biometrie)
Maschinen-Identitätage X25519, je Gerätbeim Erstboot, lokal aus dem CSPRNGprivat: nur auf dem Gerät (~/.config/kdai/age.key, 0600); öffentlich: im RegisterAlltagsentschlüsselung ohne Passphrase
Deploy-Keyssh ed25519, je Gerätbeim Erstboot, lokalprivat auf dem Gerät; öffentlich beim Repo-HostTransport-Autorisierung zum Repo (read/write) — orthogonal zur Inhalts-Verschlüsselung
Mensch Repo (git-Host, sieht nur Ciphertext) Gerät n Passphrase nur im Kopf master-key.age Master-Identität, scrypt-verschlossen .kdai-recipients Geräteregister: 1 age-Pubkey je autorisierter Maschine + Master me.md.age Kernel, verschlüsselt an alle Empfänger Skripte · Spec · Historie Mechanik reist mit; git = Audit-Log entsperrt bestimmt die Empfängermenge age-Maschinenschlüssel privat, verlässt das Gerät nie · Pubkey im Register Deploy-Key (ssh) Transport-Tor: clone / pull / push me.md (Klartext) nur lokal, gitignored; bei Login entschlüsselt age -d mit Maschinenschlüssel Tor 1 (ssh): darf ich das Repo holen? Tor 2 (age): kann ich den Inhalt lesen? — unabhängig voneinander
Kein IdP, keine PKI, kein zentrales Verzeichnis: Identität ist Besitz (Repo-Zugang) + Wissen (Passphrase) + ein selbstverwaltetes Geräteregister im eigenen Repo. Der Repo-Host ist reiner Ciphertext-Speicher mit Metadaten-Sicht. Widerruf eines Geräts = Zeile aus dem Register streichen + neu verschlüsseln.

3 · Die vier Protokolle

Gründung (einmal pro Person — im Browser, komplett clientseitig)

  1. Deterministischer Dialog erfragt Name, Präferenzen, Passphrase, Repo-Ziel; Sprache/OS/Zeitzone werden erkannt, nie gefragt.
  2. Im Browser: Master-Identität erzeugen (age-js) → master-key.age (scrypt via Passphrase) → Kernel aus Vorlage generieren (inkl. Default-Regeln r-001…r-003) → an Master verschlüsseln → Register mit Master-Pubkey.
  3. Publikation: GitLab-API (Token) oder ein kopierbares Bundle-Skript (armored age-Dateien als Heredocs, git init && push). Geheimnisse werden nach Gebrauch aus dem Speicher gelöscht; nichts davon verlässt den Browser unverschlüsselt.

Beitritt / Enrollment (einmal pro Gerät — Selbst-Autorisierung)

  1. Gerät erzeugt lokal age-Schlüssel + Deploy-Key (CSPRNG); Deploy-Key wird beim Repo-Host hinterlegt (heute manuell — der eine menschliche Trust-Schritt).
  2. git clone → Gerät hat Ciphertext, kann nichts lesen.
  3. Passphrase-Eingabe → Master-Identität wird nur im RAM entsperrt → Kernel entschlüsselt → Gerät hängt seinen Pubkey ans Register → verschlüsselt den Kernel an die erweiterte Empfängermenge neu → committet + pusht („enroll").
  4. Ab jetzt Alltagsbetrieb ohne Passphrase; Klartext-Master und Passphrase werden verworfen.

Jeder Boot (Steady State)

  1. systemd-User-Instanz startet beim Boot (Linger): git pull --rebase → age -d mit Maschinenschlüssel → me.md; Ordnung Before=plasma-workspace.target garantiert: Kernel vor Shell.
  2. Grafische Sitzung startet (Autologin + sofortige Sperre); Begrüßung meldet Namen + Kernel-Commit-Zeit.
  3. Reconciler: liest Ist-Zustand der Shell (DBus), diff't gegen desktop-spec.json aus dem Repo, wendet nur die Differenz an. Idempotent — zweiter Lauf: null Operationen.

Sync (fortlaufend)

  1. Alle 10 min und bei Logout/Shutdown: SHA-256-Wächter über me.md — nur bei echter Änderung wird neu verschlüsselt (age ist nicht deterministisch; ohne Wächter gäbe es Phantom-Commits), committet, gepusht.
  2. Andere Geräte erhalten den Stand bei ihrem nächsten Pull. Konflikte: --rebase --autostash; die git-Historie ist zugleich das Audit-Log (welches Gerät wusste wann was).

4 · Steuerung: git als Control-Plane

Es gibt keinen Steuer-Port und keine Fernsteuerungs-Session. Wer das System ändern will — Mensch oder Agent, von jedem Gerät — ändert Deklarationen im Repo: den Kernel (Bedeutung) oder die Desktop-Spec (abgeleitetes Soll). Jede Maschine reconciled sich beim nächsten Pull selbst. Eingehende Konnektivität ist ausschließlich Debug-Werkzeug. Das ist dieselbe Bewegung wie GitOps, nur dass die „Infrastruktur" hier eine Person samt ihrer Arbeitsumgebung ist — und der Diff-and-Apply-Schritt nötig bleibt, weil Plasmas eigener Layout-Load additiv ist (validierter Befund, nicht Annahme).

5 · Agenten: Rolle statt Modell, Regeln als Policy

Die KI ist eine Rolle mit Regressionskaskade: Frontier-Cloud → alternative Cloud (der Kernel ist vendor-neutral) → lokales Modell → deterministischer Boden: alle Mechanik (Sync, Enrollment, Reconciler, Storage) ist skriptbasiert und läuft ohne jede KI — Totalausfall aller Modelle degradiert das System zu „dümmer, aber betriebsfähig". Der Router ist Policy-Gate und Dispatcher zugleich: rules aus dem Kernel binden jede Stufe (nichts aus dem Kernel ohne Zustimmung je Sitzung in die Cloud; keine identitätsgebundenen Anfragen; Speicherentscheidungen ≥ 7 Tage umkehrbar und protokolliert). „Nicht erreichbar" und „darf nicht erreichbar sein" lösen dieselbe Regression aus.

6 · Threat-Model — was hält, was (noch) nicht

Angriff / VerlustStand
Repo-Host kompromittiertliest nur Ciphertext (Kernel) + Klartext-Mechanik/Spec + Metadaten (Commit-Zeiten, Größen, Gerätenamen in Kommentaren). Kann Historie manipulieren — Commits sind nicht signiert (Lücke, s. u.).
Gerät verloren/gestohlenWiderruf: Registerzeile streichen, neu verschlüsseln, Deploy-Key beim Host löschen. Aber: alte Ciphertexte der Historie bleiben für den alten Schlüssel lesbar (kein Re-Key der Vergangenheit) und der Klartext-Kernel liegt auf dem Gerät — ohne Festplattenverschlüsselung real exponiert.
Passphrase-Bruteforce offlinemöglich für jeden mit Repo-Kopie; scrypt verteuert, ersetzt aber keine starke Passphrase. Der Wächter ist als austauschbar entworfen (FIDO2/Biometrie statt Passphrase — Design).
Böswilliger Kernel-Pushwer Schreibzugang + Registerplatz hat, ist eine autorisierte Maschine — by design. Schutzlinie ist das Register + Transport-Tor, nicht der Inhalt.
Lücke: unsignierte CommitsEnrollment- und Sync-Commits sind nicht kryptografisch ans Gerät gebunden; Gerätesignaturen (ssh-Signing mit dem Deploy-Key) wären der natürliche nächste Schritt.
Lücke: Schlüssel auf PlatteMaschinen-age-Schlüssel ist eine Datei (0600), kein TPM/Keychain/Secure-Enclave-Gating; Seed ohne LUKS. Beides Design-Backlog (§4 der Architektur).
Lücke: keine Forward Secrecystatische age-Empfänger; ein später kompromittierter Maschinenschlüssel öffnet alle Ciphertexte, die je an ihn gingen. Mitigation heute: Historie neu aufsetzen bei Schlüsselverlust.
Lücke: Frühe Historiedas Laborsystem trägt Klartext-Beispieldaten in alten Commits; produktive Systeme starten mit frischer Historie (Gründungsseite tut das bereits).
Bewusste Nicht-Ziele: kein zentraler Recovery-Dienst (Passphrase verloren + kein autorisiertes Gerät mehr = neuer Master nötig), keine Anonymität gegenüber dem Repo-Host, kein Schutz gegen einen kompromittierten laufenden eigenen Rechner — dort liegt der Kernel im Klartext, notwendigerweise.

7 · Status

Validiert (Aug 2026): Gründung im Browser · Enrollment per Passphrase in frischer VM · Multi-Device (3 Registereinträge) · verschlüsselter Sync mit Audit-Historie · Boot-Ordnung Kernel-vor-Shell · idempotenter Reconciler · Storage-Tier (Nextcloud, protokolliert/umkehrbar) · generisches Seed-Image (arm64). Design: MCP-Modul-Laufzeit mit Manifest/Sandbox · lokales Modell als Default-Agent · Hardware-Gating der Schlüssel · Commit-Signaturen · x86_64/VHDX-Pipeline · Launcher-Kaskade bis zum Browser-Boden.

KDAI ist ein Projekt von Jan Mühlig (muehlig@relevantive.de). Vertiefung: KDAI-architecture.md (Schichten, Entscheidungen, §12 Seed & Identität), KDAI-seed.md (Image-Bau und Zeremonie), me.example.md (Kernel-Format). Krypto: age (X25519, scrypt für die Passphrase), ssh ed25519 für Transport, git als versionierter Ciphertext-Speicher.