WJ-Kreis-Digital-Standard

Zusammenarbeit in Echtzeit: Collabora, Talk und das High-Performance-Backend

Stand: 2026-08-13 (Faktenbasis: Inventare in meta/). Referenz-Installation: hafen.wj-konstanz-hegau.de (WJ Konstanz-Hegau).

Dieses Kapitel beschreibt die Echtzeit-Schicht des Standards: gemeinsames Arbeiten an Dokumenten im Browser (Collabora), Chat und Videokonferenz im eigenen Haus (Nextcloud Talk) und die Infrastruktur, die Videokonferenzen ab einer Handvoll Teilnehmenden erst stabil macht (das High-Performance-Backend, kurz HPB). Dazu kommt ein geplanter Baustein, der den Standard von "WhatsApp-Ersatz" zu "Sitzungs-Werkzeug" hebt: Anruf-Aufnahme mit lokaler Transkription. Der rote Faden durch alle vier Themen ist derselbe: Die Daten, auch Gesprächs-Audio, bleiben auf dem Server des Kreises.

3.1 Collabora: Office im Browser

Warum Collabora

Ohne Office-Anbindung ist Nextcloud ein Dateiablage-System: Dokumente müssen heruntergeladen, lokal bearbeitet und wieder hochgeladen werden. Genau an dieser Stelle entstehen die Versions-Konflikte ("Protokoll_final_v3_NEU.docx"), die ehrenamtliche Teams lähmen. Collabora CODE bringt LibreOffice-Technologie als Dienst in den Browser: Mehrere Personen bearbeiten dasselbe Dokument gleichzeitig, die Datei verlässt dabei nie den Server. Für einen WJ-Kreis heißt das konkret: Vorstandsprotokolle, Event-Planungslisten und Vorlagen liegen in den Gruppenordnern (Kapitel Dateistruktur) und werden dort bearbeitet, nicht in Mail-Anhängen herumgereicht.

Auf der Referenz-Installation läuft Collabora als Docker-Container (collabora/code), gebunden auf 127.0.0.1:9980, nach außen gereicht über einen eigenen Apache-vHost mit Let's-Encrypt-Zertifikat. Die Nextcloud-Seite bindet sich über die App richdocuments (Referenz: Version 11.1.0 auf Nextcloud 34.0.2) an. Dieses Muster, Dienst nur auf localhost plus TLS-Reverse-Proxy davor, zieht sich durch die gesamte Referenz-Installation und gilt im Standard für jeden Zusatzdienst.

Grenzen ehrlich benannt

Collabora ist LibreOffice, nicht Microsoft Office. Für den Alltag eines Kreises (Protokolle, Listen, einfache Präsentationen) reicht das vollständig. Drei Grenzen solltet ihr kennen, bevor ihr sie im Vorstand versprecht:

  1. Dokumente mit komplexen Makros, Formularfeldern oder aufwendigem Layout aus Microsoft Office können anders dargestellt werden. Wer pixelgenaue Kompatibilität braucht (etwa für extern vorgegebene Formulare), bearbeitet diese Einzelfälle weiter lokal.
  2. Die gleichzeitige Bearbeitung skaliert auf einem kleinen Kreis-Server gut für typische Gremiengrößen. Ein Kreis-Server dieser Klasse ist kein Ersatz für eine Konzern-Office-Farm, das muss er auch nicht sein.
  3. Collabora rendert serverseitig, braucht also dauerhaft RAM. Auf einem geteilten Server konkurriert es mit allen anderen Diensten (siehe 3.4 zur RAM-Realität der Referenz).

Mitnutzungs-Pattern: eine Collabora-Instanz für mehrere Kreise (aliasgroups)

Ein Collabora-Container kann mehrere Nextcloud-Instanzen bedienen. Das ist das zentrale Sparpotenzial im Paten-Modell, bei dem ein erfahrener Kreis einem startenden Kreis eine Demo- oder Anfangsinstanz auf dem eigenen Server mitbetreibt: Der startende Kreis braucht keinen eigenen Office-Dienst, sondern wird als zusätzliche aliasgroup am bestehenden Container angemeldet.

Das Muster, wie auf der Referenz für die Demo-Replika WJ Hochrhein umgesetzt (Script setup-demo-11.sh im Repo):

  1. Den Collabora-Container mit erweitertem Env-File neu erstellen, das pro zusätzlicher Instanz einen Eintrag aliasgroupN=https://<zweite-nc-domain>:443 enthält (Referenz: aliasgroup2=https://wjhcloud.wjknh.de:443).
  2. In der zweiten Nextcloud die gemeinsame Office-Domain eintragen: occ config:app:set richdocuments wopi_url auf die geteilte Collabora-URL (Referenz: office.wj-konstanz-hegau.de), danach occ richdocuments:activate-config.
  3. Nach dem Container-Recreate die Haupt-Instanz verifizieren, denn der Recreate trifft beide Mieter.

Wichtig für die Einordnung: Das Mitnutzungs-Pattern ist für die Demo- und Anlaufphase gedacht. Sobald ein Kreis produktiv mit echten Mitgliederdaten arbeitet, gehört er auf einen eigenen Server mit eigener Collabora-Instanz (DSGVO-Trennung der Vereine, siehe Kapitel Rollout-Runbook).

3.2 Talk: der WhatsApp-Ersatz für Internes

Wozu Talk, wenn es WhatsApp gibt

WhatsApp bleibt in der Praxis der Kanal, auf dem alle Mitglieder erreichbar sind. Der Standard versucht nicht, das zu verleugnen. Talk (App spreed, Referenz: Version 24.0.3) besetzt die Rolle daneben: der Kanal für alles, was nicht auf Privatgeräte von Meta gehört. Das sind vor allem drei Dinge:

  1. Gremien-Kommunikation. Vorstands- und Arbeitskreis-Räume mit Bezug auf die Dateien, über die gerade gesprochen wird. Bewährtes Muster der Referenz: Gremien-Räume mit Einzeluser-Einladungen statt Gruppen-Einladungen anlegen. Wer später einer AK-Gruppe beitritt, landet dadurch nicht automatisch im Gremien-Raum; die Raumleitung behält die Kontrolle über den Teilnehmerkreis.
  2. Videokonferenzen. Vorstandssitzungen und AK-Calls laufen auf der eigenen Domain statt über Zoom oder Teams, ohne Account-Zwang für Gäste (Gast-Links).
  3. Bot-Kanal der Automatisierung. Auf der Referenz ist Talk der Push-Kanal des n8n-Kuriers "Flow": Event-Reminder, Foto-Drop-Links und der Montags-Digest kommen als Talk-Nachricht an eine verantwortliche Person, oft mit vorbereitetem wa.me-Link. Ein Mensch reicht die Nachricht per Tap in die WhatsApp-Gruppe weiter. So bleibt der Mensch im Loop und die ToS-Grauzone einer WhatsApp-Vollautomation wird vermieden (Details im Kapitel Flow).

Talk-Räume lassen sich geskriptet anlegen (occ talk:room:create, im Phase-2-Setup-Script der Referenz). Achtung: Dieser Script-Teil ist nicht idempotent, ein erneuter Lauf erzeugt Duplikat-Räume.

Grenzen

Talk ersetzt WhatsApp für die interne Arbeit, nicht für die Mitglieder-Breitenkommunikation. Wer erwartet, dass gut 160 Mitglieder freiwillig eine zweite Chat-App installieren, wird enttäuscht; die Referenz plant Talk deshalb bewusst als Werkzeug für Vorstand, Ressorts und Automation, während die Mitglieder-Reichweite über die bestehenden Kanäle läuft. Und: Ohne die nächste Komponente, das HPB, bleibt Talk bei Videokonferenzen ein Werkzeug für sehr kleine Runden.

3.3 Das High-Performance-Backend (HPB)

Wann ihr es braucht

Ohne HPB verbinden sich Talk-Teilnehmende direkt untereinander (Peer-to-Peer). Das funktioniert für Zweiergespräche und kleine Runden, skaliert aber quadratisch: Jeder sendet sein Video an jeden. Als Richtwert gilt: ab etwa 4 Video-Teilnehmenden braucht ihr das HPB, sonst brechen Verbindungen ein und Laptops glühen. Für einen WJ-Kreis, dessen Vorstand allein meist mehr als vier Personen hat, ist das HPB darum kein optionales Extra, sondern Teil des Standard-Kerns: Ohne HPB ist "Vorstandssitzung per Talk" ein leeres Versprechen.

Das HPB besteht aus einem Signaling-Server (koordiniert, wer mit wem spricht) und einer Media-Bridge, die die Videoströme bündelt: Jeder sendet nur noch einmal an den Server.

Aufbau auf der Referenz

Die Referenz nutzt das aio-talk-Container-Image (ghcr.io/nextcloud-releases/aio-talk:latest), das Signaling, Media-Bridge und TURN-Server in einem Container bündelt. Port-Muster wie überall: Signaling auf 127.0.0.1:8081 hinter dem Apache-Proxy (/standalone-signaling/ als WebSocket-Proxy auf ws://127.0.0.1:8081/), nur TURN/STUN liegt mit Port 3478 (tcp und udp) direkt im Netz, weil TURN genau dafür da ist. In Nextcloud eingetragen ist der Signaling-Server als https://hafen.wj-konstanz-hegau.de/standalone-signaling/ mit aktivierter Verifikation.

Ein Apache-Detail, das beim Nachbau gern kostet: Der WebSocket-Proxy für /standalone-signaling/ muss VOR einem generischen ProxyPass / stehen, Apache matcht in Definitionsreihenfolge.

Multi-Tenant-Overlay: ein HPB für mehrere Kreise

Wie Collabora kann auch das HPB mehrere Nextcloud-Instanzen bedienen, die zugrunde liegende Signaling-Software (nextcloud-spreed-signaling) unterstützt beliebig viele [backend-N]-Sektionen. Das Hindernis ist das aio-talk-Image selbst: Sein Startskript /start.sh generiert die Signaling-Konfiguration bei jedem Start neu und kennt dabei nur eine einzige Domain. Config-Änderungen im laufenden Container überleben deshalb keinen Neustart.

Der funktionierende Ansatz (Blueprint im Infra-Vault, live auf der Referenz seit 2026-08-13, Script hpb-shared.sh im Repo):

  1. /start.sh aus dem Container extrahieren und patchen: backends = backend-1, backend-2 sowie eine [backend-2]-Sektion mit der URL der zweiten Nextcloud und secret = ${SIGNALING_SECRET} (die Env-Referenz expandiert beim Container-Start, der Klartext-Wert bleibt im serverseitigen Env-File).
  2. Container neu erstellen mit dem gepatchten Skript als read-only Bind-Mount (-v <pfad>/hpb-start.sh:/start.sh:ro); das Env-File aus dem alten Container übernehmen, damit Secrets serverseitig bleiben und nie durch eine Session oder ein Repo wandern.
  3. Reverse-Proxy der zweiten Domain um den Signaling-WebSocket-Pfad ergänzen (Reihenfolge-Regel von oben beachten).
  4. Zweite Nextcloud anbinden: occ talk:signaling:add wss://<domain2>/standalone-signaling <SIGNALING_SECRET> --verify.
  5. Beide Endpoints per curl auf /standalone-signaling/api/v1/welcome verifizieren.

Rollback ist eingebaut: Container ohne den Mount neu erstellen, dann läuft wieder das Original-Startskript (auf der Referenz zusätzlich als hpb-start-orig.sh gesichert). Die Merkregel hinter dem Muster gilt über diesen Fall hinaus: Generiert ein Container seine Config im Entrypoint aus Umgebungsvariablen, patcht man den Entrypoint per read-only Bind-Mount, nicht die generierte Config.

Drei Punkte für den Betrieb des Overlays:

Auch hier gilt die Collabora-Einordnung: geteiltes HPB für Demo- und Anlaufphase, eigener Kreis-Server mit eigenem HPB für den Produktivbetrieb.

TURN und STUN

TURN löst das Problem, das Videokonferenzen in Firmennetzen und Mobilfunknetzen sonst zuverlässig killt: Teilnehmende hinter restriktiven Firewalls oder NAT bekommen keine direkte Medienverbindung. Der TURN-Server relayt die Medienströme dann über Port 3478. Auf der Referenz läuft TURN/STUN im selben aio-talk-Container (turn: hafen.wj-konstanz-hegau.de:3478, Protokolle udp und tcp; STUN auf demselben Endpoint).

Die gute Nachricht für das Multi-Tenant-Setup: TURN braucht vom Overlay nichts. Die Shared-Secret-Authentifizierung ist domain-agnostisch, jede weitere Nextcloud wird schlicht per occ talk:turn:add turn <host>:3478 udp,tcp --secret=<TURN_SECRET> angebunden.

3.4 Anruf-Aufnahme und -Transkription (geplanter Baustein)

Vorstandssitzung aufzeichnen, Transkript erhalten, daraus das Protokoll bauen: Das ist die Ausbaustufe, die den Zeitgewinn der Digitalisierung für Ehrenamtliche am direktesten spürbar macht. Aktuelles Nextcloud Talk bringt die Funktion mit, sie besteht aus zwei Teilen, die beide auf dem eigenen Server laufen.

Wichtig für den Fakten-Check: Auf der Referenz-Installation KNH ist dieser Baustein Stand 2026-08-13 NICHT aktiv. Dieser Abschnitt beschreibt den geplanten Baustein des Standards, nicht den Ist-Zustand der Referenz. Die RAM-Konsequenz (siehe unten) ist der Grund, warum die Referenz ihn noch nicht fährt.

Die zwei Komponenten

  1. Talk-Recording-Backend. Ein eigener Dienst neben dem HPB (nicht Teil des aio-talk-Containers der Referenz), der als unsichtbarer Teilnehmer den Call mitschneidet und die Aufnahme als Datei in der Nextcloud der Person ablegt, die die Aufnahme gestartet hat. Er wird in Talk analog zum Signaling-Server mit URL und Shared Secret registriert.
  2. Speech-to-Text-Provider in Nextcloud. Nextcloud kennt STT als austauschbaren Provider (App bzw. ExApp). Ist ein Provider registriert, kann Talk Aufnahmen transkribieren und Transkripte beziehungsweise Zusammenfassungen zu Calls liefern.

Standard-Empfehlung: lokales Whisper, kein Cloud-STT

Der Standard empfiehlt als STT-Provider ausdrücklich ein LOKAL laufendes Whisper-Modell (als Nextcloud-STT-App/ExApp auf dem eigenen Server). Das ist keine Geschmacksfrage, sondern DAS Datenschutz-Argument dieses Standards: Gesprächs-Audio einer Vorstandssitzung ist mit das Sensibelste, was ein Kreis digital produziert. Mit lokalem Whisper verlässt dieses Audio nie den eigenen Server. Ein US-Cloud-STT-Dienst an dieser Stelle würde das Souveränitäts-Versprechen des gesamten Standards ("eure Daten liegen bei euch") an seiner empfindlichsten Stelle brechen. Auch die naheliegende Abkürzung über eine externe Inference-API scheidet aus; für die Referenz-Umgebung ist dokumentiert, dass die dort verfügbare Hetzner-Inference-API kein Audio verarbeitet und externe STT-APIs dem Souveränitäts-Versprechen widersprechen.

Hardware ehrlich benennen

Recording-Backend plus lokales Whisper kosten spürbar Ressourcen: Als Richtwert solltet ihr ab etwa 8 GB zusätzlichem RAM für den kombinierten Recording- und Whisper-Betrieb planen, dazu Plattenplatz für die Aufnahmen. Die Konsequenz für die Architektur ist eindeutig und im Replika-Wissen der Referenz so festgehalten: Dieser Baustein gehört auf den EIGENEN Server eines Kreises, nicht auf geteilte Paten-Instanzen. Die Referenz-Maschine ist nach dem Aufbau der Demo-Replika mit rund 2,7 GB freiem RAM voll belegt; genau deshalb ist Recording dort ein geplanter Baustein und kein Live-Feature. Wer Recording will, dimensioniert den Kreis-Server von Anfang an entsprechend größer oder rüstet nach.

DSGVO und Transparenz

Eine Aufnahme ist eine Verarbeitung personenbezogener Daten und braucht die Einwilligung der Teilnehmenden. Praktisch heißt das: Zu Beginn der Sitzung ankündigen und Widerspruch ermöglichen, bei Gästen explizit fragen, den Zweck benennen (Protokollerstellung) und Aufnahmen nach Erstellung des Protokolls löschen statt zu horten. Talk unterstützt euch dabei, weil die laufende Aufnahme für alle Teilnehmenden sichtbar angezeigt wird; heimliches Mitschneiden ist im Werkzeug nicht vorgesehen. Nehmt den Umgang mit Aufnahmen (wer darf starten, wo liegen sie, wann werden sie gelöscht) in die Datenschutz-Unterlagen des Kreises auf, bevor ihr die Funktion aktiviert.

Ehrliche Grenzen

Whisper-Transkripte sind gut, aber nicht fehlerfrei: Fachbegriffe, Namen und Dialekt werden verstolpert, Sprecherzuordnung ist nicht die Stärke des Ansatzes. Das Transkript ist Rohstoff für das Protokoll, nicht das Protokoll. Und auf einem CPU-Server dauert die Transkription einer längeren Sitzung entsprechend; plant sie als Hintergrund-Job nach der Sitzung ein, nicht als Live-Untertitel.

Checkliste

Collabora:

Talk und HPB:

Recording und Transkription (nur eigener Kreis-Server):

Referenz KNH

So läuft es bei Konstanz-Hegau konkret (Stand 2026-08-13):

← 02 Nextcloud-BasisWeiter: 04 VereinOnline →