Warum ich die operativen Anweisungen meines Labs von Makefiles auf go-task migriert habe — mit Namespaces, Preconditions, Prompts und einem Überblick, was sich damit alles steuern lässt
Ein Follow-up zum GitOps-Aufbau
meines Labs: Wenn das Repository den Zustand beschreibt, brauche ich trotzdem eine Handvoll Anweisungen, um den Cluster zu bedienen — bootstrappen, Secrets rotieren, Backups zurückspielen, Zertifikate erneuern. Lange lebten diese Anweisungen in Makefiles. Heute steckt jede davon in einem
go-task
-Taskfile, und der Umstieg war eine der besseren kleinen Entscheidungen.
Ein Synapse-Homeserver im Lab, der schmerzhafte Sonderfall Ende-zu-Ende-Verschlüsselung für meinen Bot ZeroClaw — und das Tooling, das ich bauen musste, um ihn beherrschbar zu machen
Ich betreibe einen eigenen
Matrix
-Homeserver —
Synapse
, erreichbar unter matrix.this-is-fine.social. Der laufende Betrieb ist erfreulich langweilig; ein Aspekt aber hat mich mehr Nerven gekostet als alles andere zusammen: die Ende-zu-Ende-Verschlüsselung, und zwar ausgerechnet für meinen automatisierten Teilnehmer, den Bot ZeroClaw
. Dieser Beitrag handelt von diesem Schmerz — und dem Tooling, das ich bauen musste, um ihn zu zähmen.
Was eine peer-to-peer-Git-Forge für die Open-Source-Welt bedeutet — und warum ich gerade all meine Repos von SourceHut zu Radicle umziehe
Git ist von Haus aus dezentral — aber die Art, wie wir damit zusammenarbeiten, ist es längst nicht. Pull Requests, Issues, Reviews: All das lebt auf zentralen Plattformen, die das Protokoll selbst gar nicht braucht.
Radicle
holt diese Kollaborationsschicht zurück ins dezentrale Modell, und genau deshalb ziehe ich gerade nicht nur mein Lab, sondern alle meine Repos dorthin um — und das sind einige, überwiegend die Quellen meiner Container-Images.
Vom Vorgänger OpenClaw zum schlankeren, sichereren ZeroClaw — wie ein KI-Agent meine Cluster überwacht, über Matrix spricht und Änderungen als Radicle-Patches vorschlägt
In meinem Lab läuft ein KI-Agent mit, der die Cluster im Auge behält, mir auf Matrix Bescheid gibt und Reparaturen nicht selbst durchdrückt, sondern als Patch vorschlägt. Er heißt ZeroClaw — im Chat nur Claw — und ist der schlankere, vorsichtigere Nachfolger meines früheren Agenten OpenClaw. Dieser Beitrag zeigt, wie er integriert ist, über welche Kanäle er kommuniziert und wie der Weg von einer Idee bis zum gemergten Patch aussieht.
Für die deklarative Konfiguration und den Rollout verwende ich Home-Manager — wie WeeChat dabei als reproduzierbares Nix-Artefakt entsteht und sich am Bouncer einklinkt, habe ich separat beschrieben
. Hier geht es um die Konfiguration selbst. Mein Flake zur Verwaltung aller Systeme findest du hier
; einen ausführlicheren Blogpost dazu schreibe ich bei Gelegenheit.
Vier IRC-Server stehen in irc.conf — drei laufen über den Bouncer, einer (Quakenet, mehr Gewohnheit als Vernunft) direkt:
libera, hackint und local — den cluster-internen IRCd
— erreiche ich über den ZNC-Bouncer, der unter bnc.this-is-fine.social/+6697 via TLS hängt. Für ZNC aktiviere ich zusätzliche IRC-Capabilities (znc.in/server-time-iso, znc.in/self-message, …).
Die Serverpasswörter liegen verschlüsselt in ${sec.data} und die Passphrase hierfür wird beim Startup von WeeChat über pass mit
passphrase_command = "pass show apps/weechat/passphrase" entschlüsselt.
