Nebu

Nebu (benannt nach dem Schiff „Nebukadnezar" aus dem Matrix-Film) ist ein Enterprise-Chat-Server, der die Matrix Client-Server API implementiert. Damit funktionieren Standard-Matrix-Clients (Element, Cinny, FluffyChat u.a.) ohne Anpassungen.

Nebu ist für Organisationen entwickelt, die volle Datensouveränität benötigen: On-Premise-Betrieb, kein Vendor-Lock-in, kein Telemetrie-Overhead und kein Föderationsprotokoll.

Architektur: Zwei Laufzeitkomponenten - eine einzige Elixir/OTP-Applikation (Matrix-API, Media-Gateway und Admin-UI als Modul-Namespaces Nebu.Matrix/Media/Admin; Room GenServer via Horde, Session-Manager via ETS, Presence, Event-Dispatcher) und PostgreSQL als Append-only-Eventlog. Kein Go, kein Redis, kein NATS, kein Kafka.

Sicherheit und Compliance: Authentifizierung ausschließlich über den firmeneigenen OIDC-Provider (Keycloak, Azure AD, Google Workspace, Dex), keine eigene Passwortverwaltung, Ed25519-Nachrichtensignaturen für Authentizität und Nicht-Abstreitbarkeit, Audit-Logging, Legal-Export und Vier-Augen-Prinzip für privilegierten Zugriff.

OAuth 2.0 (Matrix v1.15): Optional tritt Nebu als OAuth-2.0-Authorization-Server (Broker-Modell) vor den OIDC-Provider. Aktuelle Matrix-Clients (Element Web, FluffyChat) registrieren sich per Dynamic Client Registration, ein Administrator gibt neue Clients frei, Matrix-Access- und Refresh-Tokens stellt allein Nebu aus und sie lassen sich widerrufen. Der Provider authentifiziert nur den Menschen. Die Funktion ist standardmäßig ausgeschaltet und wird im Admin-UI geschaltet; solange sie aus ist, bleibt der bisherige OIDC-Login unverändert.

Ende-zu-Ende-Verschlüsselung (Client-Infrastruktur, Räume bleiben unverschlüsselt): Nebu unterstützt die clientseitige E2EE-Infrastruktur der Matrix-Clients: serverseitiges Schlüssel-Backup (room_keys), To-Device-Nachrichten, Geräte-Schlüsselverzeichnis (keys/upload, query, claim, changes, device_lists im Sync) sowie Cross-Signing mit serverseitig geprüften Ed25519-Signaturen für die Geräteverifikation. Der Server speichert nur öffentliche Schlüssel und opake Blobs, entschlüsselt nichts und loggt kein Schlüsselmaterial. Räume bleiben bewusst unverschlüsselt: m.room.encryption und m.room.encrypted werden abgelehnt, damit Archiv, Audit-Log und Legal-Export vollständig bleiben. To-Device-Nachrichten sind auf eine feste Liste von Typen begrenzt und mengenbegrenzt. Nicht unterstützt: Ende-zu-Ende-verschlüsselte Element-Call-Anrufe.

Implementierter Matrix-Scope: Login, Logout, Sync, Send, Messages, CreateRoom, Join, Typing, Receipts, Profile, Presence, Media-Upload/-Download/-Thumbnail, Schlüssel-Backup, To-Device, Schlüsselverzeichnis und Cross-Signing, OAuth-2.0-API (optional). Bewusst ausgeschlossen: Federation, Identity Server, verschlüsselte Räume.

Technologie-Stack: Elixir/OTP 1.19+ (Bandit, Plug, Phoenix LiveView), PostgreSQL 16+, Docker.