FEDEO/docs/chat-foederation-konzept.md

Konzept: Föderierte Chats und externe Projektteilnehmer

Stand: 26. September 2026. Status: Architekturvorschlag auf Basis des FEDEO-Codes bei Commit df48c976. Dieses Dokument beschreibt ein Zielbild; Föderation, Gastzugang und die genannten APIs sind noch nicht implementiert. Es wurden keine Einladungen verschickt und keine laufenden Instanzen verändert.

1. Empfehlung

FEDEO erhält eine gemeinsame Berechtigungsschicht für die Zusammenarbeit über Mandantengrenzen hinweg und einen darauf aufbauenden Transport zwischen FEDEO-Instanzen. Benutzer bleiben bei ihrer eigenen Instanz angemeldet. Ein Chat beziehungsweise Projekt hat genau einen verantwortlichen Mandanten und eine führende Instanz, die Mitgliedschaften, Freigaben und Änderungen verbindlich entscheidet.

Die gleiche Funktion soll drei Fälle abdecken:

Fall	Verhalten
Zwei Mandanten derselben Instanz	Explizite Einladung und dieselben objektbezogenen Rechte; Aufruf intern ohne Netzwerktransport
Mandanten verschiedener FEDEO-Instanzen	Gleiche Oberfläche; signierter Austausch zwischen den Backends
Person ohne FEDEO-Konto	Optionale zweite Ausbaustufe: eingeschränkter Gastzugang beim Projekteigentümer

Eine Einladung macht einen externen Benutzer nicht zum regulären Benutzer des einladenden Mandanten. Chatteilnahme und Zugriff auf Projektdaten sind getrennte Freigaben. Eine freigegebene Partnerinstanz erhält ebenfalls keine pauschalen Rechte auf einen Mandanten.

Der Vorschlag ist eine Föderation zwischen FEDEO-Instanzen mit zentraler Zuständigkeit je Ressource. Er bietet keine automatische Interoperabilität mit Matrix, Teams oder anderen Messengern und keine gleichberechtigten Schreibkopien auf allen Instanzen.

2. Nutzerabläufe

Gemeinsamen Chat eröffnen

1. Benutzer wählt Kommunikation → Neuer Chat → Externe Teilnehmer.
2. Er wählt einen bekannten Partnerkontakt oder fügt eine FEDEO-Kontaktadresse hinzu. Vor dem Absenden werden Person, Mandant und Instanz angezeigt.
3. Er bestimmt ausdrücklich die internen und externen Teilnehmer. Die Auswahl einer Firma fügt nicht automatisch deren gesamte Belegschaft hinzu.
4. Empfänger sieht eine Anfrage in seiner eigenen FEDEO-Instanz und nimmt sie im eingeladenen Mandantenkontext an.
5. Nach Bestätigung durch die führende Instanz erscheint derselbe gemeinsame Chat auf beiden Seiten, mit Kennzeichnung des verantwortlichen Mandanten und der externen Teilnehmer.

Ein Partnerkontakt ist lediglich eine wiederverwendbare Adresse. Er berechtigt weder zum Zugriff auf andere Chats noch zur Suche im vollständigen Benutzerverzeichnis der Partnerfirma. Unbekannte Absender landen in einer begrenzten Anfrageansicht; Benutzer und Mandanten können Kontakte blockieren.

Externe Person zu einem Projekt einladen

1. Projektverantwortlicher öffnet Projekt → Zusammenarbeit → Person einladen.
2. Er wählt Person, Rolle, gegebenenfalls Ablaufdatum und die konkret freigegebenen Inhalte.
3. Standard ist ein neuer Partnerchat mit eigenem Teilnehmerkreis. Der bisherige interne Projektchat bleibt intern. Für zwei Subunternehmer können getrennte Partnerchats entstehen; ein gemeinsamer Chat aller Firmen wird ausdrücklich angelegt.
4. Optional werden eine externe Projektübersicht und einzelne Dokumente freigegeben. Die Vorschau zeigt exakt, was der Empfänger sehen wird.
5. Nach Annahme findet der Empfänger das Projekt unter Projekte → Mit mir geteilt. Die Oberfläche zeigt die freigegebenen Inhalte und den Partnerchat, ohne Wechsel in den fremden Mandanten.
6. Verantwortliche können Teilnahme und Freigaben später einschränken, befristen oder entziehen. Chat und Projektübersicht zeigen deren aktuellen Status.

Beispiel: Ein Elektrofachbetrieb lädt einen Mitarbeiter des Gerüstbauers in das Projekt „Schulgebäude“ ein. Dieser erhält den Partnerchat, den freigegebenen Ausführungstermin und einen Lageplan. Angebote, Einkaufspreise, interne Notizen und andere Projekte bleiben verborgen.

3. Ausgangslage im Code

Bestand	Bedeutung für den Entwurf
communication_rooms	Räume gehören bisher genau einem lokalen Mandanten; key ist nur innerhalb dieses Mandanten eindeutig.
communication_room_members	Mitglieder referenzieren lokale auth_users; es fehlen Herkunftsmandant, externe Identität, Rolle und Widerrufszustand.
communication_messages, communication_room_reads	Autoren und Lesestatus sind lokale Benutzer; numerische Nachrichten-IDs taugen nicht als instanzübergreifende Identität.
projects	profiles enthält lokale Mitarbeiterprofile; externe Zusammenarbeit braucht eigene Freigaben statt fremder Mitarbeiterprofile.
auth.ts, resources/main.ts	Anmeldung und Ressourcenabfragen arbeiten mit dem aktiven lokalen Mandanten. Externe Rechte dürfen diese allgemeine Mandantengrenze nicht aufweichen.
communication.ts	Raumzugriff ist an den aktiven Mandanten gebunden; Benachrichtigungsempfänger stammen aus dessen Benutzerverzeichnis. Beides benötigt eine explizite Zusammenarbeitsschicht.

Vor einer Freigabe sind zwei vorhandene Verhaltensweisen zu korrigieren: Das Anlegen eines Raums mit bestehendem Schlüssel darf keine zusätzlichen Mitglieder in einen fremden Raum aufnehmen. Außerdem darf das Bereitstellen eines Projektchats nicht allein durch Kenntnis einer Projekt-ID zur Selbstaufnahme führen. Einladungen, Beitritt und das Lesen von Projektdaten benötigen jeweils eine objektbezogene Prüfung.

4. Zuständigkeit und Datenfluss

flowchart LR
    UA[Benutzer A] --> A[FEDEO A: Anmeldung und Berechtigungen]
    UB[Benutzer B] --> B[FEDEO B: Anmeldung und Berechtigungen]
    A --> O[(Projekt und Chat bei Eigentümer A)]
    B --> P[(Freigegebene Chatkopie für Mandant B)]
    B -->|Signierte Befehle und Projektabfragen| A
    A -->|Bestätigte Ereignisse und freigegebene Ansichten| B

• Ein gemeinsam genutzter Chat hat einen Eigentümer und eine feste führende Instanz. Projektchats werden beim Projekteigentümer geführt. Ein freier Partnerchat wird beim Ersteller geführt; das wird vor Annahme angezeigt.
• Die führende Instanz prüft jeden Schreibbefehl und vergibt dessen verbindliche Reihenfolge. Partnerinstanzen dürfen bestätigte Chatereignisse für ihre ausdrücklich berechtigten lokalen Teilnehmer speichern.
• Projektdaten bleiben beim Eigentümer. Die Partnerinstanz fragt eine eingeschränkte Ansicht an; es gibt keine Replikation der vollständigen projects-, Kunden- oder Belegtabellen.
• Jede Partnerinstanz übernimmt Anmeldung, lokale Benutzeroberfläche, Lesestatus und Benachrichtigungen ihrer eigenen Benutzer. Zugangstoken der Benutzer verlassen die eigene Instanz nicht.
• Mehrere Mandanten auf derselben Instanz durchlaufen denselben Berechtigungsdienst. Die Optimierung zum internen Aufruf darf keine zusätzlichen Rechte schaffen.

Die Entscheidung für eine führende Instanz vereinfacht Reihenfolge, Rollenwechsel und Widerruf. Sie hat einen bewussten Nachteil: Ist diese Instanz ausgefallen, können neue Nachrichten nur als ausstehend vorgemerkt werden; neue Projektabfragen und Freigaben sind nicht möglich. Bereits rechtmäßig empfangene Chatnachrichten können entsprechend der Aufbewahrungsregel weiter angezeigt werden. Es gibt in Version 1 keine automatische Übernahme durch eine andere Instanz.

5. Identitäten und Vertrauen

Eine Person handelt immer in einem konkreten Organisationskontext. Der gleiche lokale Benutzer in zwei Mandanten hat deshalb zwei getrennte Teilnehmeridentitäten.

Identität	Vorgabe
Instanz	Dauerhafte öffentliche UUID, kanonische HTTPS-Adresse und eigene Signaturschlüssel
Mandant	Dauerhafte öffentliche UUID plus Instanzidentität; lokale numerische ID bleibt intern
Teilnehmer / Principal	Kombination aus Instanz-, Mandanten- und öffentlicher Benutzer-ID
Ressource	Dauerhafte öffentliche UUID plus führende Instanz; z. B. Chat oder freigegebene Projektansicht
Nachricht / Ereignis	Globale UUID; zusätzlich fortlaufende Sequenz innerhalb des führenden Chats

Als Kontaktadresse kann eine kanonische HTTPS-Adresse dienen, beispielsweise https://partner.example/federation/actors/<opaque-id>. Anzeigenamen und E-Mail-Adressen sind veränderbare Attribute, keine Identitätsschlüssel. Gleichlautende E-Mail-Adressen auf zwei Instanzen führen nicht zu einer automatischen Zusammenführung. Öffentlich abrufbare Adressen dürfen keine offenen Mitarbeiterlisten ergeben.

Eine eigene Discovery-Datei /.well-known/fedeo-federation veröffentlicht Protokollversion, Instanz-ID, HTTPS-Endpunkt und öffentliche Schlüssel. Dieser Pfad ist ein FEDEO-eigener Vorschlag. Beim Erstkontakt werden HTTPS-Herkunft, Kontrolle des Endpunkts durch eine signierte Challenge und die Freigabe des Partners geprüft. Discovery allein verleiht kein Vertrauen.

Für Version 1 gilt eine Partner-Allowlist je Mandant innerhalb der vom Betreiber erlaubten Instanzen. Empfänger nehmen Anfragen zusätzlich selbst an. Eine bestätigte Transportverbindung ersetzt keine Raum- oder Projektfreigabe. Eine Partnerinstanz darf ausschließlich Identitäten ihrer eigenen Herkunft bestätigen; jeder Zugriff wird auf eine konkret eingeladene Kombination aus Instanz, Mandant und Benutzer begrenzt.

Das Vertrauensmodell setzt voraus, dass die Heimatinstanz ihre Benutzer korrekt authentifiziert. Ein kompromittierter Partneradministrator könnte im Namen dieser Benutzer handeln. Instanzsignaturen belegen den Absender-Server, nicht die persönliche Unterschrift des Menschen. Deshalb können Betreiber und Mandanten Partner sofort sperren; für höhere Anforderungen wäre später eine zusätzliche benutzergebundene Signatur nötig.

Schlüssel werden getrennt von JWT-, Push- und sonstigen API-Secrets verwaltet. Rotation erfolgt mit überlappend veröffentlichten Schlüsseln und Nachweis durch den bereits vertrauten Schlüssel; Verlust oder Kompromittierung verlangt eine explizite erneute Vertrauensprüfung. Domainwechsel benötigen einen dokumentierten Identitätsumzug. Ein Datenbankklon für Test oder Restore darf nicht parallel als dieselbe Instanz senden; vor Freischaltung sind Instanzidentität, Worker und Schlüssel zu prüfen.

6. Berechtigungen und Sichtbarkeit

Alle externen Rechte entstehen aus einer vom Eigentümer gespeicherten Freigabe: resource + principal + role/scopes + status + revision + expires_at. Wir prüfen zusätzlich die lokale Mitgliedschaft im Heimatmandanten, dessen Partnerregeln und die Sperrzustände beider Seiten. Rollen der fremden Instanz werden niemals zu lokalen Administratorrechten übersetzt.

Rolle	Erlaubte Fähigkeiten	Ausdrücklich nicht enthalten
Chatteilnehmer	Den freigegebenen Chat ab Beitritt lesen, Nachrichten senden, eigene Lesemarke setzen	Projektdaten, andere Räume, Teilnehmer einladen
Projektleser	Freigegebene Projektübersicht und einzeln freigegebene Dateien lesen	Vollständiges Projektobjekt, interne Notizen, Kundenakte, Belege
Projektmitarbeiter	Projektleser; später zusätzlich ausdrücklich zugewiesene Aufgaben oder freigegebene Rückmeldungen bearbeiten	Allgemeines Projekt-Schreibrecht, Kalkulation, Rollenverwaltung
Projektverantwortlicher	Auf Eigentümerseite Teilnehmer und Freigaben verwalten, soweit intern autorisiert	Automatische Rechte in Partnerorganisationen

Die Rollen sind Vorlagen für konkrete Rechte. Projektlesen erzeugt keine Chatmitgliedschaft und Chatmitgliedschaft keine Projektfreigabe; der Einladungsdialog kann beide bewusst bündeln. Version 1 umfasst Textchat und eine lesbare Projektübersicht. Datei- und Aufgabenrechte werden erst angeboten, wenn die jeweiligen Prüfungen umgesetzt sind.

Die externe Projektübersicht verwendet eine Positivliste freigegebener Felder, etwa Anzeigename, vereinbarter Status und freigegebene Termine. Weder das komplette Projektobjekt noch eingebettete Beschreibungen, notes, material, forms, Kundenverknüpfungen oder Änderungsprotokolle werden ungeprüft ausgegeben. Eine neue interne Spalte wird dadurch nicht automatisch extern sichtbar. Auch Suche, Vorschaubilder, Zähler, Exporte und Benachrichtigungen müssen denselben Umfang einhalten.

Standard für externe Teilnehmer ist history_from_seq = Beitrittssequenz. Frühere interne Nachrichten werden nicht nachträglich freigegeben. Neue Mitglieder sehen nur die für sie zulässige Historie; erneute Einladung ist eine neue Freigabe mit neuem Beginn. Bei Einführung von Antworten, Reaktionen oder Bearbeitungen dürfen Referenzen keine zuvor unsichtbaren Nachrichten offenlegen. Die Teilnehmerliste eines Partnerchats zeigt die beteiligten Identitäten und Organisationen; darüber werden Einladende und Empfänger informiert.

7. Einladung und Entzug

Zustände: pending → accepted | declined | expired | revoked. accepted entsteht ausschließlich durch eine atomare Entscheidung beim Eigentümer; danach können die daraus entstandenen Freigaben unabhängig widerrufen oder eingeschränkt werden. Der Verlauf bleibt im Audit nachvollziehbar.

1. Eigentümer prüft die Einladungsberechtigung und legt Empfängeridentität, Ressourcen, Rechte, Historienbeginn, Ablauf und eine unveränderliche Angebotsrevision fest.
2. Heimatinstanz des Empfängers zeigt die Anfrage nach Anmeldung im betreffenden Mandanten. Beim Annehmen bestätigt sie signiert Identität, Einladung und Angebotsrevision. Die Zustimmung bezieht sich auf genau diesen Umfang.
3. Eigentümer prüft Ablauf, Sperren, fortbestehende Rechte des Einladenden und die Identität erneut. Freigaben und Bestätigungsereignis werden in einer Transaktion erstellt. Wiederholte Annahme liefert dasselbe Ergebnis, keine zweite Mitgliedschaft.
4. Beide Oberflächen zeigen erst nach Bestätigung Aktiv. Eine Änderung des Angebots vor Annahme erfordert erneute Zustimmung.
5. Widerruf setzt den Zustand beim Eigentümer und erhöht die Berechtigungsrevision. Neue Befehle, Downloads und noch nicht versandte Inhaltszustellungen prüfen diesen Zustand erneut. Alte Annahmeereignisse oder Befehle dürfen eine entzogene Freigabe nicht reaktivieren.

Für Einladungen per Link gilt: einmaliges zufälliges Geheimnis, nur gehasht gespeichert, befristet und beim Einlösen atomar verbraucht. Ein Link allein ist kein Projektschlüssel. Die Annahme benötigt eine authentifizierte Empfängeridentität. Ist diese bei Erstellung noch unbekannt, wird sie nach Anmeldung dem Einladenden zur Bestätigung angezeigt; bis dahin werden keine Projektinhalte freigegeben. Tokens dürfen nicht in Zugriffslogs oder Referrer gelangen; Einlöseseite ohne Drittinhalte und Übergabe des Geheimnisses per POST.

Das Entfernen eines Mitarbeiters aus seinem Heimatmandanten sperrt dessen lokale Zusammenarbeit sofort; die Heimatinstanz meldet die Deaktivierung an die Eigentümer. Beim nächsten Befehl wird die lokale Mitgliedschaft ohnehin erneut geprüft. Es erfolgt keine stillschweigende Übertragung auf einen Nachfolger oder einen anderen Mandanten derselben Person.

Ein Entzug stoppt die weitere autorisierte Nutzung beim Eigentümer. Bereits ausgelieferte beziehungsweise bereits unterwegs befindliche Daten lassen sich nicht sicher zurückholen. Eine Partnerinstanz kann vor Eingang des Widerrufs noch ihre bisherige Chatkopie anzeigen; ein fremder Betreiber kann Kopien behalten. Die Software übernimmt Widerrufe, beendet Synchronisation und entfernt lokale Zugriffe nach Richtlinie, verspricht aber kein nachträgliches Löschen sämtlicher Kopien. Neue Projektabfragen und Dateiabrufe müssen den Eigentümer erreichen und bei Ausfall geschlossen scheitern.

8. Transport und Synchronisation

Browser und Mobile-App sprechen nur mit ihrer eigenen FEDEO-Instanz. Deren Backend übersetzt lokale Aktionen in geprüfte Föderationsbefehle. Föderationsrouten erhalten eine eigene Authentifizierung; sie dürfen fremde Signaturen nicht in reguläre lokale Benutzer-JWTs oder einen frei wählbaren tenant_id umwandeln.

Für Transportauthentifizierung wird ein festes FEDEO-Profil auf Basis von HTTP Message Signatures, RFC 9421 und Content-Digest, RFC 9530 vorgeschlagen, mit Ed25519 als festgelegtem Signaturalgorithmus. Es signiert Methode, Ziel-URI, Inhaltstyp und Inhaltsdigest sowie Schlüssel-ID, Erstellungszeit, Ablauf und Nonce. Die konkrete Implementierung muss Referenztestvektoren bestehen; Zeitfenster und abgedeckte Komponenten sind verpflichtend. Der Digest wird gegen die tatsächlichen Body-Bytes geprüft. TLS bleibt obligatorisch. Signaturen sind keine Ende-zu-Ende-Verschlüsselung.

FEDEO-spezifisch wird jede Nachricht an Zielinstanz, handelnden Principal, Eigentümerressource, Freigabe-ID und Revision gebunden. Der Empfänger prüft diese Bindungen zusätzlich zur Signatur. Ein gültig signierter Auftrag für Mandant B darf weder für Mandant C noch für eine andere Ressource wiederverwendet werden. Unbekannte Ereignistypen oder nicht unterstützte Pflichtmerkmale werden abgelehnt; es gibt keine stille Herabstufung von Sicherheitsregeln.

Verarbeitung einer Nachricht

1. Benutzer sendet mit einer stabilen Client-Auftrags-ID an seine Heimatinstanz. Diese prüft Sitzung, aktiven Mandanten und Freigabe und speichert den Auftrag dauerhaft als pending.
2. Eigentümer erhält den signierten Befehl. Unter derselben Transaktionssperre wie Mitgliedschaftsänderungen prüft er die aktuell wirksame Freigabe, vergibt Nachrichten-UUID und nächste Raumsequenz und speichert Nachricht, Befehlsresultat und Outbox-Einträge atomar.
3. Ein Worker stellt die bestätigten Ereignisse den berechtigten Heimatinstanzen zu. Vor jedem Versand prüft er die aktuellen Empfängerrechte; er verschickt keine ungefilterte Raumhistorie oder vollständigen internen Raumzustände.
4. Empfangsinstanz speichert Ereignis und Empfangsbestätigung dauerhaft und dedupliziert anhand der Ereignis-ID. Erst die Eigentümerbestätigung ändert die UI-Anzeige von Ausstehend zu Gesendet; die serverseitige Annahme beim Empfänger bedeutet noch nicht, dass ein Mensch gelesen hat.
5. Die Empfangsinstanz aktualisiert ihre Chatansicht und erzeugt höchstens eine lokale Benachrichtigung pro berechtigtem Empfänger und Ereignis.

Zustellung erfolgt mindestens einmal; Eindeutigkeit entsteht durch persistente Deduplizierung. Ein wiederholter Befehl mit derselben ID und demselben Inhalt liefert das gespeicherte Ergebnis. Dieselbe ID mit anderem Inhalt wird abgelehnt. Retries erhalten eine neue HTTP-Nonce und Signatur, behalten aber Befehls-/Ereignis-ID. So werden Transport-Replays abgewehrt, ohne legitime Wiederholung nach Timeout zu blockieren.

Raumsequenzen bestimmen die Reihenfolge, nicht Uhren verschiedener Server. Empfangsbestätigungen und Nachladen verwenden Cursor für den empfängerbezogenen Ereignisstrom; ausgelassene, nicht berechtigte Raumereignisse erzeugen keine fälschlich endlosen Lücken. Mitgliedschaftsrevisionen werden monoton verarbeitet. Eine verspätete alte Einladung überschreibt keinen neueren Widerruf. Inhalte werden nur an die im Zustellumschlag ausdrücklich berechtigten Principals des Zielmandanten gebunden; lokale Kopien werden nicht für andere Benutzer desselben Servers freigegeben.

Outbox und Inbox werden in PostgreSQL gespeichert. Ein Worker mit begrenzter Parallelität, exponentiellem Backoff und Jitter übernimmt Retries; dauerhafte Fehler werden sichtbar abgelegt. Empfangsbestätigung erfolgt erst nach dauerhafter Speicherung. Nach Ausfall werden berechtigte Änderungen per Cursor nachgeholt; bei abgelaufenem Cursor liefert der Eigentümer einen erneut gefilterten Snapshot mit aktueller Freigaberevision. Ein Restore erfordert vor Wiederaufnahme eine Reconciliation, damit alte Backups keine widerrufenen Mitgliedschaften wieder aktivieren.

Beim Restore startet der Föderationsbetrieb gesperrt. Kann der zuvor bestätigte Ereignis- und Widerrufsstand nicht lückenlos wiederhergestellt werden, bleiben alte externe Freigaben suspendiert und werden durch neue Einladungen ersetzt. Eine mit den Partnern bestätigte neue Wiederherstellungsgeneration entwertet alte ausstehende Befehle; Sequenzen dürfen nicht stillschweigend zurückgesetzt werden. Die Fortsetzung aus einem veralteten Backup ist damit keine automatische Wiederfreigabe.

9. Vorgeschlagenes Datenmodell und API-Grenzen

Die Namen sind Entwurfsvorgaben für additive Migrationen, keine fertigen Tabellen oder Endpunkte.

Baustein	Wesentliche Daten und Regeln
federation_instances, Schlüssel und Partnerregeln	Globale Instanz-ID, verifizierte Herkunft, öffentliche Schlüssel, Vertrauenszustand; Freigaben/Sperren separat je lokalem Mandanten
collaboration_principals	Herkunftsinstanz, öffentliche Mandanten-/Benutzer-ID, optional lokale Benutzerzuordnung; eindeutiger Herkunftsdreier; fremde Profile nur minimal speichern
collaboration_resources	Globale Ressourcen-ID, Art, Eigentümerinstanz/-mandant, optional Verweis auf lokalen Chat oder lokales Projekt
collaboration_bindings	Ressource plus empfangender lokaler Mandant; trennt lokale Spiegel desselben Raums und enthält den Synchronisationscursor
collaboration_grants	Ressource, Principal, Rolle/Scopes, Status, Revision, Historienbeginn, Ablauf, Ersteller; einzelne Freigaben bleiben widerrufbar
collaboration_invitations	Empfängerbindung, Angebotsrevision, angefragte Freigaben, Tokenhash soweit nötig, Zustand und Ablauf
Föderationsereignisse, Inbox, Outbox, Befehlsresultate	Globale IDs, Raumsequenz, Empfänger-/Mandantenbindung, Idempotenz, Zustellzustand und nächste Wiederholung
Nachrichtenergänzungen und Lesestatus	Nachrichten-UUID, Principal als Autor, Sequenz; Lesemarken je Principal/Binding; lokale Autor-IDs während Migration kompatibel halten
Audit	Einladung, Annahme, Rechteänderung, Widerruf, Partner-/Schlüsseländerung mit verantwortlichem Principal und Zeit; keine Tokens oder vollständigen Chattexte

Fremde Benutzer bekommen keinen künstlichen Eintrag mit Passwort in auth_users und keine Mitgliedschaft in auth_tenant_users. Beim Eigentümer darf eine externe Autoridentität deshalb nicht weiterhin einen obligatorischen lokalen author_user_id voraussetzen. Bestehende lokale Nachrichten behalten ihre Autorenverknüpfung; ein neuer Principal-Verweis ergänzt sie. Für lokale Teilnehmer wird der Principal mandantenspezifisch aufgebaut.

communication_rooms.tenantId bleibt der lokale Eigentümermandant. Fremd geführte Räume erhalten einen getrennten lokalen Binding-/Projektionsdatensatz statt eines vorgetäuschten lokalen Eigentümers. Datenbankconstraints sichern lokale Ressourcenverweise gegen einen anderen Mandanten ab. Globale Identitäten und Autorenschaft werden nicht aus frei eingereichten numerischen IDs abgeleitet.

API-Bereich	Zweck und Grenze
/.well-known/fedeo-federation	Öffentliche technische Discovery ohne Benutzer-, Raum- oder Projektverzeichnis
/federation/v1/commands	Signierte Befehle an die führende Instanz; Fachberechtigungen bleiben zwingend
/federation/v1/inbox	Bestätigte Ereignisse nur vom zuständigen Eigentümer; feste Empfängerbindung
/federation/v1/sync	Berechtigtes Nachholen; kein frei lesbares globales Ereignisprotokoll
/federation/v1/shared-projects/...	Signierte, principalgebundene Abfrage explizit freigegebener Projektfelder
/api/collaboration/...	Lokale Benutzeroberfläche für Partner, Einladungen, Chats und geteilte Projekte; lokale Anmeldung plus objektbezogene Prüfung

Ein zentraler CollaborationPolicy-Dienst prüft Aktion, handelnden Principal, Ressource, Heimatmandant und aktuelle Freigaben. Lokaler Transport und Netzwerktransport rufen denselben Fachdienst auf. Allgemeine Ressourcen-, Datei-, Export- und MCP-APIs bleiben für fremde Mandanten geschlossen; neue externe Funktionen müssen bewusst über die eingeschränkte Ansicht eingeführt werden.

Benachrichtigungen werden auf der Heimatinstanz an lokal berechtigte Nutzer erzeugt. Der Eigentümer adressiert externe Principals und greift nicht direkt auf deren Push-Tokens zu. Die vorhandene Push-Infrastruktur kann die Zustellung übernehmen; ihre Instanzregistrierung ersetzt keine Föderationsidentität oder fachliche Autorisierung. Standard für externe Push-Nachrichten ist ein neutraler Hinweis ohne Projekt- oder Nachrichtentext.

10. Betrieb, Dateien und Grenzen

• Öffentlich erreichbare HTTPS-Endpunkte sind Voraussetzung für den direkten Transport in Version 1. Für rein interne Installationen wäre später ein ausdrücklicher Relay-/Tunnelmodus nötig; ein zentraler Chatserver oder ein zentrales Adressbuch ist kein Pflichtbestandteil.
• Ausgehende Ziele stammen ausschließlich aus geprüften Partnerkonfigurationen. URL-Schemas, Ports und sämtliche aufgelösten IPv4-/IPv6-Adressen werden geprüft; keine Weiterleitungen zu beliebigen Hosts und kein Zugriff auf Loopback, private Netze oder Cloud-Metadaten. Prüfungen müssen auch DNS-Wechsel zwischen Validierung und Verbindung abdecken. Geschlossene Firmennetze brauchen eine separat konfigurierte Netzfreigabe. Grundlage: OWASP SSRF Prevention.
• Größenlimits, feste Schemas, Zeitlimits und Quotas gelten pro Instanz, Mandant und Benutzer. Ein gestörter Partner darf keine globale Warteschlange blockieren. Metriken zeigen Zustellverzug, letzte Bestätigung, Retry-Status und Sperren, ohne Chattexte zu protokollieren.
• Beim späteren Dateiaustausch bleibt der Speicher privat. Downloads laufen über einen freigabeprüfenden Dienst; keine dauerhaften öffentlichen S3-Links. Uploads sind begrenzt und vor Freigabe zu prüfen. Temporäre Downloadrechte werden an Principal, Ressource, Version und kurze Laufzeit gebunden. Sie ersetzen nicht die aktuelle Zugriffsprüfung beim Eigentümer.
• Version 1 vertraut den beteiligten Servern und verwendet Transportverschlüsselung. Betreiber der führenden und empfangenden Instanzen können Chattexte verarbeiten. Ende-zu-Ende-Verschlüsselung ist eine separate Architekturentscheidung mit Folgen für Suche, Wiederherstellung, Moderation und Benachrichtigungen; sie darf nicht nachträglich als bereits vorhandene Eigenschaft dargestellt werden.
• Aufbewahrung und Löschereignisse werden je Ressource dokumentiert. Löschanforderungen werden verteilt und protokolliert; Kopien bei fremden Betreibern oder bereits heruntergeladene Dateien sind technisch nicht sicher rückrufbar.

11. Optionaler Gastzugang ohne FEDEO-Konto

Empfehlung für eine spätere Ausbaustufe: Der Projekteigentümer stellt eine reduzierte Gastoberfläche mit eigener Authentifizierung bereit. Nach überprüfter E-Mail-Adresse und Annahme entsteht ein Gast-Principal mit ausschließlich den konkreten Projekt-/Chatfreigaben. Ein Gast erhält weder einen allgemeinen Mandantenzugang noch ein durchgereichtes internes Benutzer-Token.

Ein Einladungslink ist einmalig; wiederholte Anmeldung braucht ein separates Verfahren, beispielsweise Passkey oder kurzlebigen einmaligen Anmeldecode. Verliert der Gast seinen Zugang, führt Wiederherstellung erneut über Identitätsprüfung; eine spätere gleichlautende Adresse darf keine alten Rechte automatisch übernehmen. Ein Wechsel vom Gast zur eigenen FEDEO-Instanz erfordert Zustimmung und eine explizite Neubindung der Freigaben.

Dieser Zugang verwendet denselben Berechtigungsdienst, ist aber kein Bestandteil des ersten Föderationspiloten. So bleibt die erste Ausbaustufe auf authentifizierte Benutzer bestehender FEDEO-Instanzen begrenzt.

12. Architekturentscheidung gegenüber Alternativen

Variante	Bewertung für FEDEO
Native FEDEO-Föderation mit führender Instanz je Ressource	Empfehlung bei Fokus auf FEDEO-Partner und Projektfreigaben. Nutzt die vorhandene Oberfläche; ein eigenes versioniertes Protokoll, Schlüsselverwaltung und Zustellbetrieb müssen dauerhaft gepflegt werden.
Matrix erneut als Chatunterbau	Bietet standardisierte Serverföderation und replizierte Räume. FEDEO benötigt trotzdem eigene Projektfreigaben und ein Mapping zwischen Mandanten und Identitäten. Sinnvoll erneut zu prüfen, wenn Messenger-Interoperabilität, umfangreiche Chatfunktionen oder Verschlüsselung höchste Priorität haben.
Zentraler FEDEO-Kommunikationsdienst	Vereinheitlicht den Betrieb, macht Kommunikation aber von einem gemeinsamen Dienst abhängig und verlagert Datenhaltung. Erfüllt das hier gewählte dezentrale Betriebsmodell nur eingeschränkt.

Matrix definiert bereits einen umfangreichen Server-Server-Vertrag einschließlich Ereignissen, Zustandsabgleich und Autorisierung; die frühere Entfernung ist allein kein fachlicher Grund gegen eine Neubewertung. Unsere Empfehlung für die native Variante folgt dem engeren Ziel „FEDEO-übergreifende Projektzusammenarbeit“, nicht der Annahme, vollständige Messenger-Föderation sei trivial. Matrix Server-Server API

13. Umsetzung in abgeschlossenen Schritten

Schritt	Lieferumfang	Abnahme
0: Bestehende Grenzen absichern	Raumschlüsselkollisionen beheben, Projektchat-Beitritt autorisieren, internen und externen Chat trennen	Kein fremder Raumbeitritt durch Schlüssel oder Projekt-ID; bestehende lokale Chats funktionieren weiter
1: Zusammenarbeit lokal	Principals, Freigaben, Einladungen, Partnerchat und externe Projektansicht zwischen zwei Mandanten derselben Instanz	Einladung und Widerruf funktionieren ohne allgemeine Mandantenmitgliedschaft; Feld-/Historiengrenzen nachgewiesen
2: Föderierter Pilot	Discovery, Partnerfreigabe, Signaturen, Worker, Idempotenz und Synchronisation zwischen zwei Instanzen	Gleicher fachlicher Ablauf über Netzwerk einschließlich Ausfall und erneuter Zustellung
3: Alltagstauglicher Betrieb	Web-/Mobile-Parität, Benachrichtigungen, Moderation, Quotas, Diagnose, Schlüsselrotation und Wiederherstellung	Ende-zu-Ende-Abnahme mit mehreren Mandanten und dokumentierter Wiederaufnahme
4: Erweiterungen	Gastzugang, freigegebene Dateien und gezielte Aufgabenbearbeitung, gegebenenfalls erweiterte Chatfunktionen	Jede neue Fähigkeit erhält eigene Scope-, Widerrufs- und Datenabflusstests

Migrationen erfolgen additiv mit Backfill für öffentliche IDs und lokale Principals. Bestehende Chat-APIs werden während des Übergangs adaptiert. Kein vorhandener Raum wird automatisch föderiert; externe Zusammenarbeit wird je Mandant aktiviert und startet mit explizit angelegten Partnerchats. Bei Abschaltung stoppen neue Einladungen und ausgehende Aktionen; Eigentümer entziehen aktive externe Freigaben und stellen Widerrufe nach Möglichkeit zu. Vorhandene fremde Kopien verschwinden dadurch nicht automatisch. Alte Spalten werden erst nach Clientumstellung und geprüftem Rückfallpfad entfernt.

14. Konkrete Abnahmeszenarien

1. A1 und B1 auf derselben Instanz sowie A1 und B2 auf verschiedenen Instanzen durchlaufen identische Einladung, Annahme, Nachricht und Entzug.
2. Derselbe Benutzer in zwei Heimatmandanten erhält nur im eingeladenen Kontext Zugriff. Gleichlautende numerische IDs oder E-Mail-Adressen verbinden keine fremden Datensätze.
3. Ein Chatgast kann weder Projektübersicht noch interne Ressourcen-, Datei-, Export- oder MCP-Endpunkte verwenden. Ein Projektleser erhält ausschließlich freigegebene Felder und Dokumente.
4. Externe sehen keine alten internen Nachrichten, unsichtbaren Zitate, fremden Partnerchats oder unfreigegebenen Teilnehmerlisten. Eine erneute Einladung erweitert die Historie nicht unbeabsichtigt.
5. Abgelaufene, weitergeleitete, doppelt eingelöste und während Annahme widerrufene Einladungen erzeugen keine unberechtigten Freigaben. Rechteverlust des Einladenden vor Annahme wird erkannt.
6. Manipulierter Body, falscher Signaturschlüssel, falsche Zielinstanz, Nonce-Replay und fremder Principal werden abgelehnt. Ein gültiger Server darf keine andere Organisation impersonieren.
7. Doppelte oder vertauschte Ereignisse, verlorene Bestätigungen und Neustarts erzeugen keine doppelten Nachrichten oder Benachrichtigungen. Ein alter Grant-Zustand überschreibt keinen Widerruf.
8. Entzug während ausstehender Nachricht beziehungsweise Zustellung sperrt noch nicht autorisierte Nutzung. Die Oberfläche unterscheidet ausstehend, bestätigt, fehlgeschlagen und archiviert nachvollziehbar.
9. Ein offline befindlicher Eigentümer führt zu sichtbarer Wartesituation; Wiederverbindung holt nur weiterhin berechtigte Inhalte nach. Lokale interne Chats bleiben unabhängig nutzbar.
10. Discovery und Callback-Ziele können weder interne Dienste noch Metadaten-Endpunkte erreichen, auch bei IPv6, Redirects und DNS-Wechsel.
11. Partnerblockade, Mitarbeiterdeaktivierung, Schlüsselrotation und Restore werden mit mehreren Mandanten getestet. Alte Backups oder verspätete Befehle stellen keine entzogenen Rechte wieder her.
12. Ein Gastzugang wird erst aktiviert, wenn Gastanmeldung, Linkbindung und Trennung von normalen Mandantensitzungen separat geprüft sind.

Als erster nutzbarer Meilenstein wird eine explizite Einladung in einen Partnerchat samt optionaler externer Projektübersicht zwischen zwei lokalen Mandanten empfohlen. Dieser prüft das fachliche Modell, bevor der Netzwerktransport hinzukommt.