Implement TURN server (coturn) for WebRTC video calls

Add coturn Deployment with hostNetwork mode and init container for secret substitution. Include SOPS-encrypted shared secret, TLS certificate for turn.axion1337.chat, and Synapse TURN configuration with proper relay URIs and credentials.

Resolves DTLS timeout issues in RTC video calls by providing media relay for clients behind NAT/Firewall.

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>

.sops.yaml

@@ -0,0 +1,4 @@
+creation_rules:
+  - path_regex: .*.yaml
+    encrypted_regex: ^(data|stringData)$
+    age: "age14l0hwfqylwpemz5y2ghh2yxk0phszlnj3qlejhue0fw0kz3tmfgqdsjzdh"

README.md

@@ -0,0 +1,241 @@
+# 🚀 Element Server Suite (ESS) Community – GitOps Deployment Guide
+
+Dieses Repository enthält die Infrastruktur-as-Code (IaC) für den Matrix-Homeserver (basierend auf der Element Server Suite Community Edition), der per **FluxCD** nach GitOps-Prinzipien verwaltet wird.
+
+## 📑 Inhaltsverzeichnis
+
+1.  [Voraussetzungen & Lokale Tools](https://www.google.com/search?q=%231-voraussetzungen--lokale-tools)
+2.  [Architektur & Logik des Stacks](https://www.google.com/search?q=%232-architektur--logik-des-stacks)
+3.  [Aufbau des Repositories](https://www.google.com/search?q=%233-aufbau-des-repositories)
+4.  [Das Deployment (Aktueller Stand)](https://www.google.com/search?q=%234-das-deployment-aktueller-stand)
+5.  [Nützliche Befehle](https://www.google.com/search?q=%235-n%C3%BCtzliche-befehle)
+6.  [Troubleshooting & Known Issues](https://www.google.com/search?q=%236-troubleshooting--known-issues)
+
+-----
+
+## 1\. Voraussetzungen & Lokale Tools
+
+Um mit diesem Stack zu interagieren (Konfigurationen anzupassen, Secrets zu verschlüsseln, Fehler zu suchen), müssen folgende Tools lokal installiert sein:
+
+### 🛠️ Benötigte CLI-Tools
+
+  * **`kubectl`**: Für die direkte Kommunikation mit dem Kubernetes-Cluster.
+  * **`flux`**: Für das manuelle Anstoßen von GitOps-Synchronisationen.
+  * **`sops`** & **`age`** (oder GPG): Für die Ver- und Entschlüsselung von Secrets direkt im Git-Repo.
+  * **`helm`**: (Optional) Zum Inspizieren von Chart-Values.
+
+### 🍏 macOS (via Homebrew)
+
+```bash
+brew install kubectl fluxcd/tap/flux sops age helm
+```
+
+### 🐧 Linux
+
+```bash
+# kubectl & helm via Paketmanager (apt/dnf) oder curl
+curl -sLS https://fluxcd.io/install.sh | sudo bash
+# SOPS
+wget https://github.com/getsops/sops/releases/download/v3.8.1/sops-v3.8.1.linux.amd64
+sudo mv sops-v3.8.1.linux.amd64 /usr/local/bin/sops && sudo chmod +x /usr/local/bin/sops
+sudo apt install age
+```
+
+### 🪟 Windows (via Winget oder WSL2)
+
+*Empfehlung: Nutze WSL2 (Ubuntu) und folge den Linux-Schritten.* Nativ via Winget:
+
+```powershell
+winget install Kubernetes.kubectl FluxCD.Flux Mozilla.sops age-encryption.age Helm.Helm
+```
+
+### ⚙️ Lokale Konfiguration
+
+1.  **Kubeconfig:** Stelle sicher, dass die Datei `~/.kube/config` mit den Zugangsdaten zu deinem K3s-Cluster gefüllt ist. Test: `kubectl get nodes`.
+2.  **SOPS Key:** Du benötigst den privaten `age`-Key (oder GPG-Key), der in der `.sops.yaml` des Repositories hinterlegt ist, um Secrets bearbeiten zu können.
+
+-----
+
+## 2\. Architektur & Logik des Stacks
+
+Das Setup basiert auf einer modernen, modularen GitOps-Architektur:
+
+### Management-Komponenten
+
+  * **K3s**: Die leichtgewichtige Kubernetes-Distribution, die als Fundament dient.
+  * **FluxCD**: Der GitOps-Controller. Er überwacht dieses Git-Repository. Ändert sich hier eine Datei, wendet Flux die Änderung automatisch im Cluster an.
+  * **SOPS**: Erlaubt es, Passwörter (z.B. SMTP) verschlüsselt in Git zu speichern. Flux entschlüsselt diese "on the fly" im Cluster.
+  * **Traefik**: Der Ingress-Controller (Standard bei K3s). Er leitet Traffic von Port 80/443 an die richtigen internen Pods weiter.
+  * **Cert-Manager**: Spricht mit Let's Encrypt und stellt automatisch gültige TLS-Zertifikate für alle Ingress-Routen aus.
+
+### Matrix Stack (ESS Community v26.4.0)
+
+Die Suite ist ein "Umbrella Chart", das aus mehreren Microservices besteht:
+
+  * **Synapse (`matrix.`):** Das eigentliche Backend (Homeserver) für die Chat-Nachrichten.
+  * **Matrix Authentication Service (MAS) (`account.`):** Der OIDC-basierte Login-Server. Zwingend erforderlich für moderne Matrix-Clients.
+  * **Element Web (`domain.tld`):** Der Web-Client für die Endnutzer.
+  * **Matrix RTC (`mrtc.`):** Die SFU (Selective Forwarding Unit) für Audio-/Video-Calls.
+  * **PostgreSQL:** Die relationale Datenbank für Synapse und MAS.
+
+-----
+
+## 3\. Aufbau des Repositories
+
+Das Repository ist strikt nach "Infrastruktur" und "Applikation" getrennt, um Abhängigkeiten korrekt zu laden.
+
+```text
+gitops/
+├── .sops.yaml                 # Definiert, wie Secrets verschlüsselt werden
+├── clusters/matrix/           # Der Einstiegspunkt für FluxCD
+├── apps/
+│   ├── base/                  
+│   │   ├── infra/             # Core-Dienste (Cert-Manager, Namespaces)
+│   │   └── matrix/            # Die OCI Helm-Repository Definition für ESS
+│   └── production/            # Das eigentliche Matrix-Deployment
+│       ├── kustomization.yaml           # Inhaltsverzeichnis
+│       ├── element-server-suite.yaml    # Das HelmRelease (Bestellung an Flux)
+│       ├── cert-issuer.yaml             # Let's Encrypt Konfiguration
+│       ├── matrix-postgres-auth.yaml    # DB-Passwörter
+│       └── custom-configs/              # Eigene Anpassungen (Themes, Logging)
+│           ├── synapse-values.yaml      # Als ConfigMap
+│           ├── element-values.yaml      # Als ConfigMap
+│           └── mas-secrets.sops.yaml    # Als verschlüsseltes SOPS-Secret
+```
+
+**Abhängigkeits-Logik:** Flux installiert erst `infra-apps` (damit Namespaces und Repositories existieren) und danach `production-apps` (das eigentliche ESS-Chart).
+
+-----
+
+## 4\. Das Deployment (Aktueller Stand)
+
+### Das HelmRepository (OCI)
+
+Element verteilt die Community-Edition modern über die GitHub Container Registry (`ghcr.io`). Klassische HTTP-Helm-Repos werfen hier oft 404-Fehler.
+
+```yaml
+# apps/base/matrix/ess-repo.yaml
+apiVersion: source.toolkit.fluxcd.io/v1
+kind: HelmRepository
+metadata:
+  name: element-ess-oci
+spec:
+  type: oci
+  url: oci://ghcr.io/element-hq/ess-helm
+```
+
+### Das HelmRelease (Das Herzstück)
+
+Das ESS-Chart (`v26.4.0`) hat ein extrem striktes JSON-Schema. Konfigurationen müssen exakt sitzen:
+
+  * `serverName` muss an der Wurzel stehen.
+  * Komponenten werden in `camelCase` geschrieben (`elementWeb`, `synapseAdmin`).
+  * Zertifikate werden durch `certManager: true` automatisch gemanaged. **Keine manuellen TLS-Einträge im Ingress-Block\!**
+
+<!-- end list -->
+
+```yaml
+# apps/production/element-server-suite.yaml (Auszug)
+apiVersion: helm.toolkit.fluxcd.io/v2
+kind: HelmRelease
+metadata:
+  name: matrix-stack
+spec:
+  chart:
+    spec:
+      chart: matrix-stack
+      version: "26.4.0"
+  valuesFrom:
+    - kind: ConfigMap
+      name: ess-synapse-custom
+      valuesKey: values.yaml
+    - kind: Secret
+      name: ess-mas-custom-secrets
+      valuesKey: values.yaml
+  values:
+    serverName: axion1337.chat
+    certManager: true
+    postgres:
+      enabled: true
+    synapse:
+      enabled: true
+      ingress: { host: matrix.axion1337.chat }
+    matrixAuthenticationService:
+      enabled: true
+      ingress: { host: account.axion1337.chat }
+    elementWeb:
+      enabled: true
+      ingress: { host: axion1337.chat }
+    wellKnownDelegation:
+      enabled: false # ! WICHTIG (Siehe Troubleshooting)
+```
+
+-----
+
+## 5\. Nützliche Befehle
+
+### 🔄 Flux / GitOps Sync erzwingen
+
+Wenn man nicht auf den automatischen 10-Minuten-Timer von Flux warten will:
+
+```bash
+flux reconcile kustomization flux-system --with-source
+flux reconcile kustomization production-apps --with-source
+```
+
+### 🔍 Status des Deployments prüfen
+
+```bash
+# Zeigt, ob Flux das Chart akzeptiert und angewendet hat
+flux get helmreleases -A
+
+# Zeigt an, ob die Pods erfolgreich starten
+kubectl get pods -n matrix
+```
+
+### 🔐 Zertifikate (Let's Encrypt) debuggen
+
+```bash
+# Sind die Zertifikate da und gültig?
+kubectl get certificate -n matrix
+
+# Wo hängt der Request? (403 Fehler etc.)
+kubectl get certificaterequest -n matrix
+kubectl get challenges -n matrix
+kubectl describe challenge <name> -n matrix
+```
+
+### 🛡️ Secrets mit SOPS bearbeiten
+
+Um ein Passwort im GitOps-Repo zu ändern, editiert man die verschlüsselte Datei direkt via SOPS (sie wird transparent entschlüsselt und beim Speichern wieder verschlüsselt):
+
+```bash
+sops apps/production/custom-configs/mas-secrets.sops.yaml
+```
+
+-----
+
+## 6\. Troubleshooting & Known Issues
+
+### Issue 1: `HelmChart is not ready: stat ... no such file or directory`
+
+  * **Ursache:** Falscher Versuch, das Chart direkt aus dem GitHub-Repo-Code (als GitRepository) zu lesen. Das Chart erfordert Sub-Charts, die so nicht gerendert werden können.
+  * **Lösung:** Immer das OCI-Repository (`oci://ghcr.io/...`) und den Chartnamen `matrix-stack` verwenden.
+
+### Issue 2: `values don't meet the specifications of the schema(s)`
+
+  * **Ursache:** Ab Version 26.x hat ESS ein sehr rigides JSON-Schema.
+  * **Lösung:** Logs genau lesen.
+      * `tls` darf nicht in den Ingress-Block der Komponenten.
+      * `serverName` muss ins Top-Level, nicht unter `synapse`.
+      * Keine `config:` Blöcke für Core-Komponenten.
+
+### Issue 3: Let's Encrypt Error `403 Order's status is processing` auf der Hauptdomain
+
+  * **Ursache (Die ACME Race Condition):** Wenn `elementWeb` (auf `axion1337.chat`) und `wellKnownDelegation` (ebenfalls auf `axion1337.chat`) gleichzeitig aktiviert sind, fordert `cert-manager` zeitgleich zwei Zertifikate für dieselbe Domain an. Let's Encrypt blockt den zweiten Versuch und das Ingress-Setup hängt sich auf.
+  * **Lösung:** `wellKnownDelegation: enabled: false` im Helm-Chart setzen. Das `.well-known/matrix/server` File muss stattdessen entweder als statische JSON-Datei auf dem Webserver der Hauptdomain hinterlegt oder per Ingress-Route (Traefik Middleware) direkt auf den Synapse-Dienst umgebogen werden.
+
+### Issue 4: Fehlende Zertifikate (`No resources found`)
+
+  * **Ursache:** Manuelle Kustomize-Patches kollidieren mit dem Helm-Chart.
+  * **Lösung:** Manuelle Patches löschen und das native Feature des Charts nutzen: `certManager: true` auf der obersten (Root-)Ebene der `values` setzen. Das Chart erstellt daraufhin die korrekten Ingress-Annotations und Secrets von selbst.

apps/base/infra/cert-manager-repo.yaml

@@ -0,0 +1,8 @@
+apiVersion: source.toolkit.fluxcd.io/v1
+kind: HelmRepository
+metadata:
+  name: jetstack
+  namespace: flux-system
+spec:
+  interval: 1h
+  url: https://charts.jetstack.io

apps/base/infra/cert-manager.yaml

@@ -0,0 +1,22 @@
+apiVersion: helm.toolkit.fluxcd.io/v2
+kind: HelmRelease
+metadata:
+  name: cert-manager
+  namespace: cert-manager
+spec:
+  releaseName: cert-manager
+  interval: 30m
+  chart:
+    spec:
+      chart: cert-manager
+      version: "v1.14.0" # Oder aktuellste stabile Version
+      sourceRef:
+        kind: HelmRepository
+        name: jetstack
+        namespace: flux-system
+  install:
+    createNamespace: true
+    remediation:
+      retries: 3
+  values:
+    installCRDs: true

apps/base/infra/kustomization.yaml

@@ -0,0 +1,8 @@
+apiVersion: kustomize.config.k8s.io/v1beta1
+kind: Kustomization
+resources:
+  - ns-cert-manager.yaml
+  - ns-matrix.yaml
+  - cert-manager-repo.yaml
+  - cert-manager.yaml
+  - ../matrix/ess-repo.yaml

apps/base/infra/ns-cert-manager.yaml

@@ -0,0 +1,4 @@
+apiVersion: v1
+kind: Namespace
+metadata:
+  name: cert-manager

apps/base/infra/ns-matrix.yaml

@@ -0,0 +1,4 @@
+apiVersion: v1
+kind: Namespace
+metadata:
+  name: matrix

apps/base/matrix/ess-operator.yaml

@@ -0,0 +1,17 @@
+apiVersion: helm.toolkit.fluxcd.io/v2
+kind: HelmRelease
+metadata:
+  name: element-operator
+  namespace: matrix
+spec:
+  releaseName: element-operator
+  interval: 30m
+  chart:
+    spec:
+      chart: element-operator
+      sourceRef:
+        kind: HelmRepository
+        name: element-charts
+        namespace: flux-system
+  install:
+    createNamespace: true

apps/base/matrix/ess-repo.yaml

@@ -0,0 +1,9 @@
+apiVersion: source.toolkit.fluxcd.io/v1
+kind: HelmRepository
+metadata:
+  name: element-ess-oci
+  namespace: flux-system
+spec:
+  type: oci
+  url: oci://ghcr.io/element-hq/ess-helm
+  interval: 1h

apps/monitoring/alloy-config.yaml

@@ -0,0 +1,135 @@
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: alloy-config
+  namespace: monitoring
+data:
+  config.alloy: |
+    // Kubernetes pod discovery
+    discovery.kubernetes "k8s_pods" {
+      role = "pod"
+    }
+
+    // Relabel for Prometheus scrape
+    discovery.relabel "prometheus_pods" {
+      targets = discovery.kubernetes.k8s_pods.targets
+      rule {
+        source_labels = ["__meta_kubernetes_pod_annotation_prometheus_io_scrape"]
+        action = "keep"
+        regex = "true"
+      }
+      rule {
+        source_labels = ["__meta_kubernetes_pod_annotation_prometheus_io_path"]
+        action = "replace"
+        target_label = "__metrics_path__"
+        regex = "(.+)"
+      }
+      rule {
+        source_labels = ["__address__", "__meta_kubernetes_pod_annotation_prometheus_io_port"]
+        action = "replace"
+        regex = "([^:]+)(?::\\d+)?;(\\d+)"
+        replacement = "$1:$2"
+        target_label = "__address__"
+      }
+      rule {
+        source_labels = ["__meta_kubernetes_namespace"]
+        action = "replace"
+        target_label = "namespace"
+      }
+      rule {
+        source_labels = ["__meta_kubernetes_pod_name"]
+        action = "replace"
+        target_label = "pod"
+      }
+    }
+
+    // Scrape Flux controllers (flux-system namespace, port 8080)
+    discovery.kubernetes "flux_pods" {
+      role = "pod"
+      namespaces {
+        names = ["flux-system"]
+      }
+    }
+
+    discovery.relabel "flux_scrape" {
+      targets = discovery.kubernetes.flux_pods.targets
+      rule {
+        source_labels = ["__meta_kubernetes_pod_container_port_number"]
+        action = "keep"
+        regex = "8080"
+      }
+      rule {
+        source_labels = ["__meta_kubernetes_namespace"]
+        action = "replace"
+        target_label = "namespace"
+      }
+      rule {
+        source_labels = ["__meta_kubernetes_pod_name"]
+        action = "replace"
+        target_label = "pod"
+      }
+    }
+
+    // Scrape kube-state-metrics
+    prometheus.scrape "kube_state_metrics" {
+      targets = [{
+        __address__ = "kube-state-metrics.monitoring.svc.cluster.local:8080",
+      }]
+      forward_to = [prometheus.remote_write.selendis.receiver]
+      scrape_interval = "30s"
+      scrape_timeout = "10s"
+    }
+
+    // Scrape Flux controllers
+    prometheus.scrape "flux" {
+      targets = discovery.relabel.flux_scrape.output
+      forward_to = [prometheus.remote_write.selendis.receiver]
+      scrape_interval = "30s"
+      scrape_timeout = "10s"
+      job_name = "flux"
+    }
+
+    // Scrape node-exporter DaemonSet
+    prometheus.scrape "node_exporter" {
+      targets = [{
+        __address__ = "prometheus-node-exporter.monitoring.svc.cluster.local:9100",
+      }]
+      forward_to = [prometheus.remote_write.selendis.receiver]
+      scrape_interval = "30s"
+      scrape_timeout = "10s"
+    }
+
+    // Scrape Synapse metrics
+    prometheus.scrape "synapse" {
+      targets = [{
+        __address__ = "matrix-stack-synapse-main.matrix.svc.cluster.local:9000",
+      }]
+      forward_to = [prometheus.remote_write.selendis.receiver]
+      scrape_interval = "30s"
+      scrape_timeout = "10s"
+    }
+
+    // Kubernetes pod logs to Loki
+    loki.source.kubernetes "k8s_logs" {
+      targets = discovery.kubernetes.k8s_pods.targets
+      forward_to = [loki.write.selendis.receiver]
+    }
+
+    // Remote write to Selendis Prometheus
+    prometheus.remote_write "selendis" {
+      endpoint {
+        url = "http://10.0.0.3:9090/api/v1/write"
+        write_relabel_config {
+          source_labels = ["__name__"]
+          regex = "go_.*|process_.*"
+          action = "drop"
+        }
+      }
+    }
+
+    // Remote write logs to Selendis Loki
+    loki.write "selendis" {
+      endpoint {
+        url = "http://10.0.0.3:3100/loki/api/v1/push"
+      }
+    }

apps/monitoring/alloy.yaml

@@ -0,0 +1,33 @@
+apiVersion: helm.toolkit.fluxcd.io/v2
+kind: HelmRelease
+metadata:
+  name: alloy
+  namespace: monitoring
+spec:
+  interval: 1h
+  chart:
+    spec:
+      chart: alloy
+      version: "0.x"
+      sourceRef:
+        kind: HelmRepository
+        name: grafana
+        namespace: flux-system
+  values:
+    alloy:
+      configMap:
+        name: alloy-config
+    replicaCount: 1
+    serviceAccount:
+      create: true
+      name: alloy
+    rbac:
+      create: true
+    podAnnotations:
+      prometheus.io/scrape: "false"
+    resources:
+      limits:
+        memory: 512Mi
+      requests:
+        cpu: 100m
+        memory: 256Mi

apps/monitoring/helm-repos.yaml

@@ -0,0 +1,18 @@
+apiVersion: source.toolkit.fluxcd.io/v1
+kind: HelmRepository
+metadata:
+  name: prometheus-community
+  namespace: flux-system
+spec:
+  interval: 1h
+  url: https://prometheus-community.github.io/helm-charts
+
+---
+apiVersion: source.toolkit.fluxcd.io/v1
+kind: HelmRepository
+metadata:
+  name: grafana
+  namespace: flux-system
+spec:
+  interval: 1h
+  url: https://grafana.github.io/helm-charts

apps/monitoring/kube-state-metrics.yaml

@@ -0,0 +1,22 @@
+apiVersion: helm.toolkit.fluxcd.io/v2
+kind: HelmRelease
+metadata:
+  name: kube-state-metrics
+  namespace: monitoring
+spec:
+  interval: 1h
+  chart:
+    spec:
+      chart: kube-state-metrics
+      version: "5.x"
+      sourceRef:
+        kind: HelmRepository
+        name: prometheus-community
+        namespace: flux-system
+  values:
+    replicas: 1
+    service:
+      port: 8080
+    prometheus:
+      monitor:
+        enabled: false

apps/monitoring/kustomization.yaml

@@ -0,0 +1,9 @@
+apiVersion: kustomize.config.k8s.io/v1beta1
+kind: Kustomization
+resources:
+  - namespace.yaml
+  - helm-repos.yaml
+  - kube-state-metrics.yaml
+  - node-exporter.yaml
+  - alloy-config.yaml
+  - alloy.yaml

apps/monitoring/namespace.yaml

@@ -0,0 +1,4 @@
+apiVersion: v1
+kind: Namespace
+metadata:
+  name: monitoring

apps/monitoring/node-exporter.yaml

@@ -0,0 +1,29 @@
+apiVersion: helm.toolkit.fluxcd.io/v2
+kind: HelmRelease
+metadata:
+  name: prometheus-node-exporter
+  namespace: monitoring
+spec:
+  interval: 1h
+  chart:
+    spec:
+      chart: prometheus-node-exporter
+      version: "4.x"
+      sourceRef:
+        kind: HelmRepository
+        name: prometheus-community
+        namespace: flux-system
+  values:
+    hostNetwork: true
+    hostPID: true
+    hostRootFsMount:
+      enabled: true
+    service:
+      port: 9100
+      targetPort: 9100
+    prometheus:
+      monitor:
+        enabled: false
+    tolerations:
+      - effect: NoSchedule
+        operator: Exists

apps/production/apex-ingress.yaml

@@ -0,0 +1,44 @@
+apiVersion: cert-manager.io/v1
+kind: Certificate
+metadata:
+  name: axion-apex-tls
+  namespace: matrix
+spec:
+  secretName: axion-apex-tls
+  issuerRef:
+    name: letsencrypt-prod
+    kind: ClusterIssuer
+  dnsNames:
+    - axion1337.chat
+---
+apiVersion: traefik.io/v1alpha1
+kind: IngressRoute
+metadata:
+  name: axion-apex
+  namespace: matrix
+spec:
+  entryPoints: [websecure]
+  tls:
+    secretName: axion-apex-tls
+  routes:
+    # Höchste Priorität: /.well-known/matrix/* -> wellKnownDelegation-Service
+    - match: Host(`axion1337.chat`) && PathPrefix(`/.well-known/matrix`)
+      kind: Rule
+      priority: 100
+      services:
+        - name: matrix-stack-well-known
+          port: 8010
+    # Element Desktop Setup Skripte
+    - match: Host(`axion1337.chat`) && PathPrefix(`/docs/setup`)
+      kind: Rule
+      priority: 50
+      services:
+        - name: element-web-docs
+          port: 80
+    # Niedrigere Priorität: alles andere -> Element Web
+    - match: Host(`axion1337.chat`)
+      kind: Rule
+      priority: 10
+      services:
+        - name: matrix-stack-element-web
+          port: 80

apps/production/cert-issuer.yaml

@@ -0,0 +1,14 @@
+apiVersion: cert-manager.io/v1
+kind: ClusterIssuer
+metadata:
+  name: letsencrypt-prod
+spec:
+  acme:
+    server: https://acme-v02.api.letsencrypt.org/directory
+    email: gamemaster@axion1337.de
+    privateKeySecretRef:
+      name: letsencrypt-prod-account-key
+    solvers:
+    - http01:
+        ingress:
+          class: traefik # K3s nutzt standardmäßig Traefik

apps/production/coturn-secret.yaml

@@ -0,0 +1,22 @@
+apiVersion: v1
+kind: Secret
+metadata:
+    name: coturn-secret
+    namespace: matrix
+stringData:
+    TURN_SECRET: ENC[AES256_GCM,data:SILIqMB+fmAMFITAL7lG1hOgICec6BJf1mOcK0gdmnCHWYqRuJv7jgjfGylG25xzQKi+zE7Qual9PnkZG2KiOA==,iv:+GZqLGusE4Q0x2jEEtFxj06rryyQmQhXdkTy4eE8ZHw=,tag:OpSZkinPTAi1ZKWyo8OX3A==,type:str]
+sops:
+    age:
+        - recipient: age14l0hwfqylwpemz5y2ghh2yxk0phszlnj3qlejhue0fw0kz3tmfgqdsjzdh
+          enc: |
+            -----BEGIN AGE ENCRYPTED FILE-----
+            YWdlLWVuY3J5cHRpb24ub3JnL3YxCi0+IFgyNTUxOSAyRk1mK3NWc1l4T0JCOFpF
+            S0RuQ3ViZmo3QTNVL2JvZ0hzMy91R2l0TEhzCk01a1VGdk1sdVg4aWswTzRibXI4
+            ZlJtNFF5MjBONEZOaWVpeU5taHl2bkEKLS0tIGxpUHY3NUFLWFBaWm1QSlZiVFkx
+            MEJleHFnd3oyT3VPL2dsYkpMUlRkOWMKcKUIgsQ/ff49pGGXMnYwJmwqPVC7woAR
+            IEzvhcNX97xx746SnrxZe5t2YadsYMkYIl0nvqBPJhSlvqMNafpQbQ==
+            -----END AGE ENCRYPTED FILE-----
+    lastmodified: "2026-04-29T21:06:21Z"
+    mac: ENC[AES256_GCM,data:UhyR5m1HYWrZHwNLW5sg2PxbpaydWbP5cekghGlzSpQg7CYEcvZw3tJ/qB8zA19xZSM7tdSHOXdD+QytRq6qW59M1unqMaumA43B6JxQg1C1NdXAW0mkSc2WiNchvgpVii9P/TVlzSSIRwC3YGCQUsfa3SSfNzI4Z6fMuBnhYLE=,iv:4HYxbrYSRJLe1KcQ6q8bpee8/Lx1m3pPmisb/L2Mu64=,tag:l7n3u+Pg6533OzwtNUZvNw==,type:str]
+    encrypted_regex: ^(data|stringData)$
+    version: 3.12.2

apps/production/coturn.yaml

@@ -0,0 +1,162 @@
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: coturn-config
+  namespace: matrix
+data:
+  turnserver.conf: |
+    # TURN Server configuration
+    realm=axion1337.chat
+
+    # Listen ports
+    listening-port=3478
+    listening-ip=0.0.0.0
+    alt-listening-port=5349
+    alt-listening-ip=0.0.0.0
+
+    # External IPs (for clients behind NAT)
+    relay-ip=49.13.132.245
+    external-ip=49.13.132.245
+
+    # Relay port range
+    min-bps=0
+    bps-capacity=0
+
+    # Authentication
+    use-auth-secret
+    static-auth-secret=$TURN_SECRET
+
+    # HTTPS/TLS
+    cert=/etc/coturn/tls/tls.crt
+    pkey=/etc/coturn/tls/tls.key
+
+    # Performance tuning
+    max-bps=0
+    bps-capacity=0
+    log-file=stdout
+
+    # Logging
+    verbose
+---
+apiVersion: v1
+kind: Service
+metadata:
+  name: coturn
+  namespace: matrix
+spec:
+  type: ClusterIP
+  ports:
+    - name: stun-udp
+      port: 3478
+      protocol: UDP
+    - name: stun-tcp
+      port: 3478
+      protocol: TCP
+    - name: turns-tcp
+      port: 5349
+      protocol: TCP
+  selector:
+    app: coturn
+---
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: coturn
+  namespace: matrix
+spec:
+  replicas: 1
+  selector:
+    matchLabels:
+      app: coturn
+  template:
+    metadata:
+      labels:
+        app: coturn
+      annotations:
+        prometheus.io/scrape: "false"
+    spec:
+      hostNetwork: true
+      dnsPolicy: ClusterFirstWithHostNet
+      initContainers:
+      - name: init-config
+        image: busybox:1.28
+        command:
+        - sh
+        - -c
+        - |
+          TURN_SECRET=$(cat /etc/coturn-secret/TURN_SECRET)
+          sed "s|\$TURN_SECRET|$TURN_SECRET|g" /etc/coturn-template/turnserver.conf > /etc/coturn/turnserver.conf
+          chmod 644 /etc/coturn/turnserver.conf
+        resources:
+          limits:
+            cpu: 100m
+            memory: 64Mi
+          requests:
+            cpu: 50m
+            memory: 32Mi
+        volumeMounts:
+        - name: config-template
+          mountPath: /etc/coturn-template
+        - name: config
+          mountPath: /etc/coturn
+        - name: secret
+          mountPath: /etc/coturn-secret
+          readOnly: true
+      containers:
+      - name: coturn
+        image: coturn/coturn:latest
+        imagePullPolicy: IfNotPresent
+        ports:
+        - name: stun-udp
+          containerPort: 3478
+          protocol: UDP
+        - name: stun-tcp
+          containerPort: 3478
+          protocol: TCP
+        - name: turns-tcp
+          containerPort: 5349
+          protocol: TCP
+        volumeMounts:
+        - name: config
+          mountPath: /etc/coturn
+        - name: tls
+          mountPath: /etc/coturn/tls
+          readOnly: true
+        resources:
+          limits:
+            cpu: 500m
+            memory: 256Mi
+          requests:
+            cpu: 100m
+            memory: 128Mi
+        livenessProbe:
+          exec:
+            command:
+            - /bin/sh
+            - -c
+            - "netstat -uln | grep 3478 || exit 1"
+          initialDelaySeconds: 30
+          periodSeconds: 10
+      volumes:
+      - name: config
+        emptyDir: {}
+      - name: config-template
+        configMap:
+          name: coturn-config
+      - name: secret
+        secret:
+          secretName: coturn-secret
+          defaultMode: 0400
+      - name: tls
+        secret:
+          secretName: turn-axion1337-chat-tls
+      affinity:
+        nodeAffinity:
+          preferredDuringSchedulingIgnoredDuringExecution:
+          - weight: 100
+            preference:
+              matchExpressions:
+              - key: kubernetes.io/hostname
+                operator: In
+                values:
+                - matrix

apps/production/custom-configs/element-values.yaml

@@ -0,0 +1,222 @@
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: ess-element-custom
+  namespace: matrix
+data:
+  values.yaml: |
+    elementWeb:
+      additional:
+        config.json: |
+          {
+            "configUrl": "https://axion1337.chat/config.json",
+            "brand": "aXion1337.Chat",
+            "default_theme": "aXion1337 Dark",
+            "show_labs_settings": true,
+            "features": {
+              "feature_qr_code_login": true
+            },
+            "setting_defaults": {
+              "custom_themes": [
+                {
+                  "name": "aXion1337 Dark",
+                  "is_dark": true,
+                  "colors": {
+                    "accent-color": "#ffaf0f",
+                    "primary-color": "#ffaf0f",
+                    "secondary-color": "#ffaf0f"
+                  }
+                },
+                {
+                  "name": "Deep Purple",
+                  "is_dark": true,
+                  "colors": {
+                    "accent-color": "#6503b3",
+                    "primary-color": "#368bd6",
+                    "warning-color": "#b30356",
+                    "sidebar-color": "#15171B",
+                    "roomlist-background-color": "#22262E",
+                    "roomlist-text-color": "#A1B2D1",
+                    "roomlist-text-secondary-color": "#EDF3FF",
+                    "roomlist-highlights-color": "#343A46",
+                    "roomlist-separator-color": "#a1b2d1",
+                    "timeline-background-color": "#181b21",
+                    "timeline-text-color": "#EDF3FF",
+                    "timeline-text-secondary-color": "#A1B2D1",
+                    "timeline-highlights-color": "#22262E"
+                  }
+                },
+                {
+                  "name": "Discord Dark",
+                  "is_dark": true,
+                  "colors": {
+                    "accent-color": "#747ff4",
+                    "accent": "#747ff4",
+                    "primary-color": "#00aff4",
+                    "warning-color": "#faa81ad9",
+                    "alert": "#faa81ad9",
+                    "sidebar-color": "#202225",
+                    "roomlist-background-color": "#2f3136",
+                    "roomlist-text-color": "#dcddde",
+                    "roomlist-text-secondary-color": "#8e9297",
+                    "roomlist-highlights-color": "#4f545c52",
+                    "roomlist-separator-color": "#40444b",
+                    "timeline-background-color": "#36393f",
+                    "timeline-text-color": "#dcddde",
+                    "secondary-content": "#dcddde",
+                    "tertiary-content": "#dcddde",
+                    "timeline-text-secondary-color": "#b9bbbe",
+                    "timeline-highlights-color": "#04040512",
+                    "reaction-row-button-selected-bg-color": "#4752c4",
+                    "menu-selected-color": "#4752c4",
+                    "focus-bg-color": "#4752c4",
+                    "room-highlight-color": "#4752c4",
+                    "other-user-pill-bg-color": "#4752c4",
+                    "togglesw-off-color": "#72767d"
+                  },
+                  "compound": {
+                    "--cpd-color-theme-bg": "#0019ff",
+                    "--cpd-color-bg-canvas-default": "#2f3136",
+                    "--cpd-color-bg-subtle-secondary": "#2f3136",
+                    "--cpd-color-bg-subtle-primary": "#4f545c52",
+                    "--cpd-color-bg-action-primary-rest": "#dcddde",
+                    "--cpd-color-bg-action-secondary-rest": "#2f3136",
+                    "--cpd-color-bg-critical-primary": "#fd3f3c",
+                    "--cpd-color-bg-critical-subtle": "#745862",
+                    "--cpd-color-bg-critical-hovered": "#fd3f3c",
+                    "--cpd-color-bg-accent-rest": "#4cb387",
+                    "--cpd-color-text-primary": "#dcddde",
+                    "--cpd-color-text-secondary": "#b9bbbe",
+                    "--cpd-color-text-action-accent": "#b9bbbe",
+                    "--cpd-color-text-critical-primary": "#fd3f3c",
+                    "--cpd-color-text-success-primary": "#4cb387",
+                    "--cpd-color-icon-primary": "#dcddde",
+                    "--cpd-color-icon-secondary": "#dcddde",
+                    "--cpd-color-icon-tertiary": "#a7a0a7",
+                    "--cpd-color-icon-accent-tertiary": "#4cb387",
+                    "--cpd-color-border-interactive-primary": "#5d6064",
+                    "--cpd-color-border-interactive-secondary": "#5d6064",
+                    "--cpd-color-border-critical-primary": "#fd3f3c",
+                    "--cpd-color-border-success-subtle": "#4cb387"
+                  }
+                },
+                {
+                  "name": "Electric Blue",
+                  "is_dark": false,
+                  "colors": {
+                    "accent-color": "#3596fc",
+                    "primary-color": "#368bd6",
+                    "warning-color": "#ff4b55",
+                    "sidebar-color": "#27303a",
+                    "roomlist-background-color": "#f3f8fd",
+                    "roomlist-text-color": "#2e2f32",
+                    "roomlist-text-secondary-color": "#61708b",
+                    "roomlist-highlights-color": "#ffffff",
+                    "roomlist-separator-color": "#e3e8f0",
+                    "timeline-background-color": "#ffffff",
+                    "timeline-text-color": "#2e2f32",
+                    "timeline-text-secondary-color": "#61708b",
+                    "timeline-highlights-color": "#f3f8fd",
+                    "username-colors": ["#ff0000", "#ff7f00", "#ffff00", "#00ff00", "#0000ff", "#4b0082", "#9400d3", "#ff1493"],
+                    "avatar-background-colors": ["#cc0000", "#cc6600", "#cccc00", "#00cc00", "#0000cc", "#3b0066", "#7a00b3", "#cc1077"]
+                  },
+                  "compound": {
+                    "--cpd-color-icon-accent-tertiary": "var(--cpd-color-blue-800)",
+                    "--cpd-color-text-action-accent": "var(--cpd-color-blue-900)"
+                  }
+                },
+                {
+                  "name": "Everforest dark hard",
+                  "is_dark": true,
+                  "colors": {
+                    "accent-color": "#a7c080",
+                    "primary-color": "#a7c080",
+                    "warning-color": "#e67e80",
+                    "sidebar-color": "#323d43",
+                    "roomlist-background-color": "#2f383e",
+                    "roomlist-text-color": "#d3c6aa",
+                    "roomlist-text-secondary-color": "#d3c6aa",
+                    "roomlist-highlights-color": "#4b565c",
+                    "roomlist-separator-color": "#4b565c",
+                    "timeline-background-color": "#2b3339",
+                    "timeline-text-color": "#d3c6aa",
+                    "secondary-content": "#d3c6aa",
+                    "tertiary-content": "#d3c6aa",
+                    "timeline-text-secondary-color": "#a7c080",
+                    "timeline-highlights-color": "#4b565c",
+                    "reaction-row-button-selected-bg-color": "#4b565c"
+                  }
+                },
+                {
+                  "name": "Gruvbox Dark",
+                  "is_dark": true,
+                  "colors": {
+                    "accent-color": "#bd93f9",
+                    "primary-color": "#fe8019",
+                    "warning-color": "#fb4934",
+                    "sidebar-color": "#282828",
+                    "roomlist-background-color": "#1d2021",
+                    "roomlist-text-color": "#a89984",
+                    "roomlist-text-secondary-color": "#00ff00",
+                    "roomlist-highlights-color": "#00000030",
+                    "roomlist-separator-color": "#4d4d4d90",
+                    "timeline-background-color": "#282828",
+                    "timeline-text-color": "#ebdbb2",
+                    "secondary-content": "#928374",
+                    "tertiary-content": "#928374",
+                    "quinary-content": "#504945",
+                    "timeline-text-secondary-color": "#a89984",
+                    "timeline-highlights-color": "#00000030",
+                    "reaction-row-button-selected-bg-color": "#689d6a",
+                    "menu-selected-color": "#504945",
+                    "icon-button-color": "#928374",
+                    "accent": "#689d6a",
+                    "alert": "#cc241d",
+                    "username-colors": [
+                      "#cc241d",
+                      "#98971a",
+                      "#d79921",
+                      "#458588",
+                      "#b16286",
+                      "#689d6a",
+                      "#a89984",
+                      "#d65d0e"
+                    ],
+                    "avatar-background-colors": ["#458588", "#b16286", "#689d6a"]
+                  }
+                },
+                {
+                  "name": "Wal",
+                  "is_dark": true,
+                  "colors": {
+                    "accent-color": "#888888",
+                    "accent": "#888888",
+                    "primary-color": "#4a90e2",
+                    "warning-color": "#e74c3c",
+                    "alert": "#e74c3c",
+                    "sidebar-color": "#2b2d31",
+                    "roomlist-background-color": "#e74c3c",
+                    "roomlist-text-color": "#888888",
+                    "roomlist-text-secondary-color": "#c0c0c0",
+                    "roomlist-highlights-color": "#b8b8b8",
+                    "roomlist-separator-color": "#5e81ac",
+                    "timeline-background-color": "#2b2d31",
+                    "timeline-text-color": "#888888",
+                    "timeline-text-secondary-color": "#888888",
+                    "timeline-highlights-color": "#e74c3c",
+                    "username-colors": ["#22222a", "#e74c3c", "#b8bb26", "#fabd2f", "#4a90e2", "#b16286", "#8ec07c", "#ebdbb2"],
+                    "avatar-background-colors": ["#fabd2f", "#4a90e2", "#b16286"],
+                    "reaction-row-button-selected-bg-color": "#4a90e2",
+                    "menu-selected-color": "#4a90e2",
+                    "focus-bg-color": "#4a90e2",
+                    "room-highlight-color": "#4a90e2",
+                    "other-user-pill-bg-color": "#4a90e2",
+                    "icon-button-color": "#8ec07c",
+                    "togglesw-off-color": "#4a90e2",
+                    "secondary-content": "#888888",
+                    "tertiary-content": "#888888"
+                  }
+                }
+              ]
+            }
+          }

apps/production/custom-configs/mas-secret.yaml

@@ -0,0 +1,22 @@
+apiVersion: v1
+kind: Secret
+metadata:
+    name: ess-mas-values-secret
+    namespace: matrix
+stringData:
+    values.yaml: ENC[AES256_GCM,data:tPLcPvoTa2Qs49JSDW6CqiYMIrjsoKrExCl+hOm5R3/o+O9Lf4UqyMC4QY6T303m7GMU3tIDGX4js8NS7Fdcs9YOKoInUKlYqCYzNio+BRsl1DGtzEtcUWhXZQC58RHbI8jiLhXsI1x2vSYsMj5MkymVe9Kmjw91vxEivzn8dC2zae4rFGk/LyLoI5BHzSCT6csUGtGZe01rN/DsGpHxkYNbzinBK3uFM43IgcjCrkBK8jzsxUYA4JWvzBJ1tB5TyyTgZBBe2Baxj7vHf9SysGwbRl4TBzY5at8cPKKnmh7qaHQO3FHCCqfHi1ymt1vNRtPPGRGAKWqC8AroXTPUUe4oSQ7wakhuQwPAhQJn0FHjIJNbp2J7M9K3nWnf0eugDPcp1pQ7Iv0tUQ/2hd5Q8Xmiv7qCCBuhOGnAokUwkRnZu124PEhPwDa/PSA6bB/5dCwj8rzZOyEXJsz12cRtSPK8Kqff+bp2MSFEA8iETm40k/BxybyC2odWEhkPDlRl+YDe8rJxkGGLwP5PEgiQp5RK4ZftQ6Cgc5loUHDAar10tMsqg++iQeyeb/o=,iv:PSo85CoDdWajU3j4vHsaNCHI6UbMbII01nskXNyotVU=,tag:OBVkKsBnCv9bloORukDgcQ==,type:str]
+sops:
+    age:
+        - recipient: age14l0hwfqylwpemz5y2ghh2yxk0phszlnj3qlejhue0fw0kz3tmfgqdsjzdh
+          enc: |
+            -----BEGIN AGE ENCRYPTED FILE-----
+            YWdlLWVuY3J5cHRpb24ub3JnL3YxCi0+IFgyNTUxOSBWOVd0enFxNE85WnN1eTRD
+            MjdVSE90NUd6MWFBbCtzZFRTK0NQYllUTGdVCk9aWGNGLzNvLzU3S09la2RiY1hv
+            bXdNZjFxaVM5aUF3MTA1bWx4WU1TR0EKLS0tIFp6RmdCVlE5Zk53RjF3MnZveHo4
+            eUpzQTBCRjM0a2FmZzNkdmFKWUVPODQKqpA3drI6JV67Y3P/l8Ql5xwtohVi9D3P
+            6iAcFoqrVZMSKkkiHDvAcdUexIO/BKddjC5N608MLUz7tcxyWfMqeg==
+            -----END AGE ENCRYPTED FILE-----
+    lastmodified: "2026-04-23T13:17:31Z"
+    mac: ENC[AES256_GCM,data:V4l8oScpWwC95gg9UQpaV0oKn292Y6WoRZdWlqF3I8BWCGV4LVvLE7KxC9lqHdt/Mcgb6yuaDSv3ZMERl81QOMSMcPVfk/F0LoabP/dFiz1ogxOezHOfJJ2mTu+4yAOkK73RQY68ui5UGAV5FFu3tecE0AAouSt0YrOTBALtLpY=,iv:WBFy/v6gRBil30Oqdew3JW5XVz5wmaO0Uj7J+MfSrss=,tag:CvTEdnbs4dJ0qlnefvXIag==,type:str]
+    encrypted_regex: ^(data|stringData)$
+    version: 3.12.2

apps/production/custom-configs/synapse-values.yaml

@@ -0,0 +1,69 @@
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: ess-synapse-custom
+  namespace: matrix
+data:
+  values.yaml: |
+    synapse:
+      logging:
+        rootLevel: INFO
+        levelOverrides:
+          synapse.media.url_previewer: DEBUG
+      additional:
+        url-previews:
+          config: |
+            url_preview_enabled: true
+            url_preview_ip_range_blacklist:
+            - '127.0.0.0/8'
+            - '10.0.0.0/8'
+            - '172.16.0.0/12'
+            - '192.168.0.0/16'
+            - '::1/128'
+            - 'fe80::/10'
+            - 'fc00::/7'
+            max_spider_size: 10M
+        retention:
+          config: |
+            retention:
+              enabled: true
+              default_policy:
+                min_lifetime: 1d
+                max_lifetime: 1y
+              allowed_lifetime_min: 1d
+              allowed_lifetime_max: 2y
+              purge_jobs:
+                - longest_max_lifetime: 3d
+                  interval: 12h
+                - shortest_max_lifetime: 3d
+                  longest_max_lifetime: 1w
+                  interval: 1d
+                - shortest_max_lifetime: 1w
+                  interval: 2d
+
+            media_retention:
+              local_media_lifetime: 365d
+              remote_media_lifetime: 90d
+
+            redaction_retention_period: 7d
+            forgotten_room_retention_period: 28d
+            user_ips_max_age: 90d
+        auto_join:
+          config: |
+            auto_join_rooms:
+              - "!NkFTshKWJMgdTqTbTh:axion1337.chat"
+            auto_join_rooms_for_guests: false
+        room_publish:
+          config: |
+            room_list_publication_rules:
+              - user_id: "*"
+                action: allow
+        turn:
+          config: |
+            turn_uris:
+              - "turn:turn.axion1337.chat?transport=udp"
+              - "turn:turn.axion1337.chat?transport=tcp"
+              - "turns:turn.axion1337.chat?transport=tcp"
+            turn_shared_secret: "cab3c8408363515d9b4cdc3384a1f76ca17a973242fdfdc72b67ac4d86158527"
+            turn_user_lifetime: 86400000
+            turn_allow_guests: false

apps/production/element-server-suite.yaml

@@ -0,0 +1,76 @@
+apiVersion: helm.toolkit.fluxcd.io/v2
+kind: HelmRelease
+metadata:
+  name: matrix-stack
+  namespace: matrix
+spec:
+  interval: 1h
+  chart:
+    spec:
+      chart: matrix-stack
+      version: "26.4.0"
+      sourceRef:
+        kind: HelmRepository
+        name: element-ess-oci
+        namespace: flux-system
+
+  # NEU: Hier zieht Flux deine Puzzleteile zusammen
+  valuesFrom:
+    - kind: ConfigMap
+      name: ess-synapse-custom
+      valuesKey: values.yaml
+    - kind: ConfigMap
+      name: ess-element-custom
+      valuesKey: values.yaml
+    - kind: Secret
+      name: ess-mas-values-secret
+      valuesKey: values.yaml
+      
+  values:
+    # Top-Level: serverName – das ist dein Matrix-Homeserver-Name
+    serverName: axion1337.chat
+
+    # Cert-Manager für automatische Zertifikatsgenerierung
+    certManager:
+      clusterIssuer: letsencrypt-prod
+
+    # Interner Postgres an (default ist eh true, hier nur zur Klarheit)
+    postgres:
+      enabled: true
+
+    # Synapse – API auf matrix.axion1337.chat
+    synapse:
+      enabled: true
+      ingress:
+        host: matrix.axion1337.chat
+
+    # Matrix Authentication Service – braucht eine Subdomain
+    matrixAuthenticationService:
+      enabled: true
+      ingress:
+        host: account.axion1337.chat
+
+    # Matrix RTC (Element Call) – braucht auch eine Subdomain
+    matrixRTC:
+      enabled: true
+      ingress:
+        host: mrtc.axion1337.chat
+
+    # Element Web
+    elementWeb:
+      enabled: true
+      ingress:
+        host: axion1337.chat
+
+    # Element Admin
+    elementAdmin:
+      enabled: true
+      ingress:
+        host: admin.axion1337.chat
+
+    # Well-Known auf der Apex-Domain (axion1337.chat/.well-known/matrix/*)
+    # Aktiviert – notwendig für MatrixRTC-Discovery
+    wellKnownDelegation:
+      enabled: true
+      ingress:
+        className: "none"  # Deaktiviert den Chart-Ingress, wir erstellen einen eigenen

apps/production/element-web-docs-configmap.yaml

@@ -0,0 +1,402 @@
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: ess-element-web-docs
+  namespace: matrix
+data:
+  # HTML Index Page
+  "index.html": |
+    <!DOCTYPE html>
+    <html lang="de">
+    <head>
+      <meta charset="UTF-8">
+      <meta name="viewport" content="width=device-width, initial-scale=1.0">
+      <title>Element Desktop Setup - aXion1337.Chat</title>
+      <style>
+        * { margin: 0; padding: 0; box-sizing: border-box; }
+        body {
+          font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", sans-serif;
+          background: linear-gradient(135deg, #667eea 0%, #764ba2 100%);
+          min-height: 100vh;
+          padding: 40px 20px;
+        }
+        .container {
+          max-width: 800px;
+          margin: 0 auto;
+          background: white;
+          border-radius: 12px;
+          box-shadow: 0 20px 60px rgba(0,0,0,0.3);
+          padding: 40px;
+        }
+        h1 {
+          color: #333;
+          margin-bottom: 10px;
+          font-size: 2.5em;
+        }
+        .subtitle {
+          color: #666;
+          margin-bottom: 40px;
+          font-size: 1.1em;
+        }
+        .section {
+          margin-bottom: 40px;
+        }
+        .section h2 {
+          color: #667eea;
+          font-size: 1.5em;
+          margin-bottom: 20px;
+          border-bottom: 3px solid #667eea;
+          padding-bottom: 10px;
+        }
+        .download-grid {
+          display: grid;
+          grid-template-columns: repeat(auto-fit, minmax(200px, 1fr));
+          gap: 20px;
+          margin-bottom: 30px;
+        }
+        .download-card {
+          background: #f8f9fa;
+          border: 2px solid #e9ecef;
+          border-radius: 8px;
+          padding: 20px;
+          text-align: center;
+          transition: all 0.3s ease;
+          text-decoration: none;
+          color: #333;
+        }
+        .download-card:hover {
+          border-color: #667eea;
+          background: #f0f3ff;
+          transform: translateY(-5px);
+          box-shadow: 0 10px 30px rgba(102, 126, 234, 0.2);
+        }
+        .download-card .icon {
+          font-size: 2.5em;
+          margin-bottom: 10px;
+        }
+        .download-card .name {
+          font-weight: 600;
+          font-size: 1.1em;
+          margin-bottom: 5px;
+        }
+        .download-card .desc {
+          font-size: 0.9em;
+          color: #666;
+        }
+        .themes {
+          background: #f8f9fa;
+          border-left: 4px solid #667eea;
+          padding: 20px;
+          border-radius: 4px;
+          margin-bottom: 20px;
+        }
+        .themes h3 {
+          color: #333;
+          margin-bottom: 15px;
+        }
+        .theme-list {
+          display: grid;
+          grid-template-columns: repeat(auto-fit, minmax(150px, 1fr));
+          gap: 10px;
+        }
+        .theme-item {
+          background: white;
+          padding: 10px;
+          border-radius: 4px;
+          text-align: center;
+          color: #667eea;
+          font-weight: 500;
+          border: 1px solid #667eea;
+        }
+        .instructions {
+          background: #e7f3ff;
+          border-left: 4px solid #0066cc;
+          padding: 15px;
+          border-radius: 4px;
+          margin: 15px 0;
+          line-height: 1.6;
+        }
+        .instructions code {
+          background: #f0f0f0;
+          padding: 2px 6px;
+          border-radius: 3px;
+          font-family: monospace;
+        }
+        .support {
+          text-align: center;
+          color: #666;
+          margin-top: 40px;
+          padding-top: 20px;
+          border-top: 1px solid #e9ecef;
+        }
+        .support a {
+          color: #667eea;
+          text-decoration: none;
+          font-weight: 500;
+        }
+        .support a:hover {
+          text-decoration: underline;
+        }
+      </style>
+    </head>
+    <body>
+      <div class="container">
+        <h1>🎨 Element Desktop Setup</h1>
+        <p class="subtitle">Automatische Konfiguration mit Custom Themes für aXion1337.Chat</p>
+
+        <div class="section">
+          <h2>📥 Download Setup-Script</h2>
+          <div class="download-grid">
+            <a href="element-setup-windows.cmd" class="download-card" download>
+              <div class="icon">🪟</div>
+              <div class="name">Windows</div>
+              <div class="desc">.cmd Datei</div>
+            </a>
+            <a href="element-setup-macos.command" class="download-card" download>
+              <div class="icon">🍎</div>
+              <div class="name">macOS</div>
+              <div class="desc">.command Datei</div>
+            </a>
+            <a href="element-setup-linux.sh" class="download-card" download>
+              <div class="icon">🐧</div>
+              <div class="name">Linux</div>
+              <div class="desc">.sh Datei</div>
+            </a>
+          </div>
+
+          <div class="instructions">
+            <strong>Anleitung:</strong><br><br>
+            <strong>🪟 Windows:</strong> Datei herunterladen → Doppelklick → Script läuft automatisch<br><br>
+            <strong>🍎 macOS:</strong> Datei herunterladen → Doppelklick im Finder → Script läuft automatisch<br><br>
+            <strong>🐧 Linux:</strong><br>
+            <code>chmod +x element-setup-linux.sh</code><br>
+            <code>./element-setup-linux.sh</code>
+          </div>
+        </div>
+
+        <div class="section">
+          <h2>🎨 Verfügbare Themes</h2>
+          <div class="themes">
+            <h3>Automatisch geladen in Element:</h3>
+            <div class="theme-list">
+              <div class="theme-item">aXion1337 Dark</div>
+              <div class="theme-item">Deep Purple</div>
+              <div class="theme-item">Discord Dark</div>
+              <div class="theme-item">Electric Blue</div>
+              <div class="theme-item">Everforest dark hard</div>
+              <div class="theme-item">Gruvbox Dark</div>
+              <div class="theme-item">Wal</div>
+            </div>
+          </div>
+        </div>
+
+        <div class="section">
+          <h2>❓ Support</h2>
+          <p>Für weitere Hilfe besuche: <a href="https://element.io/help" target="_blank">element.io/help</a></p>
+        </div>
+
+        <div class="support">
+          <p>Element wird automatisch installiert und konfiguriert.<br>
+          <small>Bei Fragen oder Problemen: <a href="https://element.io/help">Element Support</a></small></p>
+        </div>
+      </div>
+    </body>
+    </html>
+
+  # README
+  "README-Element-Setup.md": |
+    # Element Desktop Setup Scripts
+
+    Automatische Konfiguration und Installation von Element Desktop mit Custom Themes für aXion1337.Chat
+
+    ## 🎨 Verfügbare Themes
+    - aXion1337 Dark
+    - Deep Purple
+    - Discord Dark
+    - Electric Blue
+    - Everforest dark hard
+    - Gruvbox Dark
+    - Wal
+
+    ## 🪟 Windows
+    Herunterladen: `element-setup-windows.cmd` → Doppelklick
+
+    ## 🍎 macOS
+    Herunterladen: `element-setup-macos.command` → Doppelklick im Finder
+
+    ## 🐧 Linux
+    ```bash
+    chmod +x element-setup-linux.sh
+    ./element-setup-linux.sh
+    ```
+
+    Support: https://element.io/help
+
+  # Windows Script
+  "element-setup-windows.cmd": |
+    @echo off
+    REM Element Desktop Setup Script for Windows
+    setlocal enabledelayedexpansion
+    echo ========================================
+    echo Element Desktop Konfiguration Setup
+    echo ========================================
+    echo.
+    set APPDATA_PATH=%APPDATA%\Element
+    set CONFIG_FILE=%APPDATA_PATH%\config.json
+    if not exist "%APPDATA_PATH%" (
+        echo Erstelle Element Verzeichnis...
+        mkdir "%APPDATA_PATH%"
+    )
+    echo Erstelle config.json...
+    (
+        echo {
+        echo   "configUrl": "https://axion1337.chat/config.json",
+        echo   "brand": "aXion1337.Chat",
+        echo   "default_theme": "aXion1337 Dark",
+        echo   "show_labs_settings": true,
+        echo   "features": {
+        echo     "feature_qr_code_login": true
+        echo   },
+        echo   "setting_defaults": {
+        echo     "custom_themes": []
+        echo   }
+        echo }
+    ) > "%CONFIG_FILE%"
+    echo Config erstellt: %CONFIG_FILE%
+    echo.
+    echo Ueberpruefen Sie ob Element Desktop installiert ist...
+    where element >nul 2>nul
+    if %ERRORLEVEL% == 0 (
+        echo Starte Element Desktop...
+        start element
+        timeout /t 2 >nul
+        echo Done!
+        pause
+        exit /b 0
+    )
+    winget list --name "Element" >nul 2>nul
+    if %ERRORLEVEL% == 0 (
+        echo WinGet gefunden. Installiere Element...
+        winget install Element.Element --silent
+        timeout /t 3 >nul
+        start element
+        pause
+        exit /b 0
+    )
+    echo.
+    echo Element Desktop konnte nicht automatisch installiert werden.
+    echo Bitte installiere Element Desktop manuell:
+    echo https://element.io/download
+    echo.
+    pause
+
+  # macOS Script
+  "element-setup-macos.command": |
+    #!/bin/bash
+    echo "========================================"
+    echo "Element Desktop Konfiguration Setup"
+    echo "========================================"
+    echo ""
+    CONFIG_DIR="$HOME/Library/Application Support/Element"
+    CONFIG_FILE="$CONFIG_DIR/config.json"
+    if [ ! -d "$CONFIG_DIR" ]; then
+        echo "Erstelle Element Verzeichnis..."
+        mkdir -p "$CONFIG_DIR"
+    fi
+    echo "Erstelle config.json..."
+    cat > "$CONFIG_FILE" << 'EOF'
+    {
+      "configUrl": "https://axion1337.chat/config.json",
+      "brand": "aXion1337.Chat",
+      "default_theme": "aXion1337 Dark",
+      "show_labs_settings": true,
+      "features": {
+        "feature_qr_code_login": true
+      },
+      "setting_defaults": {
+        "custom_themes": []
+      }
+    }
+    EOF
+    echo "Config erstellt: $CONFIG_FILE"
+    echo ""
+    echo "Ueberpruefen Sie ob Element Desktop installiert ist..."
+    if [ -d "/Applications/Element.app" ]; then
+        echo "Element im Applications Folder gefunden. Starte Element..."
+        open -a Element
+        sleep 2
+        exit 0
+    fi
+    if command -v brew &> /dev/null; then
+        echo "Installiere Element uber Homebrew..."
+        brew install element --cask
+        sleep 2
+        open -a Element
+        exit 0
+    else
+        echo ""
+        echo "Homebrew nicht gefunden. Bitte installiere zuerst:"
+        echo "https://brew.sh"
+        echo ""
+        echo "Deine config.json wurde erstellt unter:"
+        echo "$CONFIG_FILE"
+        echo ""
+    fi
+    read -p "Druecke Enter zum Beenden..."
+
+  # Linux Script
+  "element-setup-linux.sh": |
+    #!/bin/bash
+    echo "========================================"
+    echo "Element Desktop Konfiguration Setup"
+    echo "========================================"
+    echo ""
+    CONFIG_DIR="$HOME/.config/Element"
+    CONFIG_FILE="$CONFIG_DIR/config.json"
+    if [ ! -d "$CONFIG_DIR" ]; then
+        echo "Erstelle Element Verzeichnis..."
+        mkdir -p "$CONFIG_DIR"
+    fi
+    echo "Erstelle config.json..."
+    cat > "$CONFIG_FILE" << 'EOF'
+    {
+      "configUrl": "https://axion1337.chat/config.json",
+      "brand": "aXion1337.Chat",
+      "default_theme": "aXion1337 Dark",
+      "show_labs_settings": true,
+      "features": {
+        "feature_qr_code_login": true
+      },
+      "setting_defaults": {
+        "custom_themes": []
+      }
+    }
+    EOF
+    echo "Config erstellt: $CONFIG_FILE"
+    echo ""
+    if command -v apt &> /dev/null; then
+        echo "Installiere Element uber apt..."
+        sudo apt update && sudo apt install -y element-desktop
+        element &
+        exit 0
+    fi
+    if command -v dnf &> /dev/null; then
+        echo "Installiere Element uber dnf..."
+        sudo dnf install -y element-desktop
+        element &
+        exit 0
+    fi
+    if command -v pacman &> /dev/null; then
+        echo "Installiere Element uber pacman..."
+        sudo pacman -S --noconfirm element-web
+        element &
+        exit 0
+    fi
+    echo "Element Desktop konnte nicht automatisch installiert werden."
+    echo "Bitte installiere Element Desktop manuell:"
+    echo "Ubuntu/Debian: sudo apt install element-desktop"
+    echo "Fedora/RHEL: sudo dnf install element-desktop"
+    echo "Arch: sudo pacman -S element-web"
+    echo ""
+    echo "Deine config.json wurde erstellt unter:"
+    echo "$CONFIG_FILE"

apps/production/element-web-docs-server.yaml

@@ -0,0 +1,92 @@
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: element-web-docs
+  namespace: matrix
+spec:
+  replicas: 1
+  selector:
+    matchLabels:
+      app: element-web-docs
+  template:
+    metadata:
+      labels:
+        app: element-web-docs
+    spec:
+      initContainers:
+      - name: copy-files
+        image: busybox:1.36
+        command: ["/bin/sh", "-c"]
+        args:
+        - |
+          mkdir -p /html/docs/setup
+          cp /config/index.html /html/docs/setup/
+          cp /config/README-Element-Setup.md /html/docs/setup/
+          cp /config/element-setup-windows.cmd /html/docs/setup/
+          cp /config/element-setup-macos.command /html/docs/setup/
+          cp /config/element-setup-linux.sh /html/docs/setup/
+          chmod 644 /html/docs/setup/*
+        volumeMounts:
+        - name: config
+          mountPath: /config
+        - name: html
+          mountPath: /html
+      containers:
+      - name: nginx
+        image: nginx:1.26-alpine
+        ports:
+        - containerPort: 8080
+        volumeMounts:
+        - name: nginx-conf
+          mountPath: /etc/nginx/conf.d/default.conf
+          subPath: nginx.conf
+        - name: html
+          mountPath: /usr/share/nginx/html
+      volumes:
+      - name: config
+        configMap:
+          name: ess-element-web-docs
+      - name: nginx-conf
+        configMap:
+          name: element-web-docs-nginx
+      - name: html
+        emptyDir: {}
+
+---
+apiVersion: v1
+kind: Service
+metadata:
+  name: element-web-docs
+  namespace: matrix
+spec:
+  selector:
+    app: element-web-docs
+  ports:
+  - protocol: TCP
+    port: 80
+    targetPort: 8080
+  type: ClusterIP
+
+---
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: element-web-docs-nginx
+  namespace: matrix
+data:
+  nginx.conf: |
+    server {
+        listen 8080;
+        server_name _;
+
+        root /usr/share/nginx/html;
+
+        location /docs/setup/ {
+            index index.html;
+            try_files $uri $uri/ =404;
+        }
+
+        location / {
+            return 404;
+        }
+    }

apps/production/kustomization.yaml

@@ -0,0 +1,19 @@
+apiVersion: kustomize.config.k8s.io/v1beta1
+kind: Kustomization
+resources:
+  - matrix-postgres-auth.yaml
+  - cert-issuer.yaml
+  - matrix-certificates.yaml
+  # Neue Dateien:
+  - custom-configs/synapse-values.yaml
+  - custom-configs/element-values.yaml
+  - custom-configs/mas-secret.yaml
+  - element-web-docs-configmap.yaml
+  - element-web-docs-server.yaml
+  # TURN Server für WebRTC
+  - coturn-secret.yaml
+  - coturn.yaml
+  # HelmRelease (muss ganz unten stehen, damit die ConfigMaps vorher da sind!)
+  - element-server-suite.yaml
+  # Custom Apex Ingress für Element Web + Well-Known auf axion1337.chat
+  - apex-ingress.yaml  # Custom Apex Ingress für Element Web + Well-Known auf axion1337.chat

apps/production/matrix-certificates.yaml

@@ -0,0 +1,77 @@
+apiVersion: cert-manager.io/v1
+kind: Certificate
+metadata:
+  name: matrix-axion1337-chat-cert
+  namespace: matrix
+spec:
+  secretName: matrix-axion1337-chat-tls
+  issuerRef:
+    name: letsencrypt-prod
+    kind: ClusterIssuer
+  dnsNames:
+    - matrix.axion1337.chat
+---
+apiVersion: cert-manager.io/v1
+kind: Certificate
+metadata:
+  name: account-axion1337-chat-cert
+  namespace: matrix
+spec:
+  secretName: account-axion1337-chat-tls
+  issuerRef:
+    name: letsencrypt-prod
+    kind: ClusterIssuer
+  dnsNames:
+    - account.axion1337.chat
+---
+apiVersion: cert-manager.io/v1
+kind: Certificate
+metadata:
+  name: mrtc-axion1337-chat-cert
+  namespace: matrix
+spec:
+  secretName: mrtc-axion1337-chat-tls
+  issuerRef:
+    name: letsencrypt-prod
+    kind: ClusterIssuer
+  dnsNames:
+    - mrtc.axion1337.chat
+---
+apiVersion: cert-manager.io/v1
+kind: Certificate
+metadata:
+  name: axion1337-chat-cert
+  namespace: matrix
+spec:
+  secretName: axion1337-chat-tls
+  issuerRef:
+    name: letsencrypt-prod
+    kind: ClusterIssuer
+  dnsNames:
+    - axion1337.chat
+---
+apiVersion: cert-manager.io/v1
+kind: Certificate
+metadata:
+  name: admin-axion1337-chat-cert
+  namespace: matrix
+spec:
+  secretName: admin-axion1337-chat-tls
+  issuerRef:
+    name: letsencrypt-prod
+    kind: ClusterIssuer
+  dnsNames:
+    - admin.axion1337.chat
+---
+apiVersion: cert-manager.io/v1
+kind: Certificate
+metadata:
+  name: turn-axion1337-chat-cert
+  namespace: matrix
+spec:
+  secretName: turn-axion1337-chat-tls
+  issuerRef:
+    name: letsencrypt-prod
+    kind: ClusterIssuer
+  dnsNames:
+    - turn.axion1337.chat

apps/production/matrix-postgres-auth.yaml

@@ -0,0 +1,22 @@
+apiVersion: v1
+data:
+    postgresql-password: ENC[AES256_GCM,data:euLWStKb/Bu+cgyvyxLAwZiLk5VjnHl+meZxcbZS1TahlbavOMEdlg==,iv:Gg2fW0vQ752tsm62n1r3Hzc/NRFBBMdGYOkbfV1jGIs=,tag:77pv1fEP2nkcEL1Dsx+hGQ==,type:str]
+kind: Secret
+metadata:
+    name: matrix-postgres-auth
+    namespace: matrix
+sops:
+    age:
+        - recipient: age14l0hwfqylwpemz5y2ghh2yxk0phszlnj3qlejhue0fw0kz3tmfgqdsjzdh
+          enc: |
+            -----BEGIN AGE ENCRYPTED FILE-----
+            YWdlLWVuY3J5cHRpb24ub3JnL3YxCi0+IFgyNTUxOSA1d3dKNGE1SGRabm1TaWhK
+            L2FBUHlWQWVaalRzS2FlTFJqNVNlT3JyUEZ3CmJPa1Mxa1VWSTZCTVlqRFk1WU5s
+            ZDJDc05obGtEdkV5cTFRa3dvbXJNM00KLS0tIHdCeHBLb090c3M4M2g5VlkzeStJ
+            ZGVhbnJYMHFjSDFPR1lWSmlBTXUzQUkK3ROf7Vu/SsPmNob/eKcPS7BwWUQrMXMW
+            YiuPlzNpT80nrtXRgm8AHbua6adV25eEVvFbroGvqkNtay8r5NUDkg==
+            -----END AGE ENCRYPTED FILE-----
+    lastmodified: "2026-04-21T12:45:16Z"
+    mac: ENC[AES256_GCM,data:yTdP4L0ffQe3pc1gwbWgTSM+mbDgIxPajJDumvXwsM4eWJO+hlmH/nONIG+cnpVCOEDtGTm0CeJd342fU5qw8tL+1tS/OTp3FNgOv3Ms5o45crgaej4LY1JI1jCi5TAz0Kpt5YR15Aeh83OU7xig2fGbSAW5riPM/wqDHGPzBhM=,iv:MK1p9VEN6x3Q0y+YveDif2L5TPzvnvGTIUAY28AB0tM=,tag:1UM56b9Qg4WnggMQVThrMQ==,type:str]
+    encrypted_regex: ^(data|stringData)$
+    version: 3.12.2

clusters/matrix/flux-system/gotk-sync.yaml

@@ -0,0 +1,27 @@
+# This manifest was generated by flux. DO NOT EDIT.
+---
+apiVersion: source.toolkit.fluxcd.io/v1
+kind: GitRepository
+metadata:
+  name: flux-system
+  namespace: flux-system
+spec:
+  interval: 1m0s
+  ref:
+    branch: main
+  secretRef:
+    name: flux-system
+  url: https://rohana.axion1337.de/sorb/axion1337.chat-gitops.git
+---
+apiVersion: kustomize.toolkit.fluxcd.io/v1
+kind: Kustomization
+metadata:
+  name: flux-system
+  namespace: flux-system
+spec:
+  interval: 10m0s
+  path: ./clusters/matrix
+  prune: true
+  sourceRef:
+    kind: GitRepository
+    name: flux-system

clusters/matrix/flux-system/infra-sync.yaml

@@ -0,0 +1,12 @@
+apiVersion: kustomize.toolkit.fluxcd.io/v1
+kind: Kustomization
+metadata:
+  name: infra-apps
+  namespace: flux-system
+spec:
+  interval: 1m
+  path: ./apps/base/infra
+  prune: true
+  sourceRef:
+    kind: GitRepository
+    name: flux-system

clusters/matrix/flux-system/kustomization.yaml

@@ -0,0 +1,8 @@
+apiVersion: kustomize.config.k8s.io/v1beta1
+kind: Kustomization
+resources:
+  - gotk-components.yaml
+  - gotk-sync.yaml
+  - infra-sync.yaml
+  - monitoring-sync.yaml
+  - production-sync.yaml

clusters/matrix/flux-system/monitoring-sync.yaml

@@ -0,0 +1,14 @@
+apiVersion: kustomize.toolkit.fluxcd.io/v1
+kind: Kustomization
+metadata:
+  name: monitoring-apps
+  namespace: flux-system
+spec:
+  interval: 10m
+  path: ./apps/monitoring
+  prune: true
+  sourceRef:
+    kind: GitRepository
+    name: flux-system
+  dependsOn:
+    - name: infra-apps

clusters/matrix/flux-system/production-sync.yaml

@@ -0,0 +1,18 @@
+apiVersion: kustomize.toolkit.fluxcd.io/v1
+kind: Kustomization
+metadata:
+  name: production-apps
+  namespace: flux-system
+spec:
+  interval: 1m
+  path: ./apps/production
+  prune: true
+  sourceRef:
+    kind: GitRepository
+    name: flux-system
+  decryption:
+    provider: sops
+    secretRef:
+      name: sops-age
+  dependsOn:
+    - name: infra-apps

docs/TASKS.md

@@ -1,503 +0,0 @@
-# aXion1337.Chat – Task List & Meilensteine
-
-**Last Updated**: 2026-05-14  
-**Statusübersicht**: [✅ 6 Abgeschlossen] [🔄 1 In Progress] [📋 15+ Pending] [🔒 10 Security]
-
----
-
-## 📊 Status Summary (Quick View)
-
-| Kategorie | Count | Status | Details |
-|-----------|-------|--------|---------|
-| **Completed** | 6 | ✅ Done | K3S, Flux, ESS, Themes, Desktop, Monitoring, TURN |
-| **In Progress** | 1 | 🔄 Blocked | Authentik Stage 2 (awaiting manual config) |
-| **Backlog** | 15+ | 📋 Pending | Element Call Fork, DB Backups, NetworkPolicies, etc. |
-| **Security Tasks** | 10 | 🔒 Pending | Firewall, SSH, auditd, Kernel hardening, CrowdSec, Falco |
-
-### Priority Distribution
-
-| Priority | Count | Timeline |
-|----------|-------|----------|
-| 🔴 **CRITICAL** | 3 | This week |
-| 🟠 **HIGH** | 4 | 1–2 weeks |
-| 🟡 **MEDIUM** | 8 | ~1 month |
-| 🟢 **LOW** | 4+ | Nice-to-have |
-
----
-
-## 🎯 Next Steps (Priorisiert)
-
-### 🔴 **THIS WEEK – CRITICAL**
-1. **Authentik Stage 2 abschließen**
-   - Manual: OIDC Provider + Application in Authentik UI erstellen
-   - Code: `upstream_oauth2_config` in `mas-secret.yaml` einfügen
-   - Code: `passwords: enabled: false` aktivieren
-   - Commit: `enable-authentik-oidc-integration-in-mas`
-   - Est. Time: 1–2 hours
-   - Blocker: Manual Authentik config (user action)
-
-2. **Hetzner Cloud Firewall – Default-Deny Setup**
-   - Ingress: Allow 80/443 only
-   - Allow SSH from your IP or via WireGuard/Tailscale
-   - Est. Time: 30 min
-   - Cost: Free
-   - Impact: Blocks 99% of internet background noise
-
-3. **SSH Hardening**
-   - Disable password auth (key-only)
-   - Disable root login
-   - MaxAuthTries 3
-   - Est. Time: 1–2 hours
-   - Priority: HIGH
-
-4. **Database Backup Strategy – Decision & First Backup**
-   - Decision: CloudNativePG (on K3S) or Hetzner Postgres (managed)?
-   - Setup: Daily automated backups
-   - Setup: Off-site storage (S3 / Storage Box)
-   - Setup: Monthly verified restores
-   - Est. Time: 2–3 days
-   - Priority: CRITICAL (disaster recovery)
-
-### 🟠 **NEXT 1–2 WEEKS – HIGH**
-1. **Authentik End-to-End Test**
-   - Test: Login flow Element → MAS → Authentik → Matrix User
-   - Test: Password reset
-   - Create: Test invite links
-   - Est. Time: 2 hours
-
-2. **Element Call Fork**
-   - Fork: element-hq/element-call
-   - Feature: Video/audio constraints parameters
-   - Integration: Synapse well-known config
-   - Est. Time: 2–3 days
-
-3. **External PostgreSQL Migration**
-   - Decision: CloudNativePG vs. Hetzner Postgres
-   - Setup: HA + Replication
-   - Migration: Move data from ESS embedded Postgres
-   - Testing: Verify all services work
-   - Est. Time: 1–2 days
-
-4. **NetworkPolicies Deployment**
-   - Create: Default-Deny for `matrix` namespace
-   - Create: Allow rules (Synapse↔Postgres, MAS↔Postgres, Ingress→Web, etc.)
-   - Test: Ensure no service breakage
-   - Est. Time: 1 day
-
----
-
-## ✅ Abgeschlossene Aufgaben (Chronologisch)
-
-### Phase 1: Basis-Setup
-- [x] **K3S Cluster aufsetzen** – Single-Node auf Hetzner Cloud (49.13.132.245)
-  - Commit: `initial-setup` (vor Projekt)
-  - Status: ✅ Läuft
-
-- [x] **Flux CD Installation**
-  - SOPS + age Encryption
-  - GitOps Repository konfigurieren
-  - Commit: `setup-flux` (vor Projekt)
-  - Status: ✅ Läuft
-
-- [x] **Element Server Suite v26.4.0 Deployment**
-  - Synapse Homeserver (`matrix.axion1337.chat`)
-  - Matrix Authentication Service (`account.axion1337.chat`)
-  - Element Web (`axion1337.chat`)
-  - Element Admin (`admin.axion1337.chat`)
-  - MatrixRTC/Element Call (`mrtc.axion1337.chat`)
-  - Commit: `deploy-ess-matrix-stack`
-  - Status: ✅ Running
-
-### Phase 2: Core Features
-- [x] **7 Custom Element Web Themes**
-  - aXion1337 Dark, Deep Purple, Discord Dark, Electric Blue, Everforest, Gruvbox, Wal
-  - Alphabetisch sortiert
-  - Commit: `add-custom-element-themes`
-  - Status: ✅ Deployed
-
-- [x] **Element Desktop Setup Scripts** (Windows/macOS/Linux)
-  - Auto-Download + Install + Config
-  - Hosted auf `axion1337.chat/docs/setup/`
-  - Commits: `add-element-desktop-setup-scripts`, `fix-element-setup-script-hosting`
-  - Status: ✅ Deployed
-
-- [x] **Room Policies**
-  - Message Retention (1d–1y lifecycle)
-  - Room Publication Rules (allow all)
-  - Auto-Join Rooms für Onboarding
-  - Commit: `add-synapse-retention-publication-autojoin`
-  - Status: ✅ Deployed
-
-### Phase 3: WebRTC & Medienübertragung
-- [x] **TURN Server (coturn) für Video-Calls**
-  - Domain: `turn.axion1337.chat`
-  - HMAC-Auth mit Shared Secret
-  - Ports: 3478/udp, 3478/tcp, 5349/tcp, 49152-65535/udp
-  - Commit: `implement-turn-server-coturn-for-webrtc-video-calls`
-  - Status: ✅ Deployed
-  - Manual: DNS A-Record + Firewall-Ports öffnen (noch erforderlich)
-
-### Phase 4: Monitoring & Observability
-- [x] **Monitoring Stack Integration**
-  - Alloy (Grafana Agent) als Collector
-  - Remote Write zu Selendis (10.0.0.3:9090 Prometheus, :3100 Loki)
-  - kube-state-metrics, node-exporter DaemonSet
-  - Commits: `integrate-monitoring-alloy-prometheus-loki`, `fix-prometheus-remote-write-docker`
-  - Status: ✅ Deployed
-
-### Phase 5: Identity Provider (Authentik)
-- [x] **Authentik Stage 1 Deployment**
-  - HelmRelease v2026.x in `authentik` namespace
-  - Embedded PostgreSQL + Alloy-compatible
-  - Cert-Manager für TLS
-  - Commit: `deploy-authentik-as-identity-provider-for-matrix-stage-1`
-  - Status: ✅ Deployed
-  - Manual: Admin-Passwort setzen + OIDC Provider erstellen (erforderlich)
-
-🔄 **[IN PROGRESS] Authentik Stage 2 – MAS Integration**
-- [ ] **MAS Upstream OIDC Konfiguration**
-  - Client ID/Secret aus Authentik Admin UI kopieren
-  - `upstream_oauth2_config` in `mas-secret.yaml` einfügen
-  - `passwords: enabled: false`
-  - Commit: (pending)
-  - Status: ⏳ Wartet auf manuelle Authentik-Konfiguration
-
-### Phase 6: Dokumentation
-- [x] **Deployment Guides erstellen**
-  - 5 Markdown-Dateien in `docs/deployment-guides/`
-  - Chronologisch geordnet
-  - Troubleshooting + Best Practices
-  - Commit: `add-comprehensive-deployment-configuration-documentation`
-  - Status: ✅ Deployed
-
----
-
-## 🔄 In Progress / Blocked
-
-### Authentik Stage 2 – MAS Integration (⏳ Depends on Manual Config)
-**Beschreibung**: Authentik OIDC Provider muss manuell im Authentik Admin UI konfiguriert werden, bevor Stage 2 Deployment möglich ist.
-
-**Schritte**:
-1. ✅ Authentik Stage 1 Deployment (done)
-2. ⏳ Authentik Admin UI: OIDC Provider erstellen (MANUAL - user action)
-3. ⏳ Authentik Admin UI: Application mit Slug `matrix` erstellen (MANUAL - user action)
-4. ⏳ Authentik Admin UI: Enrollment Flow mit Invitation Stage (MANUAL - user action)
-5. ⏳ Authentik Admin UI: Client ID + Secret kopieren (MANUAL - user action)
-6. 📋 MAS `upstream_oauth2_config` mit Client Credentials aktualisieren
-7. 📋 `passwords: enabled: false` aktivieren
-8. 📋 Commit + Push
-
-**Blocker**: Manuelle Authentik-Konfiguration (wartet auf Benutzer)
-
----
-
-## 📋 Backlog (Weitere Aufgaben)
-
-### Authentik Completion
-- [ ] **Finish Authentik Stage 2 – MAS Integration**
-  - Prerequisites: Authentik OIDC Provider vollständig konfiguriert
-  - Task: Update `mas-secret.yaml`, enable password login disable
-  - Commit: `enable-authentik-oidc-integration-in-mas`
-  - Est. Effort: 30 min (manual + scripted)
-
-- [ ] **Test End-to-End Login Flow**
-  - Element Web login → MAS → Authentik → Matrix User Creation
-  - Create test users via Authentik
-  - Verify password reset flow
-  - Commit: (implicit in Stage 2)
-  - Est. Effort: 20 min
-
-- [ ] **Create Invite Links für neue User**
-  - Authentik Admin UI → Invitations → Create
-  - Set expiry dates (7d) + use limits
-  - Document procedure
-  - Est. Effort: 15 min
-
-### Element Call Enhancement
-- [ ] **Element Call Fork für Custom Constraints**
-  - Repository: Fork `element-hq/element-call`
-  - Feature: Video/Audio constraints parameter im config
-  - Include: Bandwidth limiting, resolution limits, frame rate control
-  - Integration mit Synapse well-known
-  - Est. Effort: 2–3 days (fork + feature + test)
-  - Priority: **HIGH** (user feature)
-
-### Database Hardening
-- [ ] **External/Dedicated PostgreSQL Deployment**
-  - Option 1: CloudNativePG Operator (open-source, auf K3S)
-  - Option 2: Managed Hetzner Postgres
-  - Separate aus ESS matrix-stack embedded Postgres
-  - HA + Replication
-  - Est. Effort: 1–2 days
-  - Priority: **HIGH** (reliability)
-
-- [ ] **Database Backup Strategy**
-  - Daily automated backups (PgBackRest oder velero)
-  - Off-site backup storage (S3 / Hetzner Storage Box)
-  - Monthly verified restores (test restore → verify data integrity)
-  - Backup + restore documentation
-  - Est. Effort: 2–3 days
-  - Priority: **CRITICAL** (disaster recovery)
-
-- [ ] **Synapse Media PVC Backups**
-  - Separate backup pipeline für `/data/media_store` PVC
-  - Reason: Media oft >100GB, sollte nicht im DB-Backup sein
-  - Velero + Restic für block-level backup
-  - Est. Effort: 1 day
-  - Priority: **HIGH** (data preservation)
-
-### Network Security
-- [ ] **NetworkPolicies – K8s-Layer Segmentation**
-  - Default-Deny Ingress für `matrix` namespace
-  - Allow rules:
-    - Ingress → MAS:443
-    - Ingress → ElementWeb:443
-    - MAS ↔ Synapse:8008
-    - Synapse ↔ Postgres:5432
-    - Authentik → Postgres:5432
-    - Authentik → Loki:3100 (monitoring)
-  - Egress: Matrix-specific (federation, etc.)
-  - Est. Effort: 1 day
-  - Priority: **MEDIUM** (compliance, least-privilege)
-
-- [ ] **Pod Security Admission (Restricted)**
-  - Apply to `matrix` & `authentik` namespaces
-  - Enforce: non-root, no privileged, read-only root fs
-  - Test: Ensure no chart breakage
-  - Est. Effort: 1 day
-  - Priority: **MEDIUM** (hardening)
-
-### Federation & Access Control
-- [ ] **Federation-Allowlist oder Closed Federation**
-  - Decision: Which servers to federate with?
-  - If allowlist: explicit `federation_domain_whitelist`
-  - If closed: `allow_public_rooms_without_join_rules: false`
-  - Synapse config in `synapse-values.yaml`
-  - Est. Effort: 4 hours
-  - Priority: **MEDIUM** (security policy)
-
-### Moderation & Anti-Abuse
-- [ ] **Mjolnir/Draupnir Bot Deployment**
-  - Open-source moderation bot für Matrix
-  - Reason: Invitation-based, aber Federation kann Spam bringen
-  - Auto-ban known bad servers/users
-  - Spam-detection rules
-  - HelmChart oder custom Deployment
-  - Est. Effort: 1–2 days
-  - Priority: **MEDIUM** (ops safety)
-
-- [ ] **Content Scanner for Media**
-  - matrix-content-scanner + ClamAV antivirus
-  - Scan uploaded media for malware
-  - Block suspicious files
-  - Est. Effort: 1–2 days
-  - Priority: **LOW–MEDIUM** (optional but good practice)
-
-### Secrets Management
-- [ ] **External-Secrets Operator oder SOPS für Flux**
-  - Current: SOPS with age encryption
-  - Consideration: External-Secrets for cloud-native (AWS Secrets Manager, Hetzner Vault, etc.)
-  - OR: Improve SOPS rotation strategy
-  - Decision needed: Keep SOPS or upgrade?
-  - Est. Effort: 2–3 days (if switching)
-  - Priority: **LOW** (current SOPS setup working)
-
-### Image & Dependency Management
-- [ ] **Renovate / Dependabot Setup**
-  - Auto-update Helm Chart versions
-  - Auto-update Container Image Tags
-  - Monitor for security patches
-  - Est. Effort: 4 hours
-  - Priority: **MEDIUM** (maintenance)
-
-- [ ] **Trivy Image Scanning**
-  - Scan images in Flux HelmReleases for CVEs
-  - Block deployment if critical CVE found
-  - CI/CD hook in git workflow
-  - Est. Effort: 8 hours
-  - Priority: **LOW–MEDIUM** (security posture)
-
-- [ ] **Monitor ESS & Element Security Advisories**
-  - Subscribe to `element-hq` security mailing list
-  - Monitor `#matrix-community` security channels
-  - Auto-alerts on new CVEs/patches
-  - Est. Effort: Ongoing (low maintenance)
-  - Priority: **MEDIUM** (security awareness)
-
-### Container Security
-- [ ] **Disable automountServiceAccountToken Everywhere**
-  - Audit all Deployments/StatefulSets
-  - Disable for: Synapse, ElementWeb, MAS, Postgres, Authentik (where not needed)
-  - Add `automountServiceAccountToken: false` to spec.template.spec
-  - Test: Ensure no breakage
-  - Est. Effort: 4 hours
-  - Priority: **MEDIUM** (least-privilege)
-
----
-
-## 🔒 Security Hardening (Host & Cluster Level)
-
-### Host OS Layer (Ubuntu/Debian)
-- [ ] **Hetzner Cloud Firewall**
-  - Default-Deny inbound
-  - Allow: 80/443 (HTTP/HTTPS)
-  - Allow: 22 (SSH) from your IP only (or via WireGuard/Tailscale)
-  - Status: ✅ Can be done in Hetzner UI
-  - Est. Effort: 30 min
-  - Priority: **CRITICAL** (immediate, zero config cost)
-
-- [ ] **SSH Hardening**
-  - Disable password auth (key-only)
-  - Disable root login
-  - PermitRootLogin: no
-  - PasswordAuthentication: no
-  - MaxAuthTries: 3
-  - Optional: Change SSH port (cosmetic, reduces log noise)
-  - Optional: SSH hinter WireGuard/Tailscale (eliminates fail2ban für SSH)
-  - Est. Effort: 2 hours
-  - Priority: **HIGH** (immediate)
-
-- [ ] **unattended-upgrades**
-  - Enable automatic security updates
-  - Configure: APT::Periodic::Update-Package-Lists "1";
-  - Configure: APT::Periodic::Unattended-Upgrade "1";
-  - Configure: APT::Periodic::AutocleanInterval "7";
-  - Est. Effort: 30 min
-  - Priority: **HIGH** (set & forget)
-
-- [ ] **K3S API Security**
-  - Current: K3S API listening on :6443 on all interfaces (default)
-  - Hardening:
-    - Option 1: Firewall restrict :6443 to localhost only
-    - Option 2: K3S --bind-address + --advertise-address to WireGuard IP
-    - Option 3: kubectl access only via jumphost/bastion
-  - Est. Effort: 2 hours
-  - Priority: **HIGH** (API is high-value target)
-
-- [ ] **auditd for File Integrity & Syscall Audit**
-  - Monitor: /etc, ~/.kube, /var/lib/rancher/k3s
-  - Audit rules für sensitive file changes
-  - Low overhead, good signal/noise ratio
-  - Output to syslog / centralized logging
-  - Est. Effort: 2 hours
-  - Priority: **MEDIUM** (forensics + compliance)
-
-- [ ] **Kernel Hardening (sysctl)**
-  - Apply hardening recommendations from Lynis
-  - Key settings:
-    - kernel.kptr_restrict=2 (hide kernel pointers)
-    - kernel.dmesg_restrict=1 (restrict dmesg)
-    - net.ipv4.tcp_syncookies=1 (SYN flood protection)
-    - net.ipv4.conf.all.rp_filter=1 (reverse path filtering)
-    - net.ipv4.conf.all.send_redirects=0
-    - net.ipv6.conf.all.disable_ipv6=0 (or =1 if no IPv6 needed)
-  - Persist via /etc/sysctl.d/99-hardening.conf
-  - Est. Effort: 2 hours
-  - Priority: **MEDIUM** (defense in depth)
-
-- [ ] **Lynis Security Baseline**
-  - Run `lynis audit system`
-  - Review recommendations
-  - Implement high-priority findings
-  - Aim for score >80
-  - Re-run quarterly
-  - Est. Effort: 4 hours (initial) + 1 hour quarterly
-  - Priority: **MEDIUM** (baseline verification)
-
-### Cluster Layer (K3S / Kubernetes)
-- [ ] **CrowdSec Integration**
-  - Install CrowdSec agent on host
-  - Connect to CrowdSec Hub (commercial platform, free tier available)
-  - Feed auth.log, syslog → CrowdSec for attack detection
-  - Auto-block IPs via local firewall or Hetzner Firewall API
-  - Est. Effort: 4 hours
-  - Priority: **MEDIUM** (proactive threat response)
-
-- [ ] **Falco Runtime Monitoring**
-  - Install Falco DaemonSet in K3S
-  - Monitor: Shell spawning in containers, suspicious syscalls, privilege escalation
-  - Output to Loki / syslog
-  - Alert on anomalies
-  - Est. Effort: 1 day
-  - Priority: **MEDIUM** (runtime detection)
-
----
-
-## 🎯 Meilensteine (Milestones)
-
-| Meilenstein | Beschreibung | Status | ETA |
-|------------|-------------|--------|-----|
-| **M1: Basis-Setup** | K3S + Flux + ESS deployed | ✅ Done | - |
-| **M2: Core Matrix** | Themes, Scripts, Policies | ✅ Done | - |
-| **M3: WebRTC & Monitoring** | TURN + Alloy/Prometheus/Loki | ✅ Done | - |
-| **M4: Identity Provider** | Authentik Stage 1+2 (pending Stage 2) | 🔄 In Progress | ~1–2 days |
-| **M5: Production-Ready** | DB Backups, NetworkPolicies, Security Hardening | 📋 Backlog | ~2–3 weeks |
-| **M6: Advanced Features** | Element Call Fork, Content Scanner, Mjolnir | 📋 Backlog | ~4+ weeks |
-| **M7: Enterprise-Ready** | Full compliance (DSGVO), HA setup, Disaster Recovery | 🎯 Future | ~8+ weeks |
-
----
-
-## 📊 Prioritäts-Kategorien
-
-### 🔴 CRITICAL (do immediately)
-- Hetzner Cloud Firewall setup
-- Database backup strategy
-- SSH hardening
-
-### 🟠 HIGH (do within 1–2 weeks)
-- Authentik Stage 2 completion
-- External PostgreSQL migration
-- NetworkPolicies
-- Element Call fork
-
-### 🟡 MEDIUM (do within 1 month)
-- CrowdSec + Falco
-- Mjolnir bot
-- Renovate/Trivy
-- PSA restricted mode
-- Kernel hardening
-
-### 🟢 LOW (nice-to-have, do if time allows)
-- Content scanner (ClamAV)
-- External-Secrets upgrade
-- SSH port relocation
-- Advanced federation rules
-
----
-
-## 📝 Notes & Decision Points
-
-### Authentik Stage 2 Blocker
-⏳ **Waiting for**: User to manually configure Authentik OIDC Provider in Authentik Admin UI.
-- Once done, provide Client ID + Secret
-- Then: Commit Stage 2 MAS config
-
-### Database: CloudNativePG vs. Hetzner Postgres
-- **CloudNativePG**: Open-source, runs on K3S, full control
-- **Hetzner Postgres**: Managed, backups included, less ops overhead
-- **Decision**: Recommend CloudNativePG for now (cost-effective), migrate to Hetzner later if operational overhead too high
-
-### Federation: Allowlist vs. Closed?
-- **Allowlist**: Default federation with all public servers, can be attacked
-- **Closed**: Only federate with trusted servers (higher security, lower interop)
-- **Decision**: Depends on user intent. For now: allow all, add Mjolnir for abuse protection
-
-### Security Framework
-- **Layers**: Perimeter (Firewall) → Host (SSH, auditd, hardening) → Cluster (NetworkPolicies, PSA, Falco) → App (Rate-limits, Mjolnir)
-- **Approach**: Implement incrementally, test after each layer
-
----
-
-## 🔗 Related Documentation
-
-- `docs/deployment-guides/README.md` – Overview
-- `docs/deployment-guides/01-turn-server-setup.md` – TURN
-- `docs/deployment-guides/02-authentik-identity-provider.md` – Authentik (Stage 1 + Stage 2 plan)
-- `docs/deployment-guides/03-monitoring-integration.md` – Monitoring
-- `docs/deployment-guides/04-element-customization.md` – Themes, Desktop
-- `docs/deployment-guides/05-room-policies.md` – Policies
-
----
-
-**Last Updated**: 2026-05-14  
-**Next Review**: 2026-05-21

docs/deployment-guides/01-turn-server-setup.md

@@ -1,54 +0,0 @@
-# TURN Server (coturn) für WebRTC Video-Calls
-
-**Status**: ✅ Vollständig deployed  
-**Domain**: `turn.axion1337.chat`  
-**Public IP**: `49.13.132.245`
-
-## Problem & Lösung
-
-Videocalls scheitern mit DTLS-Timeout bei Clients hinter NAT/Firewall. **Lösung**: coturn als TURN-Relay.
-
-## Architektur
-
-Client A ──→ coturn (turn.axion1337.chat) ──→ Client B
-
-- **Ports**: 3478/udp, 3478/tcp, 5349/tcp, 49152-65535/udp
-- **Auth**: HMAC-basiert mit Shared Secret zwischen coturn + Synapse
-- **Deployment**: K3S Deployment mit `hostNetwork: true`
-
-## Dateien (in `apps/production/`)
-
-| Datei | Inhalt |
-|-------|--------|
-| `coturn.yaml` | ConfigMap + Deployment + Service |
-| `coturn-secret.yaml` | SOPS-Secret: `TURN_SECRET` |
-| `custom-configs/synapse-values.yaml` | TURN URIs + shared secret |
-| `matrix-certificates.yaml` | cert-manager Cert für `turn.axion1337.chat` |
-
-## DNS & Firewall (manuell)
-
-```
-DNS A-Record: turn.axion1337.chat → 49.13.132.245
-
-Firewall (K3S Host):
-ufw allow 3478/udp
-ufw allow 3478/tcp
-ufw allow 5349/tcp
-ufw allow 49152:65535/udp
-```
-
-## Verifikation
-
-```bash
-# Pod läuft?
-kubectl get pods -n matrix -l app=coturn
-
-# Certificate ready?
-kubectl get certificate -n matrix | grep turn
-
-# Extern testen
-docker run -it instrumentisto/coturn \
-  turnutils_uclient -v -T -u test -w test turn.axion1337.chat
-```
-
-**Weitere Details**: Siehe vollständige Dokumentation oben.

docs/deployment-guides/02-authentik-identity-provider.md

@@ -1,45 +0,0 @@
-# Authentik als Identity Provider für Matrix
-
-**Status**: ✅ Stage 1 Deployed (Authentik läuft)  
-**Pending**: Stage 2 (MAS Integration)  
-**Domain**: `auth.axion1337.chat`
-
-## Überblick
-
-Authentik = OIDC Provider für MAS → Zentrales Login + Einladungs-basierte Registrierung.
-
-## Stage 1: Authentik Deployment
-
-**Dateien** (in `apps/authentik/`):
-- `namespace.yaml`, `helm-repo.yaml`, `authentik-secret.yaml` (SOPS)
-- `authentik.yaml` (HelmRelease v2026.x + embedded Postgres)
-- `certificate.yaml`, `ingress.yaml`
-
-**Flux Kustomization**: `clusters/matrix/flux-system/authentik-sync.yaml`
-
-## Deployment-Schritte
-
-1. **DNS A-Record**: `auth.axion1337.chat → 49.13.132.245`
-2. **Pods hochfahren**: `kubectl get pods -n authentik -w`
-3. **Authentik UI**: `https://auth.axion1337.chat/if/flow/initial-setup/` → Admin-Passwort setzen
-4. **OIDC Provider**: Admin UI → OIDC Provider erstellen
-5. **Application**: Slug `matrix` (wichtig für Issuer URL!)
-6. **Redirect URIs**:
-   - `https://account.axion1337.chat/upstream/callback/01KQDJTR1ZVTG8JQ220F5BNBFZ`
-   - Post-logout: `https://axion1337.chat`
-7. **Client ID + Secret kopieren**
-
-## Stage 2: MAS Integration
-
-1. Decrypt: `sops --decrypt --in-place apps/production/custom-configs/mas-secret.yaml`
-2. `upstream_oauth2_config` + `passwords-config` Blöcke hinzufügen
-3. Encrypt: `sops --encrypt --in-place ...`
-4. Commit & Push
-5. **WICHTIG**: `passwords: enabled: false` erst nach OIDC-Test!
-
-## Einladungs-Links
-
-Authentik Admin → Flows & Stages → Invitations → Create
-
----
-**Weitere Details**: Siehe Kapitel 2 in diesem Projekt.

docs/deployment-guides/03-monitoring-integration.md

@@ -1,52 +0,0 @@
-# Monitoring: Alloy → Prometheus/Loki auf Selendis
-
-**Status**: ✅ Vollständig deployed  
-**Remote Storage**: `10.0.0.3:9090` (Prometheus), `10.0.0.3:3100` (Loki)
-
-## Überblick
-
-Alloy (Grafana Agent) sammelt Metriken & Logs vom K3S-Cluster und schickt sie zu Prometheus/Loki auf Selendis.
-
-## Komponenten
-
-| Komponente | Rolle |
-|-----------|-------|
-| **Alloy** | Metrics & Logs Collector |
-| **kube-state-metrics** | Kubernetes Object Status |
-| **node-exporter** | Host Metrics (CPU, Memory, Disk) |
-| **Prometheus** (Selendis) | Metrics Ingestion |
-| **Loki** (Selendis) | Logs Ingestion |
-
-## Dateien (in `apps/monitoring/`)
-
-- `namespace.yaml`
-- `helm-repos.yaml` (prometheus-community, grafana)
-- `kube-state-metrics.yaml`, `node-exporter.yaml`
-- `alloy-config.yaml` (River config with scrape targets + remote write)
-- `alloy.yaml` (HelmRelease)
-
-## Scrape Targets
-
-Alloy scraped:
-- **Flux Controllers** (flux-system ns, port 8080)
-- **kube-state-metrics** (monitoring:8080)
-- **node-exporter** (monitoring:9100)
-- **Synapse** (matrix.axion1337.chat:9000)
-
-Alle Remote Write zu `10.0.0.3:9090` (Prometheus) + `10.0.0.3:3100` (Loki).
-
-## Troubleshooting
-
-```bash
-# Check Alloy Logs
-kubectl logs -n monitoring -l app.kubernetes.io/name=alloy
-
-# Check Prometheus remote write
-curl http://10.0.0.3:9090/api/v1/query?query=up
-
-# Loki test
-curl -s http://10.0.0.3:3100/loki/api/v1/query_range?query=%7B%7D | jq .
-```
-
----
-**Weitere Details**: Siehe Kapitel 3.

docs/deployment-guides/04-element-customization.md

@@ -1,57 +0,0 @@
-# Element Web Customization: Themes, Desktop-Apps, Admin
-
-**Status**: ✅ Vollständig deployed  
-**Domains**: `axion1337.chat` (Web), `/docs/setup` (Scripts)
-
-## 1. Custom Themes (7 Stück)
-
-| Theme | Primärfarbe |
-|-------|-----------|
-| aXion1337 Dark | `#1a1a1a` |
-| Deep Purple | `#6a4c93` |
-| Discord Dark | `#2c2f33` |
-| Electric Blue | `#0066ff` |
-| Everforest Dark Hard | `#1e2326` |
-| Gruvbox Dark | `#282828` |
-| Wal | `#1e1e1e` |
-
-**Konfiguration**: `apps/production/custom-configs/element-values.yaml`
-
-**Anwendung (User)**: Settings → Appearance → Colour theme
-
-## 2. Desktop-Setup-Scripts
-
-| System | Datei |
-|--------|-------|
-| Windows | `element-setup-windows.cmd` (Doppelklick) |
-| macOS | `element-setup-macos.command` (Doppelklick) |
-| Linux | `element-setup-linux.sh` (bash) |
-
-**Was die Scripts tun**:
-1. config.json erstellen mit `configUrl: "https://axion1337.chat/config.json"`
-2. Element installieren (WinGet / Homebrew / apt/dnf/pacman)
-3. Element starten (auto-config laden)
-
-**Download**: `https://axion1337.chat/docs/setup/`
-
-## 3. Element Admin-Panel
-
-**URL**: `https://admin.axion1337.chat`
-
-- User verwalten
-- Room durchsuchen
-- Server-Statistiken
-
-**Konfiguration**: `apps/production/element-server-suite.yaml` (ESS Chart)
-
-## Dateien
-
-| Datei | Ort |
-|-------|-----|
-| Custom Themes | `element-values.yaml` ConfigMap |
-| Setup-Scripts | `element-web-docs-configmap.yaml` |
-| Docs Server | `element-web-docs-server.yaml` (nginx) |
-| Ingress | `apex-ingress.yaml` (`/docs/setup/` route) |
-
----
-**Weitere Details**: Siehe Kapitel 4.

docs/deployment-guides/05-room-policies.md

@@ -1,82 +0,0 @@
-# Room Policies: Retention, Publication, Auto-Join
-
-**Status**: ✅ Vollständig deployed  
-**Konfiguration**: `apps/production/custom-configs/synapse-values.yaml`
-
-## 1. Message Retention
-
-Alte Nachrichten automatisch löschen (Speicher sparen, DSGVO).
-
-```yaml
-retention:
-  enabled: true
-  default_policy:
-    min_lifetime: 1d      # Messages bleiben ≥1d
-    max_lifetime: 1y      # Messages gelöscht nach 1 Jahr
-
-media_retention:
-  local_media_lifetime: 365d      # 1 Jahr
-  remote_media_lifetime: 90d      # 90 Tage
-
-redaction_retention_period: 7d    # Gelöschte Messages noch 7d sichtbar
-```
-
-## 2. Room Publication Rules
-
-Kontrollieren welche Rooms im öffentlichen Directory sichtbar sind.
-
-```yaml
-room_list_publication_rules:
-  - user_id: "*"           # Alle User
-    action: allow          # dürfen ihre Rooms publishen
-```
-
-**Alternativ (restrictiv)**: Nur Admins publishen
-```yaml
-room_list_publication_rules:
-  - user_id: "@admin:axion1337.chat"
-    action: allow
-  - user_id: "*"
-    action: deny
-```
-
-## 3. Auto-Join Rooms
-
-Neue User automatisch in bestimmte Rooms hinzufügen (Onboarding).
-
-```yaml
-auto_join_rooms:
-  - "!announcements:axion1337.chat"
-  - "!rules:axion1337.chat"
-auto_join_rooms_for_guests: false    # Nur registered users
-```
-
-**Room ID finden**: Element Settings → Advanced → Room ID
-
-## Deployment
-
-```bash
-# Edit ConfigMap
-kubectl apply -f apps/production/custom-configs/synapse-values.yaml
-
-# Synapse neustarten
-kubectl rollout restart deployment -n matrix matrix-stack-synapse
-
-# Verify
-kubectl logs -n matrix -l app.kubernetes.io/name=synapse | grep -i "retention\|publication"
-```
-
-## Best Practices
-
-**Privater Server**:
-- max_lifetime: 1y (großzügig)
-- action: allow (alle publishen)
-- auto_join_rooms: announcements + rules
-
-**Öffentlicher Server (DSGWR)**:
-- max_lifetime: 90d (kurz)
-- action: deny (nur Admins)
-- auto_join_rooms: [] (keine Zwangs-Rooms)
-
----
-**Weitere Details**: Siehe Kapitel 5.

docs/deployment-guides/README.md

@@ -1,92 +0,0 @@
-# aXion1337.Chat – Deployment & Konfiguration Dokumentation
-
-Diese Dokumentation beschreibt die Einrichtung und Konfiguration des Matrix-Homeservers für **axion1337.chat** mit Element Server Suite (ESS) v26.4.0 auf K3S mit Flux CD GitOps.
-
-## 📋 Übersicht Deployment-Reihenfolge
-
-Die Implementierungen wurden in dieser Reihenfolge durchgeführt. Für neue Setups sollten Sie dieser Abfolge folgen:
-
-| # | Titel | Datei | Status | Zieldomäne |
-|---|-------|-------|--------|-----------|
-| 1 | TURN Server für WebRTC Video-Calls | `01-turn-server-setup.md` | ✅ Deployed | `turn.axion1337.chat` |
-| 2 | Authentik als Identity Provider | `02-authentik-identity-provider.md` | ✅ Stage 1 Deployed | `auth.axion1337.chat` |
-| 3 | Monitoring mit Alloy/Prometheus/Loki | `03-monitoring-integration.md` | ✅ Deployed | lokal (10.0.0.3) |
-| 4 | Element Web Anpassung & Desktop-Apps | `04-element-customization.md` | ✅ Deployed | `axion1337.chat` |
-| 5 | Room Policies (Retention, Publication, Auto-Join) | `05-room-policies.md` | ✅ Deployed | Matrix Synapse |
-
----
-
-## 🚀 Quick Start für neue Deployment
-
-Siehe die einzelnen Dokumentationen für detaillierte Anleitung.
-
----
-
-## 🏗️ Architektur-Übersicht
-
-```
-┌─────────────────────────────────────────────────────────────┐
-│                     Element Web (Apex)                       │
-│                   axion1337.chat (HTTP/TLS)                  │
-└──────────────────────┬──────────────────────────────────────┘
-                       │
-         ┌─────────────┼─────────────┐
-         │             │             │
-    ┌────▼────┐  ┌─────▼──────┐  ┌──▼────────┐
-    │ MAS      │  │ Well-Known │  │Docs/Setup │
-    │account.  │  │matrix/*    │  │/setup     │
-    │axion1337 │  │            │  │           │
-    └────┬────┘  └────────────┘  └───────────┘
-         │
-    ┌────▼────────────────┐
-    │ Authentik OIDC       │
-    │ auth.axion1337.chat  │
-    │ (Identity Provider)  │
-    └─────────────────────┘
-         │
-    ┌────▼────────────────┐
-    │ Synapse Matrix       │
-    │ matrix.axion1337.chat│
-    │ (Homeserver)         │
-    └──────────────────────┘
-```
-
----
-
-## 🔑 Kritische Werte & Konfigurationen
-
-### Domains
-- **Apex**: `axion1337.chat` (Element Web)
-- **Matrix Synapse**: `matrix.axion1337.chat`
-- **MAS**: `account.axion1337.chat`
-- **Authentik**: `auth.axion1337.chat`
-- **TURN Server**: `turn.axion1337.chat`
-
-### Externe Services
-- **K3S Host IP**: `49.13.132.245`
-- **Monitoring Host**: `10.0.0.3` (Selendis)
-
----
-
-## 📚 Dokumente im Detail
-
-### [01-turn-server-setup.md](01-turn-server-setup.md)
-STUN/TURN Server für WebRTC Media Relay (Video-Calls).
-
-### [02-authentik-identity-provider.md](02-authentik-identity-provider.md)
-Authentik als OIDC Provider für Matrix. Registrierung via Einladungs-Links.
-
-### [03-monitoring-integration.md](03-monitoring-integration.md)
-Alloy → Prometheus/Loki Monitoring Integration.
-
-### [04-element-customization.md](04-element-customization.md)
-Custom Themes, Desktop-Setup-Scripts, Element Admin.
-
-### [05-room-policies.md](05-room-policies.md)
-Message Retention, Room Publication, Auto-Join Policies.
-
----
-
-## 🛠️ Wartung & Troubleshooting
-
-Alle Dokumentationen enthalten Troubleshooting-Sektionen für häufige Probleme.

docs/oldwiki/authentik.md

@@ -1,117 +0,0 @@
-# Authentik als Einladungs- und Self-Registration-Layer vor MAS in ESS Community
-
-## Kurzurteil
-
-Ja — in deinem Setup ist **Authentik** technisch sinnvoll einsetzbar, aber **nicht als Ersatz für den Matrix Authentication Service**, sondern **als Upstream-OIDC-Provider vor MAS**. Das ist der sauberste Weg, weil Synapse heute eine stabile, vereinfachte Integration mit MAS hat, ESS Community zusätzliche MAS-Konfiguration ausdrücklich über `matrixAuthenticationService.additional` vorsieht, und MAS jede OIDC-konforme Upstream-Identitätsquelle unterstützt. Für ein ESS-Deployment mit delegierter Authentifizierung ist das deutlich kohärenter als eine Direktanbindung von Synapse an Authentik vorbei. citeturn31view0turn7view2turn14view1turn23search0
-
-Wichtig ist aber die Abgrenzung: Wenn dein einziges Problem wirklich nur lautet „im Admin-Frontend kann ich keine Registration Tokens mehr klicken“, dann **brauchst du Authentik nicht zwingend**. MAS hat weiterhin eine Admin-API mit Endpunkten für User-Registration-Tokens; der fehlende Komfort liegt also eher in der Oberfläche als in der Funktion selbst. Die API ist mit `urn:mas:admin` abgesichert und kann sowohl interaktiv als auch automatisiert benutzt werden. citeturn19search0turn28search0turn28search1turn28search2
-
-## Warum Authentik hier die bessere Plattform sein kann
-
-Der Mehrwert von Authentik entsteht dann, wenn du **mehr als nur ein Token-Feld** willst: Einladungen, Self-Service-Enrolment, E-Mail-Verifikation, Policies, Gruppen-Zuweisung, später vielleicht weitere Login-Quellen hinter derselben Oberfläche. Authentik kann selbst als OpenID Provider auftreten, aber auch als Relying Party gegenüber anderen OAuth/OIDC-Quellen arbeiten; MAS sieht dann nur noch **eine** saubere OIDC-Oberfläche, während Authentik die eigentliche Onboarding- und Policy-Logik kapselt. Das passt sehr gut zu MAS, weil MAS nach oben bewusst nur OIDC unterstützt und SAML/LDAP nicht selbst als Upstream sprechen will. citeturn21view0turn21view3turn14view1
-
-Für dein Ziel „potenzielle Anwender sollen sich selbst registrieren können“ ist der entscheidende Unterschied: Bei MAS-Registration-Tokens autorisierst du eine **Matrix-Registrierung**; bei Authentik autorisierst du zunächst eine **Identität im IdP**, und MAS übernimmt diese Identität anschließend per OIDC und legt daraus den Matrix-Account an. Das ist architektonisch stärker, weil dieselbe Identität später auch für andere Dienste nutzbar wird. MAS kann beim Upstream-Login den Matrix-Localpart, Display Name und E-Mail aus Claims übernehmen; für neue Nutzer gibt es dabei sogar einen expliziten Bestätigungs- bzw. Attribut-Import-Schritt. citeturn24search0turn14view0
-
-## Wann Authentik nicht nötig ist
-
-Wenn du ausschließlich einen „Einladungs-Code“ für Matrix brauchst und keinerlei separates Identitätsmanagement, dann ist die schlankere Lösung wahrscheinlich: **bei MAS bleiben und die Registration-Tokens per Admin-API verwalten**. Dafür brauchst du keinen zusätzlichen Dienst, keine zweite Postgres-Anwendung und keine zweite Policy-Oberfläche. Das ist betriebsärmer und passt gut zu kleinen Community-Setups. citeturn19search0turn28search0turn28search2
-
-Sobald du aber Dinge wie diese willst, kippt die Bewertung klar zugunsten von Authentik: verschiedene Onboarding-Flows, Einladungs-Links statt nackter Codes, E-Mail-Verifikation, Domain-Allow-Lists, Gruppen-Zuweisung, zentrale MFA-Politik oder später externe Identity-Sources. Authentik bringt dafür sowohl vorgefertigte Einladungs-Blueprints als auch Enrolment-Flows mit und kann bei Bedarf eigene Expression Policies für restriktivere Zulassungslogik einsetzen. citeturn21view1turn21view2turn30search3
-
-## Empfohlene Zielarchitektur
-
-Die von mir empfohlene Zielarchitektur ist:
-
-**Element Web / Clients → MAS → Authentik → Benutzerquelle(n)**
-
-Synapse bleibt dabei an MAS delegiert. Das ist genau der Pfad, den die Synapse- und MAS-Dokumentation heute unterstützen: Synapse integriert stabil mit MAS, und MAS kann wiederum Upstream-OIDC-Provider sprechen. Eine direkte Synapse-OIDC-Integration mit Authentik ist zwar technisch dokumentiert, wäre in deinem ESS/MAS-Setup aber die weniger saubere Variante, weil du damit an der in ESS bereits vorgesehenen Delegationsschicht vorbeikonfigurierst. citeturn31view0turn14view2turn14view1turn7view2
-
-Für Authentik selbst ist das Standardmaterial: auf Kubernetes per Helm deployen, in Produktion ein echtes PostgreSQL verwenden statt der Demo-Datenbank, und E-Mail konfigurieren, wenn du Einladungen oder Verifikations-Mails nutzen willst. Das ist wichtig, weil Authentik-Einladungen und E-Mail-basierte Enrolment-Flows ohne Mailtransport ihren eigentlichen Nutzen verlieren. citeturn34view0turn25search1
-
-Ein entscheidender UX-Punkt: Wenn in MAS genau **ein** Upstream-Provider konfiguriert ist und die lokale Passwortdatenbank deaktiviert wird, startet MAS den Upstream-Authentifizierungsfluss automatisch. Damit verhält sich das System für Endnutzer fast so, als wäre Authentik „direkt“ integriert, obwohl MAS weiterhin die Matrix-native Auth-Schicht bleibt. citeturn26view0
-
-## Konkrete Integration in ESS und FluxCD
-
-Der erste praktische Schritt ist, Authentik als eigene GitOps-Anwendung in Kubernetes einzuführen. Offiziell ist dafür das Helm-Chart vorgesehen; produktiv sollte die Datenbank extern bzw. operator-basiert laufen, und Mail sollte von Anfang an mitgedacht werden. Danach erzeugst du in Authentik eine **Application + OAuth2/OIDC Provider**-Kombination. Das ist der von Authentik empfohlene Weg zur Erstellung eines OIDC-Providers. citeturn34view0turn35view0
-
-Für den OIDC-Provider in Authentik verwendest du als Redirect-URI **nicht** die Synapse-Callback-URL aus der direkten Synapse-Dokumentation, sondern die von MAS erwartete Upstream-Callback-URL. MAS verlangt für Upstream-Provider eine stabile ULID als Provider-ID und verwendet daraus die Callback-URL `https://<auth-service-domain>/upstream/callback/<id>`. Optional kannst du zusätzlich die Backchannel-Logout-URL `https://<auth-service-domain>/upstream/backchannel-logout/<id>` hinterlegen. Authentik unterstützt für OIDC-Anwendungen Front- und Back-Channel-Logout, sofern der Provider entsprechend konfiguriert ist. citeturn14view1turn26view3turn35view1
-
-In ESS selbst musst du dafür **keinen Chart forken**. Die vorgesehene Stelle ist `matrixAuthenticationService.additional`. Dort gibst du MAS die Upstream-OIDC-Konfiguration und schaltest die lokale Passwortdatenbank ab, wenn Authentik der alleinige Eintrittspunkt werden soll. Genau dafür ist die ESS-Advanced-Dokumentation da. citeturn7view2
-
-Ein praktikabler MAS-Werteblock für deine GitOps-Struktur sieht so aus:
-
-```yaml
-matrixAuthenticationService:
-  additional:
-    10-authentik-upstream.yaml:
-      config: |
-        passwords:
-          enabled: false
-
-        account:
-          password_registration_enabled: false
-
-        upstream_oauth2:
-          providers:
-            - id: 01JVXXXXXXXXXXXXXXXAUTHN
-              issuer: "https://auth.example.com/application/o/matrix-mas/"
-              human_name: "Community Login"
-              client_id: "mas-community"
-              client_secret: "AUS_SOPS_SECRET"
-              token_endpoint_auth_method: client_secret_post
-              scope: "openid profile email"
-              fetch_userinfo: true
-              on_backchannel_logout: logout_browser_only
-
-              claims_imports:
-                localpart:
-                  action: require
-                  template: "{{ user.preferred_username }}"
-                  # Nur für Bestandskonten und nur nach Pilotphase:
-                  # on_conflict: set
-
-                displayname:
-                  action: force
-                  template: "{{ user.name }}"
-
-                email:
-                  action: force
-                  template: "{{ user.email }}"
-```
-
-Die inhaltliche Grundlage dafür kommt direkt aus den MAS-Upstream-OIDC-Dokumenten: Provider-`id` als ULID, `issuer`, `client_id`, `client_secret`, Scope, optionale UserInfo-Nutzung und Claim-Mapping für `localpart`, `displayname` und `email`. ESS injiziert genau solche zusätzlichen MAS-Dateien über `matrixAuthenticationService.additional`. citeturn14view1turn14view0turn13view5turn7view2
-
-Für das eigentliche Onboarding in Authentik hast du zwei gute Varianten. Wenn du das MAS-Token-Modell möglichst ähnlich nachbauen willst, nimmst du **Invitations**. Authentik kann Einladungs-URLs an konkrete Empfänger senden oder generische Einladungslinks bereitstellen, bei denen Benutzer ihre Credentials selbst festlegen. Wenn du eher echte Self-Service-Registrierung willst, nimmst du einen Enrolment-Flow, optional mit E-Mail-Verifikation. Beide Muster sind offiziell dokumentiert; es gibt sogar vorgefertigte Blueprints für invitation-based enrollment und Beispiel-Flows für Enrolment mit oder ohne E-Mail-Verifikation. citeturn21view1turn21view2
-
-Wenn du bei der Benutzerführung in Element noch glatter werden willst, kannst du optional in Element Web `sso_redirect_options` setzen, damit Nutzer auf der Login- oder Welcome-Seite sofort in den OIDC-/SSO-Flow gehen. Das ist kein Muss — MAS kann bei einem einzigen Upstream-Provider ohnehin automatisch weiterleiten — aber es verbessert den Eindruck eines „SSO-only“-Setups. citeturn15view4turn26view0
-
-Ein optionaler Element-Web-Block dafür wäre:
-
-```json
-{
-  "sso_redirect_options": {
-    "on_login_page": true,
-    "on_welcome_page": true
-  }
-}
-```
-
-## Risiken und Fallstricke
-
-Der heikelste Punkt ist die **Abbildung auf bestehende Matrix-Konten**. MAS kann Upstream-Identitäten an vorhandene lokale Nutzer binden, wenn der gemappte `localpart` passt. Standardmäßig verweigert MAS diese Verknüpfung aber; dafür gibt es `claims_imports.localpart.on_conflict` mit Werten wie `set`, `add` oder `replace`. Die Dokumentation warnt ausdrücklich davor, dass das bei unsauberem Mapping ein Account-Takeover-Risiko werden kann. In der Praxis heißt das: `on_conflict` nur dann einschalten, wenn du sicher garantieren kannst, dass Authentik-`preferred_username` oder ein anderes Attribut **eindeutig und dauerhaft** dem gewünschten Matrix-Localpart entspricht. citeturn26view2turn14view0
-
-Der zweite Betriebsfallstrick ist GitOps-spezifisch: Änderungen und Ergänzungen im `upstream_oauth2.providers`-Block synchronisiert MAS beim Start in seine Datenbank, **Entfernungen** aber nicht automatisch. Wenn du einen Provider wieder herausnimmst oder umbenennst, brauchst du zusätzlich `mas-cli config sync --prune`. Für FluxCD ist das wichtig, weil „Config aus Git gelöscht“ hier nicht automatisch „Provider aus MAS-DB gelöscht“ bedeutet. citeturn27search1turn13view5
-
-Der dritte Punkt betrifft Logout-Semantik. Sowohl MAS als auch Authentik können OIDC-Logout verarbeiten, aber du solltest den Modus bewusst wählen. `logout_all` in MAS ist am konsequentesten, kann aber auch Sessions beenden, die aus derselben Upstream-Sitzung stammen und über andere Flows erzeugt wurden. `logout_browser_only` ist meist die konservativere Wahl für einen ersten Rollout. Auf Authentik-Seite kannst du zusätzlich vollständiges Single Logout aktivieren, wenn Logout aus einer Anwendung auch die Authentik-Sitzung selbst und andere verbundene Anwendungen beenden soll. citeturn26view0turn35view1
-
-Falls du Authentik doch nicht einführst und stattdessen bei MAS-Registration-Tokens bleibst, solltest du den ESS-Hinweis ernst nehmen: `account.password_registration_email_required: false` darf auf einem öffentlich föderierenden System nur zusammen mit Einschränkungen wie `registration_token_required: true` benutzt werden, sonst läufst du direkt in Missbrauch und Spam. MAS selbst dokumentiert dieselben Schalter im `account`-Block: Passwort-Registrierung ist standardmäßig aus, E-Mail-Pflicht standardmäßig an, Registration-Token-Pflicht standardmäßig aus. citeturn7view2turn13view0turn13view1turn13view2
-
-## Praktische Entscheidung
-
-Wenn dein Zielbild lautet **„Einladungen, Self-Service, Verifikation, Gruppen, spätere Erweiterbarkeit“**, dann ist meine klare Empfehlung: **Authentik vor MAS**. Das ist in ESS Community sauber integrierbar, nutzt die offiziell vorgesehenen Konfigurationspfade und hält Synapse in der heute empfohlenen MAS-Architektur. citeturn7view2turn31view0turn14view1
-
-Wenn dein Zielbild dagegen nur lautet **„ich will wieder Registration Tokens vergeben können, aber ohne zweiten IdP zu betreiben“**, dann ist die wirtschaftlichere Lösung sehr wahrscheinlich: **MAS Admin API automatisieren statt Authentik einführen**. Funktional ist das möglich; der fehlende Baustein ist nur die Bedienoberfläche, nicht die darunterliegende Token-Funktion. citeturn19search0turn28search0turn28search2
-
-## Offene Punkte und Grenzen
-
-Die produktseitigen Integrationsfragen sind gut durch die offiziellen Dokumentationen abgedeckt. Was ich in diesem Bericht bewusst generisch gehalten habe, sind deine **konkreten Datei- und Pfadnamen im GitOps-Repo** sowie die **genaue Secret-Aufteilung** zwischen ConfigMap und SOPS-Secret. Die technische Empfehlung steht trotzdem fest: MAS bleibt die Matrix-Schicht, Authentik wird der Upstream-IdP, und die Integration erfolgt über `matrixAuthenticationService.additional` in ESS. citeturn7view2turn14view1

docs/oldwiki/fix report mrtc.md

@@ -1,327 +0,0 @@
-# MISSING_MATRIX_RTC_TRANSPORT in ESS 26.4.0: Ursachenanalyse und vollständiger Fix
-
-**Die Ursache ist Hypothese 1: `wellKnownDelegation.enabled: false` ist der Kill-Switch.** In genau dieser Konfiguration schreibt das ESS-Chart den Schlüssel `org.matrix.msc4143.rtc_foci` normalerweise automatisch in das an `https://axion1337.chat/.well-known/matrix/client` ausgelieferte JSON-Dokument – sobald `wellKnownDelegation.enabled: true` **und** `matrixRTC.enabled: true` gesetzt sind. Mit `wellKnownDelegation: false` fällt dieses Dokument komplett weg. Element Web hat damit keinen Discovery-Pfad zur LiveKit-Instanz auf `mrtc.axion1337.chat`, und Matrix-JS-SDK wirft genau deshalb `MISSING_MATRIX_RTC_TRANSPORT`. Hypothese 2 (Synapse-Custom-Keys sind bogus) ist ebenfalls korrekt. Hypothese 4 (Element Web braucht explizites `rtc_foci`) ist **falsch** – Element Web liest `rtc_foci` ausschließlich aus Well-Known, niemals aus `config.json`. Hypothese 5 ist ein *sekundäres* Thema: LiveKit UDP-Ports müssen offen sein, aber der Fehler `MISSING_MATRIX_RTC_TRANSPORT` entsteht ausschließlich aus der Discovery, nicht aus Medien-Erreichbarkeit.
-
-## Wie die Fehlerkette konkret abläuft
-
-Element Web ruft beim Start eines Anrufs intern zwei Discovery-Pfade auf: `GET /_matrix/client/v1/rtc/transports` gegen Synapse (MSC4143, ab Synapse 1.140) und als Fallback `GET https://<serverName>/.well-known/matrix/client`, wo der Schlüssel `org.matrix.msc4143.rtc_foci` erwartet wird. Das ESS-Chart befüllt **beide** Pfade automatisch, sobald `matrixRTC.enabled: true` ist: In `wellKnownDelegation` wird das `rtc_foci`-Array injiziert, in Synapse wird der `matrix_rtc.transports`-Block in die `homeserver.yaml` gemerged (chart-intern, siehe ess-helm Changelog Eintrag #855: *"Configure experimental MSC4143 advertisement in Synapse when MatrixRTC is enabled. This is in addition to the MSC4143 advertisement on the client well-known endpoint for now, but it is expected to replace it in time."*). **Beide Mechanismen werden durch `wellKnownDelegation.enabled: false` nicht vollständig deaktiviert** – die Synapse-Seite wird zwar weiter gesetzt, aber weil kein Well-Known am Apex existiert, kann Element Web den Homeserver gar nicht über `default_server_name` auflösen und daher auch den Transport-Endpunkt nicht konsistent nutzen. Resultat: leere Transport-Liste, Fehler ausgelöst.
-
-Ein korrektes `/.well-known/matrix/client` sieht so aus (das ist exakt, was das Chart ausliefern würde):
-
-```json
-{
-  "m.homeserver":      { "base_url": "https://matrix.axion1337.chat" },
-  "m.identity_server": { "base_url": "https://vector.im" },
-  "org.matrix.msc4143.rtc_foci": [
-    { "type": "livekit",
-      "livekit_service_url": "https://mrtc.axion1337.chat" }
-  ]
-}
-```
-
-Der Schlüsselname ist **`org.matrix.msc4143.rtc_foci`** (MSC-Prefix, kein `m.rtc_foci`). Das Value-Objekt hat zwingend `type: "livekit"` und `livekit_service_url: "https://<matrixRTC.ingress.host>"`.
-
-## Warum die Custom-Synapse-Values aktuell wirkungslos sind
-
-Die Keys `matrix_rtc_enabled` und `matrix_rtc_uri` **existieren in Synapse nicht**. Synapse kennt für MatrixRTC genau zwei Dinge: einen `experimental_features`-Block (`msc3266_enabled`, `msc4140_enabled`, `msc4222_enabled`, und implementierungsabhängig `msc4143_enabled`) und einen Top-Level-Block `matrix_rtc.transports:` für den neuen `/v1/rtc/transports`-Endpunkt. Das ESS-Chart setzt diese **automatisch**, sobald `matrixRTC.enabled: true` ist. Synapse ignoriert unbekannte Top-Level-Keys in der `homeserver.yaml` stillschweigend; der Container crasht nicht, aber es passiert auch exakt gar nichts. Der ganze `rtc-config`-Block muss raus. Der `url-previews`-Block ist dagegen legitim – die Keys `url_preview_enabled`, `url_preview_ip_range_blacklist`, `max_spider_size` sind echte Synapse-Optionen.
-
-## Der eigentliche Grund für die "ACME Race Condition"
-
-Das Problem war **nicht** ein Bug, sondern eine vorhersagbare Fehlkonfiguration: Beide Ingresses (Element Web und wellKnownDelegation) forderten über die `cert-manager.io/cluster-issuer`-Annotation **jeweils ein eigenes TLS-Secret** für denselben Host `axion1337.chat` an. Cert-manager erzeugt dann zwei `Certificate`-Objekte mit unterschiedlichen `secretName`s → zwei `Order`-Objekte → HTTP-01-Solver-Ingresses überschreiben sich gegenseitig → Let's-Encrypt-Rate-Limit schlägt zu (5 duplicate certs / 7 Tage). Siehe cert-manager Issue #2342 und Discussion #3511: *"If both ingresses have their own secret to save the certificate tls, cert-manager runs havoc and exhausts the ACME limit very quickly."* Die saubere Lösung ist, dass genau **eine** Zertifikat-Quelle für `axion1337.chat` existiert.
-
-Das ESS-Chart selbst erwartet, dass `elementWeb.ingress.host` **nicht** gleich `serverName` ist. Der Standard-Pattern ist: Element Web auf `chat.<apex>` bzw. `app.<apex>`, Well-Known auf dem Apex, und eine optionale `baseDomainRedirect.url` leitet `/` auf dem Apex zu Element Web weiter.
-
-## Fix 1 (empfohlen): Element Web auf Subdomain umziehen
-
-Das ist die Lösung, für die das Chart designt ist, und erfordert genau eine DNS-Änderung sowie YAML-Anpassungen.
-
-### DNS-Voraussetzungen
-
-| Record | Typ | Ziel | Zweck |
-|---|---|---|---|
-| `axion1337.chat` | A/AAAA | öffentliche IP des K3s-Nodes | Apex: Well-Known + Cert für Matrix-Server-Delegation |
-| `matrix.axion1337.chat` | A/AAAA | K3s-Node-IP | Synapse |
-| `account.axion1337.chat` | A/AAAA | K3s-Node-IP | Matrix Authentication Service |
-| `mrtc.axion1337.chat` | A/AAAA | K3s-Node-IP | LiveKit-Signaling + lk-jwt-service |
-| `chat.axion1337.chat` | A/AAAA | K3s-Node-IP | **NEU**: Element Web |
-| `admin.axion1337.chat` | A/AAAA | K3s-Node-IP | Element Admin |
-
-### Angepasster HelmRelease (`apps/production/element-server-suite.yaml`)
-
-```yaml
-apiVersion: helm.toolkit.fluxcd.io/v2
-kind: HelmRelease
-metadata:
-  name: matrix-stack
-  namespace: matrix
-spec:
-  interval: 1h
-  chart:
-    spec:
-      chart: matrix-stack
-      version: "26.4.0"
-      sourceRef:
-        kind: HelmRepository
-        name: element-ess-oci
-        namespace: flux-system
-  valuesFrom:
-    - kind: ConfigMap
-      name: ess-synapse-custom
-      valuesKey: values.yaml
-    - kind: ConfigMap
-      name: ess-element-custom
-      valuesKey: values.yaml
-    - kind: Secret
-      name: ess-mas-values-secret
-      valuesKey: values.yaml
-  values:
-    serverName: axion1337.chat
-    certManager:
-      clusterIssuer: letsencrypt-prod
-
-    postgres:
-      enabled: true
-
-    synapse:
-      enabled: true
-      ingress:
-        host: matrix.axion1337.chat
-
-    matrixAuthenticationService:
-      enabled: true
-      ingress:
-        host: account.axion1337.chat
-
-    matrixRTC:
-      enabled: true
-      ingress:
-        host: mrtc.axion1337.chat
-      # SFU public-IP override empfohlen, falls der Node hinter NAT steht
-      # und STUN die falsche Adresse zurückgibt:
-      # sfu:
-      #   useStunToDiscoverPublicIP: false
-      #   manualIP: "<public-IP-of-node>"
-
-    elementWeb:
-      enabled: true
-      ingress:
-        host: chat.axion1337.chat      # <- NICHT mehr der Apex
-
-    elementAdmin:
-      enabled: true
-      ingress:
-        host: admin.axion1337.chat
-
-    wellKnownDelegation:
-      enabled: true                    # <- zurück auf true (Default)
-      # Optional: Redirect vom Apex "/" auf Element Web.
-      # Das Chart-Feature kam in 26.x hinzu; falls dein konkreter Wert-Key
-      # fehlt, siehe Fix 2 (eigene IngressRoute) als sichere Alternative.
-      baseDomainRedirect:
-        url: https://chat.axion1337.chat
-```
-
-Mit diesem Setup beansprucht **genau ein** Chart-erzeugter Ingress den Apex `axion1337.chat`, nämlich der der `wellKnownDelegation`. Es gibt nur ein Zertifikat, keine Race Condition. Element Web läuft auf `chat.axion1337.chat` und bekommt sein eigenes, konfliktfreies Cert.
-
-### Bereinigter Synapse-ConfigMap (`apps/production/custom-configs/synapse-values.yaml`)
-
-```yaml
-apiVersion: v1
-kind: ConfigMap
-metadata:
-  name: ess-synapse-custom
-  namespace: matrix
-data:
-  values.yaml: |
-    synapse:
-      logging:
-        rootLevel: INFO
-        levelOverrides:
-          synapse.media.url_previewer: DEBUG
-      additional:
-        # RTC-Block ENTFERNT: matrix_rtc_enabled / matrix_rtc_uri sind keine
-        # gültigen Synapse-Keys. Das ESS-Chart setzt matrix_rtc.transports und
-        # die nötigen experimental_features automatisch, wenn matrixRTC.enabled=true.
-        1-url-previews:
-          config: |
-            url_preview_enabled: true
-            url_preview_ip_range_blacklist:
-              - '127.0.0.0/8'
-              - '10.0.0.0/8'
-              - '172.16.0.0/12'
-              - '192.168.0.0/16'
-              - '100.64.0.0/10'
-              - '192.0.0.0/24'
-              - '169.254.0.0/16'
-              - '192.88.99.0/24'
-              - '198.18.0.0/15'
-              - '192.0.2.0/24'
-              - '198.51.100.0/24'
-              - '203.0.113.0/24'
-              - '224.0.0.0/4'
-              - '::1/128'
-              - 'fe80::/10'
-              - 'fc00::/7'
-              - '2001:db8::/32'
-              - 'ff00::/8'
-              - 'fec0::/10'
-            max_spider_size: 10M
-```
-
-Wichtige Details zum `additional`-Mechanismus: die Keys werden **alphabetisch sortiert** gemerged, daher die `1-`/`2-`-Namenskonvention. Arrays werden ersetzt, nicht zusammengeführt.
-
-### Element-Web-ConfigMap (`apps/production/custom-configs/element-values.yaml`)
-
-Hier ist **keine** RTC-spezifische Änderung nötig. Element Web hat gemäß `element-web/docs/config.md` keinen `rtc_foci`-Key und entdeckt den Transport ausschließlich über Well-Known. Der optionale `element_call`-Block steuert nur Branding und Verhalten:
-
-```yaml
-apiVersion: v1
-kind: ConfigMap
-metadata:
-  name: ess-element-custom
-  namespace: matrix
-data:
-  values.yaml: |
-    elementWeb:
-      additional:
-        config.json: |
-          {
-            "brand": "aXion1337.Chat",
-            "element_call": {
-              "brand": "aXion1337 Call",
-              "use_exclusively": true
-            },
-            "features": {
-              "feature_video_rooms": true,
-              "feature_element_call_video_rooms": true
-            },
-            "show_labs_settings": true
-          }
-```
-
-`use_exclusively: true` entfernt die Legacy-Jitsi-Option aus dem UI, sodass Anrufe garantiert über MatrixRTC/LiveKit laufen.
-
-## Fix 2 (Alternative): Apex manuell splitten per Traefik IngressRoute
-
-Falls `baseDomainRedirect` in deiner 26.4.0-Revision nicht greift oder du Element Web auf dem Apex behalten willst, ersetze beide Chart-Ingresses durch eine **einzige Traefik IngressRoute mit einem einzigen Certificate**. Dadurch sieht cert-manager nur noch eine Quelle für `axion1337.chat`, und Traefik routet Pfad-basiert.
-
-```yaml
-# apps/production/apex-ingress.yaml
-apiVersion: cert-manager.io/v1
-kind: Certificate
-metadata:
-  name: axion-apex-tls
-  namespace: matrix
-spec:
-  secretName: axion-apex-tls
-  issuerRef:
-    name: letsencrypt-prod
-    kind: ClusterIssuer
-  dnsNames:
-    - axion1337.chat
----
-apiVersion: traefik.io/v1alpha1
-kind: IngressRoute
-metadata:
-  name: axion-apex
-  namespace: matrix
-spec:
-  entryPoints: [websecure]
-  tls:
-    secretName: axion-apex-tls
-  routes:
-    # Höchste Priorität: /.well-known/matrix/* -> wellKnownDelegation-Service
-    - match: Host(`axion1337.chat`) && PathPrefix(`/.well-known/matrix`)
-      kind: Rule
-      priority: 100
-      services:
-        - name: matrix-stack-well-known-delegation   # ggf. Service-Namen mit `kubectl get svc -n matrix` verifizieren
-          port: 8080
-    # Niedrigere Priorität: alles andere -> Element Web
-    - match: Host(`axion1337.chat`)
-      kind: Rule
-      priority: 10
-      services:
-        - name: matrix-stack-element-web
-          port: 8080
-```
-
-Dazu muss in der HelmRelease die automatische Chart-Ingress-Erzeugung für diese beiden Komponenten unterbunden werden – setze `wellKnownDelegation.ingress.className: "none"` bzw. `elementWeb.ingress.className: "none"` oder setze die `host`-Werte auf Dummy-Hostnames, sodass die Chart-Ingresses nicht denselben Apex beanspruchen. Fix 1 ist wegen geringerer Komplexität klar zu bevorzugen.
-
-## Netzwerk- und Firewall-Anforderungen für LiveKit
-
-**Das ist der nächste Stolperstein nach dem Well-Known-Fix.** Die HTTPS-Ingress auf `mrtc.axion1337.chat` terminiert nur **Signaling (WSS auf TCP 443)** und die lk-jwt-service-Endpunkte `/sfu/get`, `/get_token`, `/healthz`. WebRTC-Medien laufen **nicht** über den Ingress, sondern direkt zum Node auf UDP/TCP-NodePorts.
-
-Öffne auf deiner K3s-Node-Firewall (und im Router/Cloud-Security-Group):
-
-| Port | Protokoll | Standard ESS CE | Zweck |
-|---|---|---|---|
-| 80, 443 | TCP | — | Ingress + ACME HTTP-01 |
-| `rtcMuxedUdp` NodePort | **UDP** | 30002 (CE) / 30882 (Pro) | **Kritisch**: WebRTC-Medien (UDP-Mux). Ohne das: keine Audio/Video-Daten |
-| `rtcTcp` NodePort | TCP | 30881 | ICE/TCP-Fallback für Clients ohne UDP |
-| `turn` NodePort | UDP | 30004 | Nur falls `matrixRTC.sfu.exposedServices.turn.enabled: true` |
-| `turnTLS` Port | TCP | 31443 oder 443 | Nur falls TURN/TLS aktiv; braucht SNI-Passthrough und eigenes Hostname |
-
-Ermittle die tatsächlichen NodePorts per `kubectl get svc -n matrix | grep rtc`. Wenn dein Node hinter NAT steht und LiveKits STUN-basierte Public-IP-Erkennung die falsche Adresse zurückliefert, setze zusätzlich:
-
-```yaml
-matrixRTC:
-  sfu:
-    useStunToDiscoverPublicIP: false
-    manualIP: "<deine-öffentliche-IP>"
-```
-
-## Verifikationsschritte
-
-Nach Reconcile (`flux reconcile helmrelease matrix-stack -n matrix`) diese vier Tests durchführen:
-
-**1. Well-Known für Matrix-Client liefert rtc_foci:**
-```bash
-curl -sS https://axion1337.chat/.well-known/matrix/client | jq .
-# Erwartung: JSON mit "m.homeserver" UND "org.matrix.msc4143.rtc_foci"
-# das livekit_service_url == "https://mrtc.axion1337.chat" enthält.
-
-curl -sS https://axion1337.chat/.well-known/matrix/server | jq .
-# Erwartung: {"m.server": "matrix.axion1337.chat:443"}
-```
-
-**2. lk-jwt-service und LiveKit-Signaling sind erreichbar:**
-```bash
-curl -i https://mrtc.axion1337.chat/healthz
-# Erwartung: HTTP/1.1 200 OK
-
-curl -i https://mrtc.axion1337.chat/sfu/get
-# Erwartung: HTTP/1.1 405 Method Not Allowed (akzeptiert nur POST)
-
-curl -i -H "Connection: Upgrade" -H "Upgrade: websocket" \
-     -H "Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==" \
-     -H "Sec-WebSocket-Version: 13" \
-     https://mrtc.axion1337.chat/
-# Erwartung: HTTP/1.1 101 Switching Protocols (WebSocket-Upgrade)
-```
-
-**3. Synapse bietet den MSC4143-Endpunkt an:**
-```bash
-TOKEN="<gültiges-access-token>"
-curl -sS -H "Authorization: Bearer $TOKEN" \
-  https://matrix.axion1337.chat/_matrix/client/v1/rtc/transports | jq .
-# Erwartung: {"transports":[{"type":"livekit","livekit_service_url":"https://mrtc.axion1337.chat"}]}
-```
-
-**4. UDP-Medien kommen an:** In Element Web Call starten → im Chrome/Firefox-DevTools unter Netzwerk → WS prüfen, dass `wss://mrtc.axion1337.chat/rtc?access_token=...` einen `101`-Upgrade bekommt; unter `chrome://webrtc-internals` nach ICE-Candidate-Paaren mit Status `succeeded` und Typ `host/srflx` schauen. Falls nur Signaling, aber kein Media: UDP-NodePort auf Firewall prüfen.
-
-## ACME-Race dauerhaft vermeiden
-
-Merksatz: **Ein Hostname ⇒ genau ein `Certificate`-Objekt ⇒ genau ein `secretName`.** Drei betriebliche Strategien:
-
-- **Subdomain-Trennung (Fix 1):** Jede Chart-Komponente bekommt einen eigenen FQDN, jeder FQDN genau ein Cert. Keine Kollision möglich. Das ist die vom Chart vorgesehene Form.
-- **Geteiltes Secret:** Wenn zwei Ingresses denselben Host tragen müssen, trägt nur **einer** die `cert-manager.io/cluster-issuer`-Annotation. Beide referenzieren `spec.tls[].secretName` auf dasselbe Secret. Traefik wählt das Zertifikat korrekt aus.
-- **DNS-01 statt HTTP-01:** Löst den Solver-Ingress-Konflikt grundsätzlich, weil kein zweiter Ingress erzeugt wird. Setzt DNS-Provider-Credentials im ClusterIssuer voraus.
-
-## Vom Benutzer übersehene Chart-Werte
-
-Außer den oben beschriebenen Korrekturen sind diese Keys erwähnenswert, falls du feintunen willst. `matrixRTC.hostAliases` ist ein dokumentierter Workaround gegen Cluster-interne DNS-Probleme, wenn der lk-jwt-service-Pod den Homeserver-Apex bzw. Synapse über den Ingress-Controller statt direkt erreichen muss. `matrixRTC.sfu.exposedServices.<name>.portType` akzeptiert `NodePort`, `HostPort` oder `LoadBalancer` – für bare-metal K3s ohne externen LB ist `NodePort` richtig. `matrixRTC.sfu.additional."user-config.yaml".config` erlaubt rohes LiveKit-YAML für Spezialfälle (STUN-Server, Codecs). `wellKnownDelegation.additional.client` / `.server` / `.element` erlauben, in die erzeugten JSON-Dokumente zusätzliche Felder einzumischen – normalerweise nicht nötig, aber nützlich für föderative Sonderfälle.
-
-## Fazit
-
-Der eigentliche Defekt war ein einziger Kippschalter: `wellKnownDelegation.enabled: false` hat den einzig existierenden Discovery-Kanal für den LiveKit-Focus gekappt. Der darum herum gebaute Custom-Synapse-Block ist ein Red Herring – die zugehörigen Schlüssel existieren in Synapse schlicht nicht und werden ignoriert. Die ursprünglich empfundene ACME-Race ist kein Bug des Charts, sondern die vorhersagbare Folge davon, dass zwei Chart-erzeugte Ingresses (Element Web **auf dem Apex** plus Well-Known) jeweils ein eigenes Let's-Encrypt-Zertifikat für denselben Host anforderten. Sobald Element Web nach `chat.axion1337.chat` wandert und Well-Known wieder aktiv ist, produziert das Chart automatisch das korrekte `org.matrix.msc4143.rtc_foci`-Feld, injiziert den `matrix_rtc.transports`-Block in Synapse, und Element Call funktioniert – vorausgesetzt die UDP-NodePort-Firewall ist offen, was nach dem Discovery-Fix der zweite Punkt auf der Prüfliste ist.

docs/oldwiki/invitereg.md

@@ -1,498 +0,0 @@
-# Invite-basierte Selbstregistrierung mit MAS in ESS Community unter Ansible und FluxCD
-
-## Zusammenfassung
-
-Für ein entity["company","Element","matrix software company"]-basiertes ESS-Community-Deployment mit aktivem Matrix Authentication Service ist eine invite-basierte Selbstregistrierung **ohne Authentik** sauber umsetzbar. Der belastbare Weg ist: **MAS-Registrierung aktivieren, Registrierungstoken erzwingen, Tokens über die MAS Admin API erzeugen, und Standard-Onboarding über Synapse `auto_join_rooms` abbilden**. In MAS-/MSC3861-Setups sind die alten Synapse-Mechanismen für Registration Tokens bzw. Shared-Secret-Registration nicht mehr der richtige Pfad: Die Synapse-Registration-Token-API ist in diesem Modus deaktiviert, ebenso die Shared-Secret-Registration-API; die offizielle Automationsoberfläche für externe Tools ist stattdessen die MAS Admin API. citeturn1view2turn20view1turn26search11turn26search5turn35view0
-
-Für die Zuweisung zu Räumen und Spaces gilt: **MAS-Claims sind für Identitätsattribute gedacht, nicht für Raum-/Space-Mitgliedschaften**. Der robuste Standard ist daher eine Zweiteilung: **allgemeine Onboarding-Räume und Spaces über Synapse `auto_join_rooms`**, und **feingranulare, zielgruppenspezifische Mitgliedschaften über einen kleinen Post-Registration-Provisioner oder ein Synapse-Modul** über `on_user_registration` bzw. `on_user_login`. Gruppen/Communities sind heute kein sinnvolles Ziel mehr, weil Synapse diese Funktion deprecated und anschließend entfernt hat; für aktuelle Deployments solltest du konsequent mit **Spaces + Rooms** arbeiten. citeturn16view0turn16view1turn16view2turn34view0turn35view0turn17search0turn17search2
-
-Für GitOps empfehle ich eine klare Trennung zwischen **statischer Konfiguration** und **operativem Invite-Zustand**. Statisch in Git/SOPS/Flux gehören: MAS-Account-Settings, SMTP-Daten, der MAS-Admin-OAuth-Client und optionale Onboarding-Policies. **Kurzlebige Einmal-Tokens** sollten dagegen in der Regel **nicht** als dauerhafter Desired State in Git geführt werden, sondern bei Bedarf über die MAS Admin API erzeugt, per E-Mail verschickt und nur optional als Audit-Record abgelegt werden. Das passt deutlich besser zu FluxCD als das “GitOpsen” flüchtiger Einladungen. Die optionale LiveKit-/Element-Call-Schicht ist für den Registrierungsfluss architektonisch unabhängig. citeturn20view1turn23view0turn23view3turn25search0turn25search13
-
-## Zielbild und Architektur
-
-Die offizielle ESS-Dokumentation unterstützt zusätzliche Konfiguration für Synapse, MAS, Element Web und MatrixRTC/LiveKit jeweils über `additional`-Blöcke. MAS läuft dabei neben Synapse und spricht mit Synapse über den dedizierten `matrix_authentication_service`-Mechanismus; Synapse 1.136+ führt diese Integration als stabile Konfiguration. Für dein Ziel bedeutet das: ESS/Helm liefert die Plattform, MAS erzwingt die Token-basierte Registrierung, Synapse übernimmt Mitgliedschaften, und Element Web kann optional eine eigene Landing-/Invite-Seite anzeigen. citeturn1view2turn1view5turn31view1turn35view0turn24search0
-
-```mermaid
-flowchart TB
-    subgraph GitOps["GitOps-Steuerung"]
-      A[Ansible]
-      F[FluxCD]
-      G[Git Repository]
-      S[SOPS Secrets]
-      A --> G
-      S --> G
-      F --> G
-    end
-
-    subgraph K8s["Kubernetes / ESS Helm"]
-      HR[HelmRelease matrix-stack]
-      EW[Element Web]
-      MAS[Matrix Authentication Service]
-      SYN[Synapse]
-      PG[(PostgreSQL)]
-      SMTP[SMTP]
-      MOD[Optional: Post-Registration Provisioner / Synapse-Modul]
-      LK[Optional: LiveKit / Element Call]
-    end
-
-    G --> HR
-    HR --> EW
-    HR --> MAS
-    HR --> SYN
-    HR --> PG
-    HR --> LK
-
-    MAS --> PG
-    SYN --> PG
-    MAS --> SMTP
-    MAS <--> SYN
-    EW --> MAS
-    EW --> SYN
-
-    A -->|MAS Admin API| MAS
-    A -->|E-Mail Einladung| User[Neuer Benutzer]
-    User -->|Invite-Link + Registration Token| EW
-    User -->|Registrierung| MAS
-    MAS -->|User-Provisionierung| SYN
-    SYN -->|auto_join_rooms| User
-    MOD -->|join/invite per Synapse Admin API| SYN
-```
-
-Die praktikabelste Zielarchitektur ist deshalb: **Invite-Mail → MAS Token-Registierung → Synapse-Provisionierung → automatisches Standard-Onboarding via `auto_join_rooms` → optionaler Fein-Provisioner für zusätzliche Spaces/Räume**. Für Spaces ist wichtig: Synapse behandelt Spaces “unter der Haube” als Räume, daher können Space-Aliasse in `auto_join_rooms` verwendet werden. **Automatisch erzeugen** kann Synapse über `autocreate_auto_join_rooms` jedoch **keine Spaces**; Spaces müssen also vorher existieren. citeturn16view0turn16view1turn16view5
-
-Die Optionen lassen sich so einordnen:
-
-| Option | Bewertung | Stärken | Schwächen | Geeignet für |
-|---|---|---|---|---|
-| MAS Registration Tokens | **Empfohlen** | Nativ im MAS-Stack, sauber mit ESS/MAS, externe Tooling-Anbindung über Admin API | Keine offizielle, dokumentierte “Einladungs-E-Mail-Engine” für Invite-Links; Token-Versand musst du selbst automatisieren | ESS Community mit FluxCD/Ansible citeturn20view1turn12view0turn37view1turn1view2 |
-| Authentik Invitations | Möglich, aber hier unnötig | Fertiges Invite-/Enrollment-Modell, URL-basierte Invitations | Zusätzlicher IdP-Layer, mehr bewegliche Teile, für dein Ziel kein Muss | Wenn ohnehin zentraler OIDC-IdP Standard ist citeturn36search0turn36search1 |
-| Manuelle Admin-Erstellung | Solide als Fallback | Maximal kontrolliert, kein Self-Service nötig | Kein Selbstregistrierungsfluss, hoher Betriebsaufwand | Break-glass, Admin-/Testkonten citeturn27view1turn26search5 |
-
-Wichtig für die Zielmodellierung: **Groups/Communities** sind im aktuellen Synapse-Kontext kein tragfähiges Onboarding-Ziel mehr. Die offizielle Synapse-Kommunikation beschreibt Groups/Communities als deprecated und ab Synapse 1.61 entfernt; Spaces sind der vorgesehene Ersatz. Wenn du also “Spaces, Groups, Rooms” als Zielbild denkst, sollte die reale Implementierung **Spaces + Rooms** heißen. citeturn17search0turn17search2
-
-## MAS-Konfiguration und GitOps-Manifeste
-
-ESS stellt laut offizieller Doku genau den von dir benötigten Mechanismus bereit: Zusätzliche MAS-Konfiguration wird unter `matrixAuthenticationService.additional` in YAML-Fragmente gelegt und in die finale MAS-Konfiguration gemerged. Dasselbe gilt für Synapse unter `synapse.additional` und für Element Web unter `elementWeb.additional`. citeturn1view2turn31view1
-
-Der kleinste sinnvolle MAS-Block für invite-basierte Self-Registration sieht so aus. Die Felder `password_registration_enabled`, `registration_token_required` und `password_registration_email_required` sind offiziell dokumentiert; ESS dokumentiert zusätzlich explizit, dass `password_registration_email_required: false` **nur** in Kombination mit Restriktionen wie `registration_token_required: true` auf öffentlich föderierenden Deployments verantwortbar ist, weil die Instanz sonst missbraucht werden kann. citeturn2view4turn20view0turn1view2
-
-```yaml
-apiVersion: v1
-kind: Secret
-metadata:
-  name: ess-mas-values-secret
-  namespace: matrix
-stringData:
-  values.yaml: |
-    matrixAuthenticationService:
-      additional:
-        10-account.yaml:
-          config: |
-            passwords:
-              enabled: true
-              minimum_complexity: 3
-
-            account:
-              password_registration_enabled: true
-              registration_token_required: true
-              password_registration_email_required: false
-              password_change_allowed: true
-              password_recovery_enabled: false
-              login_with_email_allowed: false
-
-            # Optional, falls du Recoveries / Verifizierung brauchst
-            email:
-              from: '"Matrix Auth" <no-reply@__DOMAIN__>'
-              reply_to: '"Support" <support@__DOMAIN__>'
-              transport: smtp
-              mode: starttls
-              hostname: __SMTP_HOST__
-              port: 587
-              username: __SMTP_USERNAME__
-              password: __SMTP_PASSWORD__
-
-            # Für halböffentliche Setups empfehlenswert
-            captcha:
-              service: cloudflare_turnstile
-              site_key: __TURNSTILE_SITE_KEY__
-              secret_key: __TURNSTILE_SECRET_KEY__
-
-            policy:
-              data:
-                registration:
-                  banned_usernames:
-                    literals: ["admin", "root", "support"]
-                emails:
-                  allowed_addresses:
-                    suffixes: ["@example.org"]
-                requester:
-                  banned_ips:
-                    - 10.0.0.0/8
-                    - 192.168.0.0/16
-
-            rate_limiting:
-              registration:
-                burst: 2
-                per_second: 0.0003
-              login:
-                per_ip:
-                  burst: 5
-                  per_second: 0.02
-                per_account:
-                  burst: 30
-                  per_second: 0.1
-```
-
-Damit externe Tools Tokens anlegen können, muss die **MAS Admin API** aktiviert werden. Die offizielle MAS-Doku sagt ausdrücklich, dass `adminapi` nicht standardmäßig exponiert ist und in einen Listener aufgenommen werden muss; Zugriffe werden mit dem Scope `urn:mas:admin` geschützt. Für automatisierte Tools ist der dokumentierte Weg ein **OAuth-Client mit `client_credentials`**, dessen `client_id` in `policy.data.admin_clients` steht. citeturn20view1turn23view0turn23view3
-
-```yaml
-apiVersion: v1
-kind: Secret
-metadata:
-  name: ess-mas-admin-client
-  namespace: matrix
-stringData:
-  admin-client.yaml: |
-    http:
-      listeners:
-        - name: web
-          resources:
-            - name: discovery
-            - name: human
-            - name: oauth
-            - name: compat
-            - name: graphql
-              playground: false
-            - name: assets
-              path: ./share/assets/
-            - name: adminapi
-          binds:
-            - address: "[::]:8080"
-
-    clients:
-      - client_id: 01JV0000000000000000000001
-        client_auth_method: client_secret_basic
-        client_secret: "__MAS_ADMIN_CLIENT_SECRET__"
-
-    policy:
-      data:
-        admin_clients:
-          - 01JV0000000000000000000001
-```
-
-Dieses Secret bindest du wiederum als weiteren `additional`-Eintrag ein. So vermeidest du Dateipfad-Annahmen im Container und hältst den Client-Secret-Wert SOPS-fähig. citeturn31view1turn20view1turn23view0
-
-```yaml
-apiVersion: v1
-kind: Secret
-metadata:
-  name: ess-mas-values-secret
-  namespace: matrix
-stringData:
-  values.yaml: |
-    matrixAuthenticationService:
-      additional:
-        20-admin-client.yaml:
-          configSecret: ess-mas-admin-client
-          configSecretKey: admin-client.yaml
-```
-
-Für FluxCD genügt ein klassisches `valuesFrom`-Muster. Das bildet dein bestehendes Repo-Schema mit ConfigMaps/Secrets gut ab und bleibt mit SOPS kompatibel. citeturn31view1turn1view2
-
-```yaml
-apiVersion: helm.toolkit.fluxcd.io/v2
-kind: HelmRelease
-metadata:
-  name: matrix-stack
-  namespace: matrix
-spec:
-  interval: 1h
-  chart:
-    spec:
-      chart: matrix-stack
-      sourceRef:
-        kind: HelmRepository
-        name: element-ess-oci
-        namespace: flux-system
-  valuesFrom:
-    - kind: ConfigMap
-      name: ess-synapse-custom
-      valuesKey: values.yaml
-    - kind: ConfigMap
-      name: ess-element-custom
-      valuesKey: values.yaml
-    - kind: Secret
-      name: ess-mas-values-secret
-      valuesKey: values.yaml
-  values:
-    serverName: "__SERVER_NAME__"
-    postgres:
-      enabled: true
-    synapse:
-      enabled: true
-      ingress:
-        host: "__SYNAPSE_HOST__"
-    matrixAuthenticationService:
-      enabled: true
-      ingress:
-        host: "__MAS_HOST__"
-    elementWeb:
-      enabled: true
-      ingress:
-        host: "__ELEMENT_HOST__"
-    matrixRTC:
-      enabled: true
-      ingress:
-        host: "__MRTC_HOST__"
-```
-
-Für das automatische Standard-Onboarding nimmst du Synapse `auto_join_rooms`. Die offizielle Synapse-Doku bestätigt: neue Benutzer werden automatisch zu den gelisteten Räumen hinzugefügt; **Space-Aliasse sind erlaubt**, weil Spaces Räume sind; **Spaces werden aber nicht automatisch erzeugt**, und für private/invite-only Auto-Join-Setups muss `auto_join_mxid_localpart` gesetzt sein, wobei dieser Benutzer in den betreffenden Räumen Mitglied sein und Einladungsrechte haben muss. citeturn16view0turn16view1turn16view2
-
-```yaml
-apiVersion: v1
-kind: ConfigMap
-metadata:
-  name: ess-synapse-custom
-  namespace: matrix
-data:
-  values.yaml: |
-    synapse:
-      additional:
-        20-onboarding.yaml:
-          config: |
-            auto_join_rooms:
-              - "#welcome:__SERVER_NAME__"
-              - "#announcements:__SERVER_NAME__"
-              - "#community-space:__SERVER_NAME__"
-
-            autocreate_auto_join_rooms: false
-            auto_join_mxid_localpart: system
-            auto_join_rooms_for_guests: false
-```
-
-Für die User Experience kannst du Element Web mit einer eigenen Welcome-/Invite-Seite versehen. Offiziell unterstützt Element Web dafür `embedded_pages.welcome_url`, `login_for_welcome`, Branding-Parameter und – für native OIDC-Setups – OIDC-Client-Optionen. Für deinen Fall ist das vor allem nützlich, **weil die offizielle MAS-Dokumentation keinen stabil dokumentierten URL-Parameter zum Prefill eines Registration Tokens beschreibt**; die saubere Lösung ist daher oft eine eigene Landing-Page, die den Token erklärt oder temporär speichert und dann zum Registrierungsfluss führt. Diese Aussage ist eine Architektur-Inferenz aus den offiziellen Element- und MAS-Dokumenten. citeturn24search0turn20view1turn22view0
-
-```yaml
-apiVersion: v1
-kind: ConfigMap
-metadata:
-  name: ess-element-custom
-  namespace: matrix
-data:
-  values.yaml: |
-    elementWeb:
-      additional:
-        config.json: |
-          {
-            "embedded_pages": {
-              "welcome_url": "https://__ELEMENT_HOST__/invite/index.html",
-              "login_for_welcome": false
-            },
-            "branding": {
-              "auth_header_logo_url": "https://__ELEMENT_HOST__/assets/logo.svg"
-            }
-          }
-```
-
-Ein wichtiger Betriebs-Hinweis: Es gibt aktuell ein **offenes GitHub-Issue** im ESS-Helm-Repository, das meldet, dass `matrixAuthenticationService.additional.*` in bestimmten Konstellationen ignoriert werden könne. Das ist kein offizieller Release-Hinweis, aber als Failure-Mode ernst zu nehmen. Deshalb solltest du nach jeder Änderung das **gerenderte MAS-ConfigFile im Pod** prüfen, bevor du mit echten Einladungen arbeitest. citeturn38view0turn31view1
-
-## Einladungsworkflow und Provisionierung
-
-Der saubere GitOps-Ablauf ist in der Praxis fünfstufig. Zuerst legst du **statische Konfiguration** in Git ab: MAS-Settings, SMTP, Admin-Client, Synapse Auto-Join. Danach reconciled Flux diese Ressourcen in den Cluster. Anschließend erzeugt Ansible oder ein Shell-Skript **on demand** ein kurzlebiges Registration Token über die MAS Admin API. Dieses Token wird per E-Mail verschickt – entweder als Link zu deiner eigenen Invite-Landing-Page oder als Nachricht mit Token + Registrierungsanweisung. Beim ersten erfolgreichen Abschluss der Registrierung provisioniert MAS den Account in Synapse; Synapse zieht dann `auto_join_rooms`. Wenn du danach noch gezielt Spaces/Räume abhängig von Abteilung, Rolle oder Domäne vergeben willst, übernimmt das ein Provisioner oder ein Synapse-Modul. citeturn20view1turn12view0turn16view0turn34view0
-
-Für die **MAS Admin API** ist der dokumentierte Automationspfad `client_credentials`. Die MAS-Doku nennt dafür explizit statische Clients + `policy.data.admin_clients`. Das Access-Token kannst du discovery-basiert holen, damit du keine Token-Endpoint-Pfade hart codierst. citeturn20view1turn22view0turn23view0
-
-```bash
-#!/usr/bin/env bash
-set -euo pipefail
-
-MAS_ISSUER="https://account.__DOMAIN__/"
-CLIENT_ID="01JV0000000000000000000001"
-CLIENT_SECRET="${MAS_ADMIN_CLIENT_SECRET}"
-
-TOKEN_ENDPOINT="$(
-  curl -fsSL "${MAS_ISSUER}.well-known/openid-configuration" \
-  | jq -r '.token_endpoint'
-)"
-
-ACCESS_TOKEN="$(
-  curl -fsSL -u "${CLIENT_ID}:${CLIENT_SECRET}" \
-    -H 'Content-Type: application/x-www-form-urlencoded' \
-    -d 'grant_type=client_credentials' \
-    -d 'scope=urn:mas:admin' \
-    "${TOKEN_ENDPOINT}" \
-  | jq -r '.access_token'
-)"
-
-curl -fsSL -X POST "https://account.__DOMAIN__/api/admin/v1/user-registration-tokens" \
-  -H "Authorization: Bearer ${ACCESS_TOKEN}" \
-  -H 'Content-Type: application/json' \
-  -d '{
-    "usage_limit": 1,
-    "expires_at": "2026-05-01T12:00:00Z"
-  }' | jq
-```
-
-Die MAS-OpenAPI-Spezifikation dokumentiert für Registration Tokens genau die Felder, die du dafür brauchst: `token` optional, `usage_limit`, `expires_at`, dazu die Verwaltungsendpunkte zum **Listen**, **Updaten**, **Revoken** und **Unrevoken** unter `/api/admin/v1/user-registration-tokens`. “Valid” bedeutet laut Spec: nicht abgelaufen, nicht widerrufen und Usage-Limit nicht ausgeschöpft. Für Invite-Flows solltest du in der Regel **`usage_limit: 1` und kurze Expiry-Zeiten** verwenden. citeturn12view0turn13view0turn37view0turn37view1turn37view2
-
-Beispiel für Rotation bzw. Widerruf eines ungenutzten Tokens:
-
-```bash
-TOKEN_ID="01JVABCDEF..."
-curl -fsSL -X POST "https://account.__DOMAIN__/api/admin/v1/user-registration-tokens/${TOKEN_ID}/revoke" \
-  -H "Authorization: Bearer ${ACCESS_TOKEN}"
-```
-
-Wenn du Token-Limits oder die Ablaufzeit nachträglich anpassen willst, ist laut MAS-Admin-Spec `PUT /api/admin/v1/user-registration-tokens/{id}` der vorgesehene Weg. citeturn13view0turn11view0
-
-In Ansible lässt sich derselbe Flow sehr gut abbilden. Hier ein minimales Beispiel mit Discovery, Token-Erzeugung und Mailversand. Der SMTP-Provider ist bewusst als Platzhalter gelassen, weil du ihn nicht spezifiziert hast. Die Speicherung des erzeugten Registration-Tokens in Git ist **optional**; ich würde standardmäßig nur **Token-ID, Empfänger, Ablaufzeit und Versandzeitpunkt** als Audit speichern, nicht das Secret selbst. citeturn20view1turn12view0turn3view1turn2view5
-
-```yaml
-- name: Discover MAS token endpoint
-  ansible.builtin.uri:
-    url: "https://account.__DOMAIN__/.well-known/openid-configuration"
-    return_content: true
-  register: oidc_discovery
-
-- name: Get MAS admin access token
-  ansible.builtin.uri:
-    url: "{{ oidc_discovery.json.token_endpoint }}"
-    method: POST
-    user: "{{ mas_admin_client_id }}"
-    password: "{{ mas_admin_client_secret }}"
-    force_basic_auth: true
-    body_format: form-urlencoded
-    body:
-      grant_type: client_credentials
-      scope: urn:mas:admin
-    return_content: true
-  register: mas_oauth
-
-- name: Create single-use registration token
-  ansible.builtin.uri:
-    url: "https://account.__DOMAIN__/api/admin/v1/user-registration-tokens"
-    method: POST
-    headers:
-      Authorization: "Bearer {{ mas_oauth.json.access_token }}"
-    body_format: json
-    body:
-      usage_limit: 1
-      expires_at: "{{ invite_expires_at }}"
-    return_content: true
-  register: mas_invite
-
-- name: Build invite URL
-  ansible.builtin.set_fact:
-    invite_url: "https://__ELEMENT_HOST__/invite/?token={{ mas_invite.json.data.attributes.token | urlencode }}"
-
-- name: Send invitation email
-  community.general.mail:
-    host: "__SMTP_HOST__"
-    port: 587
-    secure: starttls
-    username: "__SMTP_USER__"
-    password: "__SMTP_PASSWORD__"
-    to: "{{ invitee_email }}"
-    from: "no-reply@__DOMAIN__"
-    subject: "Deine Matrix-Einladung"
-    body: |
-      Hallo,
-
-      hier ist deine Einladung für Matrix.
-      Einladung: {{ invite_url }}
-
-      Das Token ist einmalig nutzbar und gültig bis {{ invite_expires_at }}.
-```
-
-Für die **automatische Zuweisung** zu Spaces/Räumen nach erster Anmeldung gibt es drei robuste Muster:
-
-Erstens der Standardpfad über `auto_join_rooms`: ideal für **alle** neuen Benutzer, z. B. `#welcome`, `#announcements` und ein Haupt-Space. Das ist die einfachste und offizielle Lösung. Zweitens ein **Post-Registration-Provisioner**, der den Benutzer zusätzlich in weitere Räume einlädt oder joined. Dafür ist der offizielle Synapse-Admin-Endpunkt `POST /_synapse/admin/v1/join/<room_id_or_alias>` gedacht. Drittens ein **Synapse-Modul**, das `on_user_registration` oder `on_user_login` implementiert. Die Primärdoku beschreibt genau diese Callback-Punkte; seit Synapse 1.135 müssen Module allerdings worker-safe sein, weil `on_user_registration` auch auf Workern laufen kann. citeturn16view0turn27view0turn34view0turn35view0
-
-Ein Provisioner gegen die Synapse Admin API kann so aussehen. Dabei setze ich voraus, dass du bereits einen **user-bound** Synapse-Admin-Token hast; dafür verweist die offizielle MAS-Doku auf den Device-Code-Flow mit Synapse-Admin-Scopes. Dasselbe Dokument zeigt auch, wie man kombinierte MAS-/Synapse-Admin-Tokens interaktiv anfordern kann. citeturn27view0turn32search1turn32search0
-
-```bash
-#!/usr/bin/env bash
-set -euo pipefail
-
-SYNAPSE_BASE="https://matrix.__DOMAIN__"
-SYNAPSE_ADMIN_TOKEN="${SYNAPSE_ADMIN_TOKEN}"
-USER_ID="$1"
-
-join_room() {
-  local alias="$1"
-  curl -fsSL -X POST \
-    -H "Authorization: Bearer ${SYNAPSE_ADMIN_TOKEN}" \
-    -H 'Content-Type: application/json' \
-    "${SYNAPSE_BASE}/_synapse/admin/v1/join/${alias}" \
-    -d "{\"user_id\":\"${USER_ID}\"}" >/dev/null
-}
-
-join_room "#community-space:__SERVER_NAME__"
-join_room "#announcements:__SERVER_NAME__"
-join_room "#team-general:__SERVER_NAME__"
-```
-
-Wichtig ist hier die Abgrenzung zu “Claim Mappings”: Die offizielle MAS-OIDC-Doku beschreibt `claims_imports` für **`localpart`**, **`displayname`**, **`email`** und **`account_name`**. Daraus folgt: Claim-Mappings sind nützlich, wenn du später doch einen Upstream-OIDC-Provider ergänzen willst, aber sie lösen **nicht** die Mitgliedschaft in Spaces/Räumen. Für deinen Authentik-freien Invite-Flow ist das korrekte Modell also **Token + Synapse-Onboarding**, nicht “Claims → Rooms”. citeturn21search1turn9search4
-
-## Sicherheit und Betriebsmodell
-
-Die sicherste Konfiguration für dein Szenario ist nicht “offene Registrierung mit etwas Deko”, sondern **echte Invite-only-Registrierung**. Das bedeutet konkret: `password_registration_enabled: true`, `registration_token_required: true` und nur dann `password_registration_email_required: false`, wenn du bewusst auf Token-Schutz, kurze Laufzeiten, Single-Use und gute Missbrauchsbarrieren setzt. Genau davor warnt die ESS-Doku ausdrücklich: Ein öffentlich föderierender Server ohne Mailpflicht **und** ohne starke Restriktionen wird missbraucht. citeturn2view4turn20view0turn1view2
-
-Ich würde die Sicherheitsprofile so priorisieren:
-
-| Profil | Empfohlene Settings | Wann sinnvoll | Kommentar |
-|---|---|---|---|
-| Striktes Invite-only | `password_registration_enabled: true`, `registration_token_required: true`, `password_registration_email_required: false`, `usage_limit: 1`, kurze Expiry | Kleine Community, kuratierte Benutzerbasis | Beste Mischung aus UX und Missbrauchsschutz citeturn2view4turn12view0turn37view2 |
-| Invite-only mit Recovery | Wie oben, aber `password_recovery_enabled: true` und SMTP voll konfiguriert | Wenn Nutzer Self-Service-Passwort-Reset brauchen | Erhöht Komfort, verlangt sauberen Mailbetrieb citeturn2view4turn2view5 |
-| Halböffentlich | Tokenpflicht + CAPTCHA + E-Mail-Allowlist + restriktivere Rate-Limits | Wenn Einladungen wiederverwendbar oder breiter verteilt werden | Mehr Schutz gegen Bot-/Spam-Missbrauch citeturn3view2turn20view0turn3view1 |
-
-Zu den wichtigsten Härtungsmaßnahmen gehören: **Single-Use (`usage_limit: 1`)**, **kurze Gültigkeit**, **Rate Limits für Registrierungen**, **optional CAPTCHA**, **optional Domain-Allowlist für E-Mails**, **Banned IP/User-Agent-Regeln** und ein **interner oder streng geschützter MAS-Admin-API-Zugang**. MAS dokumentiert all diese Stellhebel explizit: `policy.data.registration.*`, `emails.allowed_addresses`, `requester.banned_ips`, CAPTCHA-Provider und `rate_limiting.registration`. citeturn20view0turn3view1turn3view2turn2view5
-
-Für die Raum-/Space-Seite gilt zusätzlich: Halte sensible Onboarding-Räume **invite-only** und vermische “öffentlich sichtbare Discovery” nicht mit einem privaten Invite-Modell. Die Matrix-/Synapse-Dokumentation empfiehlt bei privaten Setups ausdrücklich, die Sichtbarkeit öffentlicher Räume restriktiv zu halten; Synapse hat die Standardregeln für Room-Directory-Publikation in neueren Versionen auch bewusst verschärft. citeturn17search6turn35view0
-
-Ein subtiler, aber wichtiger Punkt ist die Trennung von **MAS Admin** und **Synapse Admin**. Offiziell ist `urn:mas:admin` für automatisierte `client_credentials`-Tools dokumentiert. Für `urn:synapse:admin:*` beschreibt die Scope-Referenz dagegen ein benutzergebundenes Modell; außerdem braucht Synapse-Admin zusätzlich die Matrix-API-Scopes. Daraus folgt als belastbare Betriebsregel: **Reine Maschinenautomation sollte primär MAS Admin API nutzen; Synapse-Admin-Aktionen entweder über Auto-Join, über ein Synapse-Modul oder über einen echten Service-User mit benutzergebundenem Admin-Token**. citeturn20view1turn32search0turn32search1
-
-## Tests, Rollout und Recovery
-
-Der Rollout sollte nicht mit echten Einladungen beginnen, sondern mit einem **vollständigen Dry-Run auf Staging oder einem Testkonto**. Zuerst reconcile-st du Flux, dann prüfst du das HelmRelease und die gerenderte MAS-Konfiguration. Danach testest du die MAS Admin API, erzeugst ein kurzes Einmal-Token, registrierst einen neuen Testnutzer, überprüfst `times_used`/`valid`, kontrollierst die Raum-/Space-Mitgliedschaften und widerrufst übrige Tokens. Damit deckst du sowohl die ESS-/MAS-Seite als auch die Synapse-Onboarding-Seite einmal komplett ab. citeturn20view1turn12view0turn16view0turn27view0
-
-Die fachliche Checkliste dafür ist kurz, aber strikt:
-
-- **Konfiguration vorhanden:** `matrixAuthenticationService.additional` und `synapse.additional` sind im gerenderten Config-Output sichtbar. Wegen des offenen ESS-Issues zu `additional.*` solltest du das aktiv prüfen. citeturn31view1turn38view0  
-- **MAS Admin API erreichbar:** `/api/spec.json` bzw. das Anlegen eines Tokens funktioniert mit `urn:mas:admin`. citeturn20view1turn10view0  
-- **Token-Lebenszyklus korrekt:** neues Token erscheint als `valid`, nach Nutzung steigt `times_used`, bei `usage_limit: 1` ist es anschließend nicht mehr gültig. citeturn12view0turn37view2  
-- **Onboarding korrekt:** Testnutzer landet im Haupt-Space, in Welcome/Announcements und – falls aktiviert – in weiteren Zielräumen. citeturn16view0turn27view0  
-- **Missbrauchsschutz greift:** Ablaufzeit, CAPTCHA, Rate-Limits und Policy-Regeln sind aktiv. citeturn3view1turn3view2turn20view0  
-
-Die wichtigsten Failure Modes und ihre Recovery-Schritte sind diese:
-
-| Symptom | Wahrscheinliche Ursache | Recovery |
-|---|---|---|
-| Registrierung fordert trotzdem E-Mail-Verifikation | `password_registration_email_required` ist noch `true` oder falsches MAS-Configfile aktiv | Gerendertes MAS-Configfile prüfen, Werte korrigieren, neu deployen citeturn2view4turn1view2turn38view0 |
-| `403` bei Token-Erzeugung | OAuth-Client nicht in `policy.data.admin_clients` oder falscher Scope | Client-/Policy-Fragment korrigieren, neuen Access Token holen citeturn20view1turn23view3 |
-| `404` auf `/api/admin/v1/...` | `adminapi` nicht in `http.listeners.resources` aktiviert | Listener-Block korrigieren und Redeploy citeturn20view1 |
-| User landet nicht im Space | Space existiert nicht, Space wurde nicht separat angelegt, oder `auto_join_mxid_localpart`-User kann nicht einladen | Space vorab anlegen, `system`-User joinen lassen, Rechte prüfen; Spaces werden nicht automatisch erstellt citeturn16view0turn16view1turn16view2 |
-| Feingranulare Raumzuweisung klappt nicht | Du versuchst Membership über Claim-Mapping zu lösen | Membership über Auto-Join, Provisioner oder Synapse-Modul abbilden citeturn21search1turn34view0 |
-| “Groups” lassen sich nicht mehr sinnvoll zuweisen | Groups/Communities sind im aktuellen Synapse-Modell entfernt | Auf Spaces + Rooms umstellen citeturn17search0turn17search2 |
-
-Wenn ein Invite-Token versehentlich verschickt wurde, ist der saubere Recovery-Schritt **nicht** das HelmRelease zu verändern, sondern das Token per MAS Admin API zu **revoken** und bei Bedarf ein neues zu erzeugen. Wenn ein Benutzer zwar registriert wurde, aber Raumzuweisungen fehlen, ist die schnellste operative Korrektur ein nachgelagerter Join über den Synapse-Admin-Endpunkt. Wenn ein Synapse-Modul dafür verantwortlich ist, beachte die Worker-Eigenschaft von `on_user_registration`. citeturn13view0turn27view0turn35view0
-
-## Quellenbasis und offene Punkte
-
-Die belastbarsten Primärquellen für dieses Design sind die offiziellen Dokumentationen zu ESS, MAS, Synapse, Element Web und LiveKit. Für den Vergleichspfad “Authentik Invitations” ist die offizielle Authentik-Doku hinzugezogen worden.
-
-Die Priorisierung war dabei:
-
-- ESS Advanced-Doku zur Einbindung zusätzlicher Konfigurationsdateien für MAS, Synapse, Element Web und MatrixRTC. citeturn1view2  
-- ESS Chart-Values zur Bestätigung, dass `matrixAuthenticationService.additional`/`synapse.additional`/`elementWeb.additional` offizielle Wertepfade sind. citeturn31view1turn31view4  
-- MAS-Konfigurationsreferenz für `account.*`, `captcha`, `policy`, `rate_limiting`, `email`, `clients`, `admin_clients` und HTTP-Listener. citeturn2view4turn20view0turn22view0turn23view0  
-- MAS Admin API und OpenAPI-Schema für Token-Erzeugung, Update, Revoke, Validitätsbegriff und Automationsmodell. citeturn20view1turn12view0turn13view0turn37view1turn37view2  
-- MAS Scope- und Access-Token-Doku für den Unterschied zwischen `urn:mas:admin` und benutzergebundenem Synapse-Admin-Zugriff. citeturn32search0turn32search1  
-- Synapse-Konfigurationsmanual für `auto_join_rooms`, Space-Aliasse, `autocreate_auto_join_rooms` und `auto_join_mxid_localpart`. citeturn16view0turn16view1turn16view2  
-- Synapse-Admin- und Modul-Doku für Raumzuweisung per API und Callback-Punkte `on_user_registration` / `on_user_login`. citeturn27view0turn34view0turn35view0  
-- Element-Web-Konfiguration für Welcome-/Branding-/OIDC-nahe UX-Optionen. citeturn24search0  
-- LiveKit-/Element-Call-Doku als optionale, vom Registrierungsfluss getrennte RTC-Schicht. citeturn25search0turn25search13  
-- Authentik-Invitationsdoku nur für den Vergleich innerhalb der Optionen-Tabelle. citeturn36search0turn36search1  
-
-Offen beziehungsweise bewusst konservativ behandelt bleiben drei Punkte. Erstens beschreibt die offizielle MAS-Dokumentation nach dem hier ausgewerteten Stand **keinen stabil dokumentierten Invite-Link-Parameter**, mit dem ein Registration Token sicher per URL in die MAS-UI vorbefüllt wird; deshalb empfehle ich eine eigene Landing-Page oder Token-Übermittlung im Mailtext. Zweitens ist **client_credentials** sauber für die **MAS Admin API** dokumentiert, nicht aber als Standardmuster für **Synapse-Admin-Automation**; für Synapse-Onboarding ist deshalb `auto_join_rooms` oder ein user-/modulbasierter Pfad robuster. Drittens gibt es aktuell ein offenes ESS-Helm-Issue zu `matrixAuthenticationService.additional.*`; deshalb solltest du das gerenderte MAS-Configfile im Deployment immer verifizieren, bevor du produktive Einladungen versendest. citeturn20view1turn32search0turn38view0
- 

docs/ops-configmap-sync.md

@@ -1,296 +0,0 @@
-# 🔄 GitOps ConfigMap Auto-Sync via Checksums
-
-Dieses Dokument erklärt ein Kernproblem mit **Flux CD** und **externe Konfigurationen** – und wie wir es gelöst haben.
-
----
-
-## 📋 Das Problem: Flux erkennt ConfigMap-Änderungen nicht
-
-### Die Situation
-
-Unsere HelmRelease (`element-server-suite.yaml`) nutzt `valuesFrom`, um Konfigurationen aus externen **ConfigMaps** zu laden:
-
-```yaml
-spec:
-  valuesFrom:
-    - kind: ConfigMap
-      name: ess-element-custom     # ← Diese ConfigMap
-      valuesKey: values.yaml
-    - kind: ConfigMap
-      name: ess-synapse-custom     # ← Diese ConfigMap
-      valuesKey: values.yaml
-```
-
-Diese ConfigMaps entstehen aus Dateien im Git-Repo (`apps/production/custom-configs/*.yaml`) und werden von Kustomize in den Cluster deployed.
-
-### Das Kernproblem
-
-**Flux CD reagiert NICHT automatisch, wenn sich eine ConfigMap ändert.**
-
-Warum? Flux überwacht nur das Git-Repository auf Änderungen. Wenn du `element-values.yaml` änderst:
-
-1. ✅ Flux sieht die Änderung im Git-Repo
-2. ✅ Kustomize erzeugt eine neue ConfigMap mit den neuen Werten
-3. ❌ Aber Helm (der Helm-Controller in Flux) erkennt **nicht**, dass sich die externe ConfigMap geändert hat
-4. ❌ Helm deployt das Chart nicht neu → Die alten Themes/Configs bleiben aktiv
-
-Das ist kein Bug, sondern by-design: Helm achtet nur auf:
-- Chart-Version (z.B. `26.4.0`)
-- Änderungen in den direkten `values:` Blöcken
-- Nicht auf externe Quellen wie ConfigMaps
-
----
-
-## 🔑 Die Lösung: Checksums als Trigger
-
-Wir nutzen **Annotations mit Checksums** als Workaround:
-
-```yaml
-apiVersion: helm.toolkit.fluxcd.io/v2
-kind: HelmRelease
-metadata:
-  annotations:
-    element-config-checksum: "401f8a87d0ef5d91d2e5032d4aede42c"  # ← Hash der element-values.yaml
-    synapse-config-checksum: "e98fe81141f52e7ea833596ca39853b9"  # ← Hash der synapse-values.yaml
-```
-
-Wenn sich der Annotation-Wert ändert, sieht Flux, dass die **HelmRelease selbst** sich geändert hat – und deployt neu.
-
-### Automatisierung via Git Pre-Commit Hook
-
-Das Problem: Wer aktualisiert die Checksums, wenn man `element-values.yaml` editiert?
-
-**Lösung:** Ein Git **pre-commit Hook** tut das automatisch:
-
-```bash
-$ vi apps/production/custom-configs/element-values.yaml
-# (Farbe ändern, Theme hinzufügen, …)
-
-$ git add apps/production/custom-configs/element-values.yaml
-$ git commit -m "feat: new theme"
-# ← Der Hook läuft jetzt:
-#   1. Berechnet MD5-Hash der neuen element-values.yaml
-#   2. Aktualisiert die Annotation in kustomization.yaml
-#   3. Added kustomization.yaml zum Commit automatisch
-```
-
-Der User muss **nichts Zusätzliches tun** – alles läuft automatisch.
-
----
-
-## 🚀 Installation
-
-Nach dem Repository **klonen**, führe dieses Skript aus:
-
-```bash
-cd prod/gitops
-./scripts/install-hooks.sh
-```
-
-Das Skript:
-- ✅ Erstellt einen Symlink `.git/hooks/pre-commit` → `scripts/hooks/pre-commit`
-- ✅ Macht die Hook-Datei ausführbar
-- ✅ Gibt dir eine Bestätigungsmeldung
-
-**Einmalig pro lokales Repository.** Neue Klone müssen den Hook auch installieren.
-
----
-
-## 📝 Workflow: ConfigMaps ändern
-
-So sieht die Praxis aus:
-
-### 1️⃣ Änderung machen
-
-```bash
-vi apps/production/custom-configs/element-values.yaml
-# Edit: Themes, Farben, Logging-Level, etc.
-```
-
-### 2️⃣ Committen (Hook läuft automatisch)
-
-```bash
-git add apps/production/custom-configs/element-values.yaml
-git commit -m "feat: add Dark Purple theme variant"
-
-# Pre-Commit Hook läuft automatisch:
-# → Berechnet neuen Hash
-# → Updated kustomization.yaml
-# → Added kustomization.yaml zum Commit
-```
-
-### 3️⃣ Überprüfung (optional)
-
-```bash
-# Schaue, was committet wird:
-git show --stat
-
-# Output sollte zeigen:
-#   element-values.yaml (modified)
-#   kustomization.yaml (modified) ← vom Hook hinzugefügt
-```
-
-### 4️⃣ Pushen & Deployen
-
-```bash
-git push
-# ← Flux sieht die Änderung an kustomization.yaml
-# ← HelmRelease wird neu-synced mit den neuen Checksums
-# ← Die neue Config ist in ~5 Minuten aktiv
-```
-
----
-
-## 🔧 Technische Details
-
-### Welche Dateien sind "überwacht"?
-
-Der Hook beobachtet:
-
-| Datei | Annotation | Ziel |
-|-------|-----------|------|
-| `apps/production/custom-configs/element-values.yaml` | `element-config-checksum` | Element Web Themes, Branding |
-| `apps/production/custom-configs/synapse-values.yaml` | `synapse-config-checksum` | Synapse Logging, Federation |
-
-### Hook-Implementation
-
-Der Hook (`scripts/hooks/pre-commit`) macht folgendes:
-
-1. Prüft, ob eine der überwachten Dateien geändert wurde (`git diff --cached`)
-2. Berechnet den MD5-Hash der Datei (kompatibel mit macOS/Linux)
-3. Ersetzt den Hash-Wert in `apps/production/kustomization.yaml` via `sed`
-4. Added `kustomization.yaml` automatisch zum Commit mit `git add`
-
-```bash
-# Beispiel: element-values.yaml ändert sich von
-value: "401f8a87d0ef5d91d2e5032d4aede42c" # element-config
-# zu
-value: "a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6" # element-config
-```
-
----
-
-## ⚠️ Häufige Fragen
-
-### F: Was passiert, wenn der Hook fehlschlägt?
-
-A: Der Commit wird **abgebrochen**. Du siehst eine Fehlermeldung. Typische Gründe:
-- `md5` oder `md5sum` nicht installiert (sehr unwahrscheinlich)
-- `sed` Syntax-Fehler (sehr selten)
-
-Lass dich nicht entmutigen – rufe denen auf, die das Setup machen 🚀
-
-### F: Kann ich den Hook deaktivieren?
-
-A: Ja, aber bitte nicht! Wenn du temporär ohne Hook arbeiten möchtest:
-
-```bash
-git commit --no-verify
-```
-
-Das umgeht den Hook einmalig. Danach musst du die Checksums manuell aktualisieren.
-
-### F: Der Hook touched `kustomization.yaml`, obwohl ich sie nicht editiert habe?
-
-A: Das ist **Absicht**. Der Hook updated **nur** die Checksums, nicht den Rest der Datei. Das ist sauber und Git-freundlich.
-
-### F: Was wenn ich mehrere ConfigMaps gleichzeitig ändere?
-
-A: Der Hook aktualisiert **alle** deren Checksums in einem Pass. Keine Probleme.
-
----
-
-## 🧪 Verifikation: Hook funktioniert?
-
-Teste es selbst:
-
-```bash
-# 1. Hook installieren
-./scripts/install-hooks.sh
-
-# 2. Eine Teständerung machen
-echo "# Test" >> apps/production/custom-configs/element-values.yaml
-
-# 3. Committen
-git add apps/production/custom-configs/element-values.yaml
-git commit -m "test: verify hook"
-
-# 4. Überprüfung: Wurde kustomization.yaml auto-updated?
-git diff HEAD~1 apps/production/kustomization.yaml | grep -i checksum
-
-# Output sollte zeigen, dass ein Checksum sich geändert hat
-```
-
-Wenn ja → Hook funktioniert! ✅  
-Wenn nein → Rufe uns an 📞
-
----
-
-## 📚 Zusammenhang mit Flux CD
-
-```
-┌─────────────────────────────────────────────────────────────┐
-│ Git Repository (axion1337.chat-gitops)                      │
-├─────────────────────────────────────────────────────────────┤
-│                                                              │
-│  apps/production/custom-configs/                            │
-│  ├── element-values.yaml (du änderst das)                   │
-│  ├── synapse-values.yaml                                    │
-│  └── mas-secret.yaml                                        │
-│                                                              │
-│  apps/production/                                           │
-│  └── kustomization.yaml (Hook updated die Checksums hier)   │
-│                                                              │
-│  apps/production/                                           │
-│  └── element-server-suite.yaml (HelmRelease mit Annotations)│
-│                                                              │
-└─────────────────────────────────────────────────────────────┘
-                            ↓ git push
-┌─────────────────────────────────────────────────────────────┐
-│ FluxCD im Kubernetes-Cluster                                │
-├─────────────────────────────────────────────────────────────┤
-│                                                              │
-│ 1. GitRepository Source                                     │
-│    └─ Fetcht dein Repo alle 10 Minuten                      │
-│                                                              │
-│ 2. Kustomization production-apps                            │
-│    └─ Applyt die Kustomize-Overlays                         │
-│    └─ Erzeugt ConfigMaps mit neuen Werten                   │
-│                                                              │
-│ 3. HelmRelease matrix-stack                                 │
-│    └─ Sieht neue Annotations (Checksums)                    │
-│    └─ Deployt Helm-Chart mit neuen Werten                   │
-│                                                              │
-│ 4. Element Web Pods                                         │
-│    └─ Restarten automatisch                                 │
-│    └─ Laden neue Config aus der ConfigMap                   │
-│                                                              │
-└─────────────────────────────────────────────────────────────┘
-```
-
----
-
-## 🚨 Notfall: Manuelle Checksum-Aktualisierung
-
-Falls der Hook ausfällt (z.B. weil Git Hooks in CI deaktiviert sind), kannst du Checksums manuell aktualisieren:
-
-```bash
-# 1. Neuen Hash berechnen
-md5sum apps/production/custom-configs/element-values.yaml
-# Output: a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6  apps/production/custom-configs/element-values.yaml
-
-# 2. Annotation in kustomization.yaml updaten
-vi apps/production/kustomization.yaml
-# Ändere: value: "a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6" # element-config
-
-# 3. Committen
-git add apps/production/kustomization.yaml
-git commit -m "fix: manual checksum update"
-git push
-```
-
----
-
-**Version:** 1.0  
-**Letztes Update:** 2026-05-14  
-**Kompatibilität:** FluxCD 2.x, Kustomize 5.x+

wiki/index.md

@@ -1,9 +0,0 @@
-# aXion1337.Chat Wiki
-
-Welcome to the aXion1337.Chat deployment wiki!
-
-## 📚 Contents
-- [Deployment Guides](deployment-guides)
-- [Tasks & Roadmap](tasks)
-- [Architecture](architecture)
-