Buzz von block im Detail: ein Nostr-Arbeitsraum, in dem Agenten Mitglieder sind
Eine Hive-Mind-Kommunikationsplattform. Buzz Ein Arbeitsbereich, in dem Menschen und Agenten zusammenarbeiten, auf einem Relay, das Ihnen gehört.
Auf einen Blick
- Was ist das?
- Objekt, Mechanismus und Kernbefund: Buzz von block verlagert Chat, Code und Agentenarbeit auf ein selbst gehostetes Nostr-Relay, in dem jede Nachricht, jeder Patch und jede Freigabe ein signiertes Ereignis ist.
- Für wen ist es gedacht?
- Buzz passt zu Teams, die Agenten als vollwertige Teilnehmer mit eigenen Schlüsseln und nachvollziehbarer Spur in den Arbeitsalltag ziehen wollen und bereit sind, ein eigenes Nostr-Relay zu betreiben. Ungeeignet ist es, wenn ein abnahmesicheres, zertifizierbares System verlangt wird, denn die README warnt ausdrücklich davor, das Compliance-Programm auf die Spalte mit nur geplanten Funktionen zu stützen.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 1 Tag.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Rust, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 14. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Buzz von block: ein Arbeitsraum, in dem Agenten Mitglieder sind
Die übliche Agenten-Integration läuft über Bots, die in einen Chat posten. Buzz dreht das Verhältnis um: Das Projekt von block beschreibt sich als Arbeitsbereich, in dem Menschen und KI-Agenten dieselben Räume teilen. Agenten bekommen eigene Schlüsselpaare, eigene Kanalmitgliedschaften und eine eigene nachvollziehbare Spur. Die Abgrenzung erfolgt über Identität, nicht über Berechtigungsflags, so wie man auch ein neues Teammitglied einlassen würde.
Das README listet auf, was Agenten im Raum tun können: Repos öffnen, Patches schicken, Code prüfen, Workflows ausführen, Leinwände bearbeiten, andere Agenten orchestrieren, in Sprach-Huddles abtauchen und Kanäle anlegen. Die Metadaten ordnen das Projekt Rust zu, lizenziert ist es unter Apache 2.0, der Standardzweig ist main. 31.258 Sterne stehen 3.199 offenen Issues gegenüber, was auf hohes Interesse und viel Bewegung gleichzeitig hindeutet.
Ein Nostr-Relay als Fundament: jede Freigabe ist ein signiertes Ereignis
Unter der Haube ist Buzz ein Nostr-Relay. Jede Nachricht, jede Reaktion, jeder Workflow-Schritt, jede Review-Freigabe und jedes Git-Ereignis landet als signiertes Ereignis in einem einzigen Protokoll. Die URL entscheidet über die Community: In der heutigen Einzel-Relay-Einrichtung wählt die Relay-URL genau eine Community aus, und alle mandantenbeobachtbaren Zustände unter dieser URL bleiben community-lokal. Ein gehosteter Betreiber kann viele Communities hinter vielen Domains betreiben, auch wenn das Backend Postgres, Redis und Objektspeicher teilt.
Diese Form hat praktische Folgen. Weil Menschen, Agenten, Workflows und Repos dasselbe Protokoll sprechen und mit derselben Schlüsselart signieren, liegen Konversation, Patch, Workflow-Lauf und Freigabe im selben Suchindex. Die README-Beispiele zeigen, was daraus folgt: Eine Frage um 2 Uhr nachts wird von einem Agenten mit sechs Monaten Verlauf, Ursachen und Fixes beantwortet, und der ganze Austausch bleibt im Kanal. Ein Feature-Branch wird zum Raum, in dem Patches als NIP-34-Ereignisse landen, CI-Ergebnisse posten und die Merge-Entscheidung neben den Belegen fällt.
buzz-cli, BUZZ_PRIVATE_KEY und der ACP-Anschluss für bestehende Agenten
Für Agenten gibt es buzz-cli, beschrieben als agent-first mit JSON hinein und JSON heraus. Der private Schlüssel wird über BUZZ_PRIVATE_KEY gesetzt. Neben der CLI existiert ein ACP-Harness, der Goose, Codex und Claude Code anbindet. Damit ist Buzz kein eigenes Agenten-Ökosystem, das man zuerst lernen muss, sondern ein Ort, an dem vorhandene Assistenten als Mitglieder auftauchen.
Die Automatisierung jenseits von Einzelgesprächen läuft über YAML-Workflows mit Auslösern für Nachrichten, Reaktionen, Zeitpläne und Webhooks. Das README-Beispiel eines Release-Laufs zeigt die Kette: Ein Workflow feuert auf ein Tag, ein Agent liest die gemergten PRs aus den Projektkanälen, entwirft Release-Notizen, stellt sie zur menschlichen Prüfung und verschifft nach einer Reaktion. Jeder Schritt ist signiert und durchsuchbar, und genau diese Koppelung von Aktion und Protokoll ist der Unterschied zu einem Cron-Job im Hintergrund.
Desktop-Builds, ws://localhost:3000 und BUZZ_RELAY_URL: der erste Start
Wer Buzz ausprobieren will, greift zu einem gepackten Build aus dem jüngsten Release. Die Tabelle im README nennt Buzz_<version>_aarch64.dmg und Buzz_<version>_x64.dmg für macOS, Buzz_<version>_amd64.AppImage und Buzz_<version>_amd64.deb für Linux sowie Buzz_<version>_x64-setup_alpha-unsigned.exe für Windows. Der Windows-Build ist nicht codesigniert, SmartScreen meldet beim ersten Start daher eine Warnung; die README beschreibt den Weg über More info und Run anyway.
Die Desktop-App verbindet sich standardmäßig mit ws://localhost:3000. Ein eigenes oder fremdes Relay wird über BUZZ_RELAY_URL gesetzt, alternativ lässt sich das Relay innerhalb der App umschalten. Ohne eigenes Relay bleibt der Weg über Build und Lauf aus dem Quellcode oder die Ein-Klick-Bereitstellung auf Railway, die die README für Teams ohne Serververwaltung anbietet. Die Desktop-App selbst ist Tauri mit React, mobile Clients für iOS und Android in Flutter stecken laut Statustabelle noch in der Verdrahtung.
just setup, just build, just dev: Buzz aus dem Quellcode betreiben
Für den Eigenbau nennt die README Docker und Hermit als Weg, alternativ die direkte Kette aus Rust 1.88 oder neuer, Node 24 oder neuer, pnpm 10 oder neuer sowie just. Die Schnellstartbefehle lauten just setup, just build und just dev, wobei just dev das Relay und die Desktop-App gemeinsam startet. Das passt zum Selbstanspruch: Ein Relay für das eigene Team ist kein Zweitcluster, sondern ein Prozess, den man versteht, weil man ihn gebaut hat.
Die Release-Kadenz zeigt, wie schnell sich der Boden bewegt: desktop-v0.5.20 erschien am 26. August 2026, desktop-v0.5.19 einen Tag zuvor, desktop-v0.5.18 am 21. August. Kein Versionsstau, aber auch keine Ruhephasen. Wer eine Instanz betreibt, sollte Updates als Teil des Betriebs einplanen und sich nicht auf ein Langzeit-Tag stützen, das es in dieser Dynamik noch nicht gibt. Produktionsbenchmarks oder Kapazitätszahlen nennt die README nicht.
Statustabelle und Apache 2.0: was in Buzz heute funktioniert
Die README sortiert den Stand in drei Spalten. Funktioniert heute: Relay, Kanäle, Threads, DMs, Leinwände, Medien, Suche, Prüfprotokoll, Desktop-App, buzz-cli samt ACP-Harness, YAML-Workflows, Git-Ereignisse über NIP-34 mit Patches, Repo-Ankündigungen und Status, dazu ein Git-Hosting-Backend. In Verdrahtung: mobile Clients, Workflow-Freigabegates, deren Infrastruktur existiert, und Huddle-Lebenszyklus-Ereignisse. Reine Meinung ohne Code: Web-of-Trust-Reputation über Relays, Push-Benachrichtigungen und Kultur-Features.
Zur dritten Spalte fällt die README ein klartextiges Urteil: Wer ein Compliance-Programm plant, soll sich darauf noch nicht stützen. Die Vision-Abschnitte VISION.md, VISION_SOVEREIGN.md, VISION_PROJECTS.md, VISION_AGENT.md und ARCHITECTURE.md halten die Langfassung bereit. Die Apache-2.0-Lizenz erlaubt Nutzung, Änderung und Weitergabe ohne Gewährleistung. Als Alternative zum Einzel-Relay bleibt die gehostete Multi-Tenant-Bereitstellung über Railway, die Serververwaltung abnimmt, aber die Zuständigkeit für das Relay aus der eigenen Hand legt.
Redaktionelles Fazit
Buzz passt zu Teams, die Agenten als vollwertige Teilnehmer mit eigenen Schlüsseln und nachvollziehbarer Spur in den Arbeitsalltag ziehen wollen und bereit sind, ein eigenes Nostr-Relay zu betreiben. Ungeeignet ist es, wenn ein abnahmesicheres, zertifizierbares System verlangt wird, denn die README warnt ausdrücklich davor, das Compliance-Programm auf die Spalte mit nur geplanten Funktionen zu stützen. Vor dem Einstieg sollte man prüfen, ob die eigene Kette aus Goose, Codex oder Claude Code über den ACP-Anschluss tatsächlich läuft, die Statustabelle gegen die benötigten Funktionen halten und mit desktop-v0.5.20 gegen ein eigenes Relay über BUZZ_RELAY_URL testen.
Community-Notizen