# Intent: XMPP/Prosody-Umzug von pinix nach blunix

## Ziel

Den kompletten XMPP-Stack (Prosody-Server, Web-Frontends, Zertifikatsverwaltung,
Forgejo-Benachrichtigung) von `pinix` nach `blunix` umziehen, mit derselben
Resilienz-Motivation wie beim bereits abgeschlossenen Forgejo-Umzug
(`docs/roadmap.md`, "Forgejo-Umzug von pinix nach blunix — erledigt
(06.09.2026)"): Erreichbarkeit unabhängig von `pinix`-Ausfällen.

## Umfang

- Prosody-Server (`hosts/pinix/localServices/prosody/setup-prosody.nix`) inkl.
  aller virtualHosts (`${domain}`, `bot.${domain}`), MUC-Konfiguration,
  HTTP-Upload (`httpFileShare`) — Modul zieht nach `blunix` um.
- Vollständige 1:1-Datenübernahme von `/var/lib/prosody` (Accounts, Roster,
  MUC-Archiv, Uploads) von pinix nach blunix. Bestehende MUC-Bot-Affiliations
  (z. B. `update@muc`, `lobby@muc`) bleiben dadurch automatisch erhalten.
- xmpp-web-Frontends (`chat.0ff.space`, `plaza.0ff.space`,
  `hosts/pinix/localServices/xmpp-web.nix`) inkl. nginx-Reverse-Proxy ziehen
  mit um.
- TLS-Umstellung: weg vom manuellen Zertifikats-Kopierprozess (aktuell
  dokumentiert in `hosts/pinix/localServices/prosody/README.md`, Abschnitt
  "Refresh the TLS certificate"), hin zu direktem Zugriff auf die von Traefik
  verwalteten Zertifikate, da Prosody jetzt co-located mit der
  ACME-Terminierung läuft.
- Wegfall der bisherigen blunix-seitigen Passthrough-Konfiguration, da das
  Backend nun lokal läuft:
  - `hosts/blunix/localServices/upload-prosody.nix` (Traefik-Loadbalancer →
    `tailnetIPs.pinix:5280`)
  - `hosts/blunix/localServices/traefik/xmpp-web.nix` (TCP-TLS-Passthrough für
    5222/5269 und die Web-Frontends)
- `wiki-update.sh` (Forgejo-Push-Benachrichtigung nach `update@muc.${domain}`,
  aktuell Teil von `hosts/pinix/localServices/webhook.nix`) zieht mit nach
  `blunix` um, in das dortige `hosts/blunix/localServices/webhook.nix`.
- Schnittstellenänderungen, die sich aus dem Umzug ergeben (Ergebnis des im
  Chat bestätigten Abgrenzungs-/Schnittstellenchecks):
  - **Forgejo → Webhook-Ziel:** wechselt von
    `tailnetIPs.pinix:9000/hooks/wiki-update` auf lokal (`127.0.0.1` oder
    `tailnetIPs.blunix`, konsistent mit den bestehenden blunix-Hooks). Die
    Repo-seitigen Webhook-URLs (Forgejo-DB, nicht Nix) für `nixos-config`,
    `website`, `dashboard`, `launcher` müssen manuell umgestellt werden.
  - **Forgejo `webhook.ALLOWED_HOST_LIST`**
    (`hosts/blunix/localServices/forgejo.nix`): pinix-Eintrag bleibt trotzdem
    bestehen, solange `gitpull-calendar-web` (calendar-web bleibt auf pinix,
    unabhängig von Vikunja) dort weiter empfängt — nur der `wiki-update`-Teil
    wandert.
  - **AdGuard internes DNS:** chat/plaza/upload sind aktuell öffentliche
    Hostnamen ohne internen Rewrite — voraussichtlich keine Änderung nötig,
    wird bei der Umsetzung gegengeprüft.
  - **LLDAP (blunix):** Prosodys LDAP-Bind wechselt von Tailnet-Adresse
    (`tailnetIPs.blunix:3890`) auf `127.0.0.1:3890` — reiner Lesezugriff,
    keine LLDAP-Konfigänderung.
  - **agent-xmpp-listener (blunix, bereits dort):** verbindet sich schon
    gegen `bot.${domain}`; Zielserver wird nach dem Umzug lokal statt entfernt
    erreichbar — sollte ohne Konfigänderung weiterlaufen, wird nach der
    Migration verifiziert.
  - **Secrets:** `go-sendxmpp.age`, `motd.age`, LDAP-Bind-Passwort — laut
    `secrets/secrets.nix` bereits für alle Hosts entschlüsselbar (siehe
    Annahmen); nötig ist nur das Laufzeit-Wiring (Pfad/Owner) in
    `hosts/blunix/localServices/secrets.nix`.
- pinix-Prosody-/xmpp-web-/`wiki-update`-Module werden nach dem Umzug
  deaktiviert, nicht gelöscht (Forgejo-Fallback-Muster:
  `systemd.services.<...>.enable = false`, Modulimport bleibt bestehen).

## Explizit ausgeschlossen

- `vikunja-update.sh` und der `vikunja@`-Bot-Account: bleiben unverändert auf
  pinix. Aktuell ungenutzt (Nutzer setzt Vikunja derzeit nicht ein), daher
  keine Prüfung oder Anpassung im Rahmen dieses Vorhabens.
- Vikunja selbst bleibt auf pinix, keine Migration.
- Kein festes Wartungsfenster erforderlich — der Umschaltzeitpunkt ist frei
  wählbar, keine harte Anforderung an Nahtlosigkeit.
- Root-Cause der pinix-Instabilität (siehe Forgejo-Umzugsnotiz vom
  31.07.2026) wird nicht untersucht — dieses Vorhaben behebt das
  Resilienz-Symptom, nicht die Ursache.
- Endgültige Stilllegung/Löschung des pinix-Moduls ist explizit spätere
  Nacharbeit, kein Teil dieses Vorhabens.
- Änderungen an `agents/catalog.json`, `agents/*.md` oder
  `agents/claude-settings/*.json` sind nicht Teil dieses Vorhabens — der
  Umzug berührt nur die Multi-Host-, nicht die Rollen-/Katalog-Grenze.

## Annahmen

- `go-sendxmpp.age` und `motd.age` sind laut `secrets/secrets.nix`
  (`publicKeys = users ++ systems`) bereits für alle Hosts inkl. blunix
  entschlüsselbar; erforderlich ist nur das Laufzeit-Wiring (Pfad/Owner) in
  `hosts/blunix/localServices/secrets.nix`, keine `agenix -r`-Rotation.
- LDAP-Auth bleibt inhaltlich unverändert gegen LLDAP (bereits auf blunix
  laufend), wechselt durch die Co-Location lediglich von Tailnet- auf
  Loopback-Zugriff.
- Federation/S2S (Port 5269) und öffentliche DNS-Einträge ändern sich nicht,
  da blunix bereits der öffentliche Ingress-Punkt für den XMPP-Traffic ist
  (aktuell per TCP-Passthrough).
- Die Umsetzung (Implementierung, Tests, Aktivierung) übernimmt die
  Admin-Rolle nach diesem Intent-Dokument; der Planner implementiert nichts
  selbst.

## Offene Risiken

- Split-Brain-Risiko wie beim Forgejo-Umzug: pinix darf während/nach der
  Migration nicht versehentlich reaktiviert werden (z. B. durch einen
  unabhängigen pinix-Redeploy, der das deaktivierte Modul wiederbelebt).
- TLS-Private-Key-Handling während der Datenübernahme erfordert dieselbe
  Sorgfalt wie der bestehende Zertifikats-Rotationsprozess (Key nie im
  Klartext loggen/committen, korrekte Dateiberechtigungen).
- Kurze Verbindungsunterbrechung für laufende Clients (z. B. Monal) beim
  Cutover ist zu erwarten; laut Nutzer unkritisch, da der Zeitpunkt frei
  wählbar ist.
- Karenzzeit vor der endgültigen pinix-Stilllegung analog Forgejo ("ein paar
  Tage bestätigter Stabilität auf blunix") ist einzuplanen, bevor das
  pinix-Modul entfernt wird.
- Die Repo-seitigen Forgejo-Webhook-URLs (nicht Nix-verwaltet) müssen manuell
  in der Forgejo-Weboberfläche für die betroffenen Repos umgestellt werden —
  leicht zu vergessen, da es sich nicht in `nix flake check` zeigt.

## Erfolgskriterien

- Prosody läuft vollständig auf blunix; c2s, s2s, MUC und HTTP-Upload sind
  funktional erreichbar.
- `chat.0ff.space` und `plaza.0ff.space` laufen von blunix aus, TLS wird über
  Traefik/ACME bezogen statt über den manuellen Kopierprozess.
- Bestehende Accounts, Roster, MUC-Historie und Uploads sind nach dem Umzug
  unverändert nutzbar.
- `wiki-update.sh` sendet Forgejo-Push-Benachrichtigungen erfolgreich von
  blunix aus in `update@muc.${domain}`.
- Der `agent-xmpp-listener` auf blunix funktioniert nach der Migration
  unterbrechungsfrei weiter.
- pinix-Prosody-/xmpp-web-/`wiki-update`-Module sind deaktiviert (nicht
  aktiv), Daten und Module bleiben als Fallback liegen.