Chat-Tools, Coding-Agenten, Git-Hosting, Tickets und CI erzeugen meist getrennte Spuren. Eine Entscheidung steht im Chat, der Patch im Repository, der Lauf in einer CI-Oberfläche und der Kontext im Kopf einzelner Beteiligter. Buzz von Block versucht nicht, einfach noch einen Bot in diesen Stapel zu setzen. Es baut einen gemeinsamen Arbeitsraum, in dem Menschen und Agenten dieselben Räume, Identitätsregeln und einen signierten Ereignisverlauf benutzen.1, 2
Das ist ein interessanter Ansatz, aber kein fertiger Ersatz für Slack, GitHub und eine CI-Plattform.2 Buzz bezeichnet sich selbst als Developer Preview; wichtige Bausteine sind noch in Arbeit oder bewusst nur teilweise umgesetzt.1, 2 Für Teams, die Agenten nicht als privaten Einzelnutzer-Tab, sondern als nachvollziehbare Mitwirkende einsetzen wollen, ist das Projekt trotzdem einen genauen Blick wert.2
Kurzantwort
Buzz ist ein quelloffener, selbst hostbarer Workspace von Block. Ein eigenes Relay speichert Chats, Threads, Reaktionen, Git-Ereignisse, Suchindex und Audit-Informationen; Menschen und Agenten handeln darin über eigene Nostr-Schlüssel. Für einen lokalen Test reicht die Desktop-App plus lokales Relay. Wer ein Team produktiv anbinden will, betreibt das bereitgestellte Compose-Bundle mit PostgreSQL, Redis und S3-kompatiblem Speicher, sichert die Schlüssel und pinnt das Container-Image auf eine konkrete Version.2, 5, 7
Was Buzz anders macht
Die Oberfläche erinnert an Slack: Communities, Channels, Threads, Direktnachrichten und Reaktionen. Der grundlegende Unterschied liegt unterhalb der Oberfläche. Buzz legt Nachrichten, Reaktionen, Workflow-Schritte, Review-Freigaben und Git-Ereignisse als kryptografisch signierte Nostr-Ereignisse in einem Relay ab. Das Relay ist die zentrale Quelle für Lesen und Schreiben; es ist ausdrücklich kein Peer-to-Peer-Netz und keine Blockchain.2, 3
Ein Agent ist dabei kein Webhook, der unter einem Menschenkonto schreibt. Er erhält ein eigenes Schlüsselpaar, eigene Channel-Mitgliedschaften und einen eigenen Prüfpfad. Praktisch lässt sich also nachvollziehen, welcher Agent welche Nachricht, welchen Patch oder welchen Workflow-Schritt ausgelöst hat. Das ersetzt keine Rechteplanung, macht Zuständigkeiten aber wesentlich klarer als ein geteiltes API-Token.2, 3
Abbildung: Projekt-Channel und Agenten-Thread in Buzz. Screenshot aus dem offiziellen Buzz-Repository.10
Ein Ereignislog statt vieler lose gekoppelter Protokolle
Technisch nutzt Buzz Nostr NIP-01 auf der Leitung. Ein Ereignis enthält unter anderem Public Key, Inhalt, Tags, Typnummer und Schnorr-Signatur. Das Relay prüft Anmeldung und Signatur, prüft bei Channel-Inhalten die Mitgliedschaft, persistiert Ereignisse, verteilt sie an Abonnenten, indexiert sie für die Suche und schreibt Audit-Informationen.3
Das klingt abstrakt, hat aber einen konkreten Effekt: Wenn ein Agent einen Fehler triagiert, kann die Diskussion mitsamt Belegen im selben Arbeitsraum bleiben.2 Wenn ein Feature-Branch zum Channel wird, können Patch, CI-Status, Review und Merge-Entscheidung nebeneinander liegen.2 Diese Einheitlichkeit ist der stärkste Teil des Konzepts; sie verhindert aber nicht automatisch schlechte Agentenentscheidungen oder unzureichende Prüfungen.
Was heute tatsächlich nutzbar ist – und was nicht
Laut Projekt-README sind Relay, Channels, Threads, Direktnachrichten, Canvases, Medien, Suche, Audit-Log, Desktop-App, buzz-cli, ACP-Anbindung, YAML-Workflows und Git-Ereignisse bereits vorhanden. Mobile Clients, Teile der Workflow-Freigaben und Huddle-Ereignisse werden noch verdrahtet; Web-of-Trust-Reputation, Push-Benachrichtigungen, Git-Hosting-Backend und weitere Kulturfunktionen sind Vision, nicht zugesagte Produktfunktion.2
Die Architektur-Dokumentation nennt zudem konkrete Lücken: Das Rate-Limiter-Interface hat derzeit keine produktive Implementierung. Workflow-Freigaben sind nicht Ende-zu-Ende verdrahtet; ein Lauf mit Freigabeschritt kann als fehlgeschlagen enden. Die Workflow-Aktionen send_dm und set_channel_topic sind schema-seitig vorhanden, liefern aber aktuell NotImplemented.3
Die Konsequenz ist schlicht: Buzz eignet sich im August 2026 gut zum Erkunden eines agentenorientierten Team-Workspaces und für kontrollierte interne Pilotprojekte.2, 3 Für eine öffentlich erreichbare, geschäftskritische Plattform sollte man es nicht wie eine ausgereifte Collaboration-Suite behandeln.3 Insbesondere externe Zugänge, Agentenbefugnisse, Backups und Updates brauchen einen verantwortlichen Betreiber.5, 7
Für wen ist Buzz sinnvoll?
Sinnvoll ist Buzz für:
- kleine Entwicklerteams oder Homelabs, die Agenten sichtbar in ihre Arbeitskanäle einbinden möchten;2
- Projekte, bei denen nachvollziehbar bleiben soll, warum ein Patch entstand und wer ihn geprüft hat;2
- Teams mit mehreren Agenten-Harnesses, etwa Codex, Claude Code oder Goose, die nicht jeweils in isolierten Einzeltabs arbeiten sollen;2, 6
- Betreiber, die Chat- und Agentendaten auf eigener Infrastruktur und unter eigenen Schlüsseln halten wollen.2, 6
Weniger passend ist es für:
- Organisationen, die sofort belastbare Compliance-, SSO-, Mobil- und Support-Anforderungen abdecken müssen;2, 3
- Teams, die keine Person für Container, Datenbank, Object Storage, Schlüssel und Backups haben;5, 7
- Workflows, in denen ein Agent unbeaufsichtigt weitreichende Produktionsrechte erhalten soll. Ein signierter Verlauf ist ein Nachweis, keine Sicherheitsfreigabe.
Ein aktuelles Praxisvideo von Tonbi’s AI Garage zeigt genau den produktiven Kern: Agenten werden wie Mitglieder zu Channels hinzugefügt, antworten in Threads und können auf getrennte Rollen, Harnesses und Zugriffsregeln zugeschnitten werden. Das Video ist ein Erfahrungsbericht, nicht die Produktspezifikation; für die tatsächlichen Fähigkeiten und Grenzen bleibt die Projektdokumentation maßgeblich.9, 2
Abbildung: Agenten erscheinen als Mitglieder eines Engineering-Channels und reagieren neben Menschen. Screenshot aus dem offiziellen Buzz-Repository.11
Die Bausteine: Desktop, Relay, Agenten und CLI
Buzz besteht nicht aus einer einzelnen App:2, 3
| Baustein | Aufgabe |
|---|---|
| Buzz Desktop | Tauri-/React-Client für Menschen; verbindet sich mit einem Relay. |
buzz-relay | Rust-Server für WebSocket, REST-API, Authentifizierung, Ereignisse, Suche und Audit. |
| PostgreSQL | Speichert Ereignisse, Channels, Tokens, Workflows und Audit-Daten. |
| Redis | Verteilt Ereignisse, verwaltet Presence und Typing-Signale. |
| S3/MinIO | Speichert Medien und Git-/CAS-Daten. |
buzz-cli | Agentenorientierte Kommandozeile: JSON rein, JSON raus. |
buzz-acp | Brücke zwischen Relay-Ereignissen und Agenten über das Agent Client Protocol (ACP). |
Für Agenten ist die CLI bewusst maschinenlesbar. Sie kann Channels und Nachrichten verwalten, suchen, auf Ereignisse reagieren, Workflows auslösen, Agent-Memory schreiben sowie Git-Repositories ankündigen und schützen. Zur Anmeldung verwendet sie einen eigenen privaten Nostr-Schlüssel in BUZZ_PRIVATE_KEY; dieser gehört in einen Secret Store, nicht in ein Repository oder einen Chat.6
Installation: drei sinnvolle Wege
1. Schnell ausprobieren: Desktop-App an ein vorhandenes Relay hängen
Der schnellste Einstieg ist ein Paket aus den aktuellen GitHub-Releases. Zum Recherchezeitpunkt ist Buzz Desktop v0.5.5 die aktuelle Desktop-Veröffentlichung. Es gibt Builds für macOS auf Apple Silicon und Intel, Linux als AppImage oder Deb-Paket sowie einen Windows-Installer. Der Windows-Build ist laut Projekt nicht code-signiert; SmartScreen kann deshalb beim ersten Start warnen.4, 2
Nach dem Start verbindet sich die App standardmäßig mit ws://localhost:3000. Für ein eigenes oder geteiltes Relay lässt sich BUZZ_RELAY_URL vor dem Start setzen oder die Relay-Adresse in der App ändern.2
# Beispiel für Linux/macOS: Relay vor dem Start festlegen
export BUZZ_RELAY_URL="ws://127.0.0.1:3000"
Dieser Weg ist nur dann sinnvoll, wenn bereits ein Relay existiert.2 Für einen echten lokalen Test muss das Relay zunächst über den Quellcode oder das Produktions-Compose-Bundle gestartet werden.2, 5
2. Lokal aus dem Quellcode: der Entwicklerweg
Der offizielle Quick Start verlangt Docker und Hermit. Alternativ nennt das Projekt Rust ab 1.88, Node ab 24, pnpm 10 und just. Hermit lädt die fixierten Werkzeuge beim ersten Aufruf nach.2
git clone https://github.com/block/buzz.git
cd buzz
. ./bin/activate-hermit
just setup && just build
# Für die tägliche Entwicklung
. ./bin/activate-hermit
just dev
just setup startet die Docker-Dienste und Migrationen; just dev startet Relay und Desktop zusammen. Das Relay ist dann unter ws://localhost:3000 erreichbar. Wer Relay- und Desktop-Logs getrennt sehen will, nutzt just relay und in einem zweiten Terminal just desktop-dev.2
Wichtig: Das Docker-Compose im Projektwurzelverzeichnis ist ausdrücklich für die tägliche Entwicklung gedacht. Es ist kein Produktionsrezept für einen öffentlich erreichbaren Server.2, 5
3. Eigenes Team-Relay auf VPS oder Homeserver
Für einen einzelnen Server stellt das Repository deploy/compose/ bereit. Der Stack startet Relay, PostgreSQL 17, Redis 7, MinIO und einen Job zum Anlegen des Media-Buckets. Docker Compose ab Version 2.24.4 ist erforderlich.5, 7
git clone https://github.com/block/buzz.git
cd buzz/deploy/compose
cp .env.example .env
# Danach jede CHANGE_ME-Angabe bewusst ersetzen.
./run.sh config
./run.sh start
./run.sh status
Für eine lokale Installation muss RELAY_URL exakt der Adresse entsprechen, mit der sich Clients verbinden, beispielsweise ws://127.0.0.1:3000. Nicht zwischen localhost und 127.0.0.1 wechseln: Die Dokumentation weist darauf hin, dass die Adresse einschließlich Schema und Port die Community identifiziert und bei Abweichungen die NIP-98-Anmeldung scheitern kann.7
Für einen VPS mit Domain aktiviert dieser Aufruf die Caddy/TLS-Ergänzung:
BUZZ_COMPOSE_TLS=true ./run.sh start
Dann braucht RELAY_URL die öffentliche wss://-Adresse.7 Vor den ersten echten Daten sollte die Domain feststehen: Ein Wechsel der Relay-URL erzeugt praktisch eine neue, leere Community; die lokale Test-Community bleibt an der alten Adresse gebunden.7
Schlüssel und Betrieb sauber vorbereiten
Ein produktiver Betrieb braucht zwei voneinander verschiedene Nostr-Identitäten:7
BUZZ_RELAY_PRIVATE_KEYist der Signierschlüssel des Relays.7RELAY_OWNER_PUBKEYist der öffentliche Schlüssel des Besitzers und darf nicht mit einem privaten Schlüssel verwechselt werden.7
Der offizielle Weg erzeugt bei Bedarf ein Schlüsselpaar im Container:7
docker run --rm --entrypoint /usr/local/bin/buzz-admin \
ghcr.io/block/buzz:main generate-key
Den privaten Teil nicht in Shell-Historien, Tickets oder Konfigurations-Repositories kopieren. Die Projektanleitung empfiehlt, Relay-Schlüssel, Owner-Key, PostgreSQL-Daten, Object-Storage-Bucket und Git-Volume zu sichern. Außerdem sollte ein produktiver Betreiber BUZZ_IMAGE nicht dauerhaft auf :main lassen, sondern auf einen Release-Tag oder Digest pinnen.5, 7
Nach dem Start gehört eine echte Prüfung dazu:
curl -fsS http://127.0.0.1:3000/_liveness
./run.sh status
Erst wenn beide Prüfungen erfolgreich sind, sollte die Relay-Adresse an weitere Personen verteilt werden.5
Abbildung: Buzz kann Medien im Channel anzeigen und Kommentare an Frames verankern. Screenshot aus dem offiziellen Buzz-Repository.12
Agenten anbinden, ohne die Kontrolle abzugeben
Für einen ersten Agentenbetrieb braucht Buzz ein eigenes Schlüsselmaterial und eine Relay-URL.2 Das offizielle Beispiel für die ACP-Harness-Konfiguration lautet konzeptionell:2
export BUZZ_PRIVATE_KEY="nsec1..."
export BUZZ_RELAY_URL="ws://127.0.0.1:3000"
buzz-acp
Die ACP-Harness kann Agentenprozesse wie Goose, Codex oder Claude Code starten. Sie unterstützt unter anderem Begrenzungen für parallele Prozesse, Turn-Timeouts, Channel-Filter und einen standardmäßigen Mention-Modus. Die Defaults sind jedoch kein Sicherheitskonzept für produktive Zugriffe: Jede Agentenrolle braucht einen klaren Arbeitsbereich, möglichst wenige Tools und keine impliziten Produktionsrechte.2
Ein sinnvolles Pilotmuster ist deshalb:
- Relay nur intern oder zunächst lokal betreiben.
- Einen einzelnen Agenten mit eigener Identität anlegen.2
- Ihn nur in einen Test-Channel aufnehmen.2
- Sein Arbeitsverzeichnis und seine Tools auf ein Test-Repository begrenzen.
- Erst danach Aufgaben wie Recherche, Issue-Triage oder Patch-Vorschläge ausführen lassen.
- Menschen behalten Review und Merge-Entscheidung.
Das aktuelle Developers-Digest-Video demonstriert die Nutzung als vertraut wirkenden Chat-Workspace mit Agenten, Rollen und unterschiedlichen Harnesses. Es ist nützlich, um die Oberfläche und das Zusammenspiel zu sehen; Aussagen über installierte Funktionen sollten stets gegen README und Release-Stand gegengeprüft werden.8, 2
Was der Ansatz bringt – und was er nicht löst
Der Nutzen von Buzz liegt nicht darin, dass ein Modell „mehr kann“. Der Nutzen ist organisatorisch: Agentenaktivität, Auftrag, Antworten und Folgen werden im selben Raum sichtbar.2 Das erleichtert Übergaben, Suche und spätere Nachvollziehbarkeit.2 Besonders bei mehreren spezialisierten Agenten ist ein gemeinsamer Kontext besser als eine Sammlung unsichtbarer Cronjobs und Einzelsitzungen.
Die Grenzen bleiben erheblich:
- Ein Audit-Log beweist nicht, dass eine Entscheidung richtig war.
- Eigene Schlüssel machen Identitäten sauberer, ersetzen aber kein Secret-Management.
- Self-Hosting bedeutet Datenhoheit, aber auch Verantwortung für Datenbank, Updates, Backups und Zugangsschutz.5, 7
- Die Open-Source-Lizenz Apache 2.0 erlaubt breite Nutzung und Veränderung, enthält aber keine Betriebszusage oder Gewährleistung.2, 13
- Der Projektstatus ist Frühphase.1, 2 Die eigene Pilotumgebung sollte deshalb klein bleiben und ohne geschäftskritische Abhängigkeit starten.
Mein Urteil: Buzz ist eine der klareren Antworten auf die Frage, wie Agenten in Teamarbeit sichtbar werden können. Die Entscheidung für ein einheitliches, signiertes Ereignismodell ist technisch konsistent und für Entwicklungsarbeit plausibel.2, 3 Wer heute eine stabile Unternehmensplattform sucht, sollte abwarten.2, 3 Wer ein Homelab oder ein kleines Entwicklerteam hat und Agenten kontrolliert in reale Channels holen will, bekommt ein ungewöhnlich konkretes Open-Source-Experiment.
Passende Produktrecherchen
Für den Betrieb eines kleinen Self-Hosting-Setups sind diese Recherchen nützlicher als beliebige „KI-Hardware“:
- Mini-PCs für Docker und Homelab
- Unterbrechungsfreie Stromversorgung für NAS und Server
- Externe SSDs für verschlüsselte Backups
- Hardware-Sicherheitsschlüssel für Admin-Zugänge
- NAS-Systeme für lokale Backups
Als Amazon-Partner verdiene ich an qualifizierten Verkäufen. Preise und Verfügbarkeiten können abweichen.
Transparenzhinweis
Dieser Beitrag wurde mit Unterstützung künstlicher Intelligenz erstellt und automatisiert auf Quellen, Fakten und Qualitätskriterien geprüft.
Quellen
[2] Buzz README
[6] Buzz CLI
[7] Block Engineering: Run your own Buzz relay
[8] Developers Digest: Buzz – Open-Source Collaboration
[9] Tonbi’s AI Garage: Buzz Beginner’s Guide
[10] Offizieller Screenshot: Channel-Thread
[11] Offizieller Screenshot: Channel-Agenten