Compliance-Tester
Geprüft mit der Suite auf compliance.conversations.im, Report dort einsehbar.
Open Source XMPP
Zerta in Go.
XMPP-Server in Go, Build v0.7.0. Getestet mit der Compliance-Suite auf compliance.conversations.im. Apache 2.0. Für Teams, die Federation, mobile Clients und Betriebskontrolle wollen, ohne einen exotischen Runtime-Stack zu übernehmen.
- Compliance-Suite: compliance.conversations.im
- Build v0.7.0
- Apache 2.0
- Single Go-Binary
Vertrauen
Fakten, keine Plattform-Rhetorik.
Zerta ist ein Hard-Fork von Jackal und wird als eigenständiges Apache-2.0-Projekt weiterentwickelt. Die Seite bleibt bei belegten technischen Aussagen.
Apache-Lizenz
Permissive Open-Source-Lizenz statt Copyleft-Gespräch vor dem ersten Prototyp.
Lesbarer Betriebsstack
Build, Debugging und Deployment passen in normale SRE- und Go-Toolchains.
Moderne Authentifizierung
SASL2, Bind2 und FAST für zeitgemäße Client-Authentifizierung.
Warum Zerta
Für Operator, die den Stack lesen können wollen.
Zerta konkurriert nicht über Alters- oder Größenversprechen. Der Vorteil liegt in kontrollierbarer Technik: Go, klare Lizenz, bekannte Monitoring-Werkzeuge und wählbare Infrastruktur-Backends.
Go statt Spezial-Runtime
Eine Codebase, die sich mit normalen Go-Werkzeugen bauen, prüfen und debuggen lässt.
Apache 2.0 statt Lizenz-Reibung
Geeignet für eigene Erweiterungen, SaaS-Betrieb und Produktintegration ohne frühes Lizenztheater.
Prometheus und pprof
Keine eigene Dashboard-Insel. Metriken und Profile gehen in den Stack, den Ops-Teams ohnehin nutzen.
Fünf Cluster-Backends
Redis, PostgreSQL, NATS, Raft oder etcd: die Architektur folgt deiner Infrastruktur, nicht umgekehrt.
Features
Der aktuelle Scope, gruppiert nach Betriebssicht.
Die Feature-Liste ist bewusst technisch. Keine Kundenlogos, keine Scale-Zahlen, keine Performance-Versprechen ohne Messung.
Auth & Sicherheit
SASL2, Bind2, FAST, Channel Binding, OMEMO, Privacy Lists, Guardian und Anti-Spam.
Messaging & Sync
MAM, Message Carbons, Stream Management, CSI, Offline Messages und Roster.
Zusammenarbeit
Multi-User Chat, persistent rooms, Moderation, MUC RTBL, HTTP Upload, TURN/STUN-Credentials (XEP-0215, externer Server) und Push.
Betrieb
PostgreSQL, MySQL, BoltDB, Redis-Caching, Admin API, zertactl, Prometheus, Health Checks und pprof.
Schnell starten
Eine Binary. Eine Config. Starten.
Der Standardpfad bleibt nachvollziehbar: Repository klonen, Binary installieren, YAML konfigurieren, Server starten. Docker und Helm liegen ebenfalls im Projekt.
git clone https://git.uuxo.net/UUXO/zerta.git
cd zerta
make install installctl
zerta --config=config.yaml
# Nutzer anlegen
zertactl user add username:password
# Docker
docker-compose -f dockerfiles/docker-compose.yml upDokumentation
Vom Setup zum Betrieb.
Die gehostete Docs-Struktur ist der nächste Schritt. Bis dahin führen die wichtigsten Pfade direkt ins Repository.
Installation & Betrieb
Build, systemd, nginx, TLS, Monitoring, Security und Clustering im Admin Guide.
Konfiguration
Vollständige YAML-Referenz für Listener, Storage, Auth, TLS, Module und Cluster.
Compliance
Dokumentierter Weg zur Compliance-Suite auf compliance.conversations.im mit aktiviertem Modul-Set.
FAQ
Fragen vor der Entscheidung.
Kurze Antworten, jede mit Beleg im Repository. Wo eine Dokumentation noch fehlt, steht das hier genau so.
Setup
Was brauche ich für einen produktiven Zerta-Server?
MySQL 8+ oder PostgreSQL 12+ als Datenbank, ein gültiges TLS-Zertifikat (z. B. Let's Encrypt) und nginx davor für TLS-Terminierung, WebSocket und BOSH. HTTP-Upload (XEP-0363) bringt Zerta selbst mit. Für TURN/STUN erzeugt Zerta zeitlich begrenzte Zugangsdaten (XEP-0215); einen eigenen TURN-Server bringt es nicht mit, dafür ist ein externer nötig. Die vollständige Liste inklusive Build-Toolchain steht im Admin Guide unter „Requirements“.
HTTP-Upload: eingebautes 0363-Modul. Für HMAC/Dedup/eigenen Speicher optional hmac-file-server.
Kann ich Zerta ohne externe Datenbank ausprobieren?
Ja. BoltDB ist eingebettet und braucht keinen Datenbankserver — aber nur für einen einzelnen Knoten, ohne Replikation und ohne Clustering. Für den produktiven Betrieb sind MySQL oder PostgreSQL vorgesehen. Das Schema legt Zerta beim Start selbst an, ein manueller Import entfällt.
Betrieb
Wie betreibe ich Zerta auf mehreren Knoten?
Clustering läuft über einen geteilten KV-Store (cluster.type: kv). Im Code implementiert sind fünf Backends: Redis, PostgreSQL, NATS, Raft und etcd. Der Admin Guide beschreibt alle fünf. BoltDB unterstützt kein Clustering.
Welche Monitoring-Schnittstellen gibt es?
Der eingebaute HTTP-Server liefert Prometheus-Metriken unter /metrics (OpenMetrics aktiviert) und Go-Profiling unter /debug/pprof/. Ein Grafana-Dashboard liegt im Repository unter monitoring/. Storage-Metriken werden über storage.repository.type: measured eingeschaltet. Ein eigener Monitoring-Abschnitt in der Dokumentation ist noch nicht veröffentlicht.
Wie schütze ich den Server gegen Brute-Force und Spam?
Guardian begrenzt pro C2S-Listener fehlgeschlagene Logins (max_auth_failures), sperrt Adressen für eine konfigurierbare Dauer (ban_duration) und drosselt neue Verbindungen (connect_rate_limit). Für Nachrichten gibt es das Modul antispam mit Rate-Limit pro Nutzer sowie muc_rtbl für Echtzeit-Blocklisten in Räumen.
Gibt es Guides für Backup, Restore und Upgrade?
Nein. Diese Operator-Guides sind geplant, aber nicht veröffentlicht. Belegt ist bisher nur: Schema-Migrationen führt Zerta beim Start automatisch aus. Backup und Wiederherstellung laufen heute über die Bordmittel der eingesetzten Datenbank plus Konfiguration und Upload-Verzeichnis. Wer Zerta produktiv einsetzt, muss diesen Ablauf derzeit selbst festlegen und testen.
Protokoll
Was bedeutet der Compliance-Tester-Status?
Getestet mit der Suite auf compliance.conversations.im, zuletzt am 15.04.2026 auf 0ea1.net mit demselben Ergebnis wie uuxo.net. Aktuell läuft auf uuxo.net Build v0.7.0. Der volle Report steht bei compliance.conversations.im, kein XEP-Katalog auf dieser Seite.
Was bringen SASL2, Bind2 und FAST?
SASL2 (XEP-0388) zusammen mit Bind2 (XEP-0386) erledigt Login und Ressourcen-Bind in einem Round-Trip, was die Zahl der Roundtrips beim Verbindungsaufbau senkt. FAST (XEP-0484) ergänzt Token-Authentifizierung, dazu kommen Channel Binding (XEP-0440) und SCRAM-Hash-Upgrade (XEP-0480).
FAST-Tokens werden als HT-SHA-256-NONE ausgestellt und sind damit nicht channel-gebunden. Sie sind wie ein vollwertiges Zugangs-Credential zu behandeln.
Migration
Kann ich von ejabberd oder Prosody zu Zerta migrieren?
Ja, mit dem Werkzeug zerta-import. Es liest eine ejabberd- oder Prosody-Datenbank (MySQL oder PostgreSQL) und schreibt in die Zerta-Datenbank: Konten, Roster, vCards, Archiv (MAM), Blocklist, MUC-Räume und PubSub. Mit --dry-run zählt es nur, ohne zu schreiben. Passwörter, die sich nicht sicher übernehmen lassen, brechen den Import mit einem Report ab, statt still unbrauchbar zu werden. Zusätzlich gibt es einen Export zurück nach ejabberd oder Prosody. Ein ausführlicher Migrationsleitfaden ist noch nicht veröffentlicht; Details stehen im Betriebshandbuch im Repository (Abschnitt „Migration von Fremdservern“).
Was unterscheidet Zerta von Jackal?
Zerta ist ein Fork von ortuman/jackal und wird als eigenständiges Projekt unter Apache 2.0 weitergeführt. Schwerpunkte im aktuellen Stand: Compliance-Tester-Abdeckung, moderne Authentifizierung (SASL2/Bind2/FAST), Clustering über KV-Backends sowie Guardian und Anti-Spam.
Konfigurationsdatei, Binaries und Environment-Prefix sind zerta-eigen (zerta.yml, ZERTA_*). Eine Jackal-Konfiguration lässt sich deshalb nicht ungeprüft übernehmen.
Repository
Der Code ist der Beleg.
Server, Doku, Beispielkonfigurationen, Docker-Dateien und Helm-Skripte liegen auf git.uuxo.net. Managed Hosting gehört getrennt auf uuxo.net.