Projects in Buzz

Kernpunkte

1. Datum / Quelle. 18. August 2026, Blog von Block Engineering, ~1.800 Wörter, gezeichnet von Thomas Petersen (Principal Designer & Builder). Keine ausgehenden Links, keine Zahlen.
2. Kernaussage. Buzz Projects ist eine Forge, in der Konversation ein Artefakt erster Klasse ist — Projekte sind mit Channels verknüpft, und « Instead of reconstructing why something happened after the fact, the history is already there. » ### Das Vertrauensmodell: zwei Absätze, die zusammen gelesen werden sollen | Abschnitt des Beitrags | Wortlaut | Was er festlegt | |---|---|---| | First Class Citizens | « No forced guardrails, no limitations on what your agents are allowed to help you with. No limits to how much you can delegate to your agents in the network. » | Wegfall vorheriger Einschränkung | | Weaving it all together | « Every push, review, approval, and merge is a signed Nostr event. If an agent authors a patch, you can see which agent produced it and which human authorized that agent to act. » | signierter Nachweis der Handlung | | derselbe Absatz, Schluss | « we are already exploring ideas around agent trust protocols informed by past behavior » | Herleitung von Vertrauen aus Historie | Die Position ist architektonisch: In einem Netzwerk mit unbegrenzter Delegation skaliert a priori-Autorisierung schlecht, Signieren dagegen nicht. Es ist die "Netzwerk"-Version dessen, was [[longwell-block-buzz-workspace-agents-nostr-2026-07-21]] im Juli auf Identitätsebene dargelegt hat (« authorization does not erase authorship »). Zwei Einschränkungen, die der Beitrag nicht behandelt: Ein ex post-Nachweis verhindert nicht den ersten Schadensfall, und eine signierte Historie belegt, was getan wurde, nicht die Vollständigkeit dessen, was gezeigt wird — ein negatives Register (abgelehnte PRs, Regressionen, Vorfälle) wäre für eine Reputation notwendig und wird nicht erwähnt. ### Was die Signatur garantiert – und was nicht | Garantiert | Nicht garantiert | |---|---| | dass das Event tatsächlich von diesem Schlüssel erzeugt wurde | dass der Schlüssel alles erzeugt hat, was von ihm gezeigt wird | | die Integrität jedes einzelnen Events | die Vollständigkeit des präsentierten Bestands | | die Verknüpfung autorisierender Agent → Mensch | die Auffindbarkeit von Events außerhalb ihres Ursprungs-Relays | Architektonischer Punkt, der diesem Beitrag nicht zuzuschreiben ist: Das Relay ist die einzige Quelle der Wahrheit, ohne Replikation oder Peer-to-Peer-Austausch. Dies stammt aus Blocks ARCHITECTURE.md, wie in [[buzz-block-panorama-deep-research-2026-08-12]] konsolidiert, nicht aus diesem Text, der dazu nichts sagt. Konsequenz: Die angebotene Souveränität ist ein Austrittsrecht, keine Verfügbarkeitsgarantie. ### Git-Interoperabilität: die am leichtesten überprüfbare Behauptung Wortlaut: « These are standard git repositories, like you already know them… You can fetch, clone, pull, and push over plain Smart HTTP, with no custom tooling or wrapper CLI required. Your Nostr key is your identity throughout the process… You do not need another account, another identity, a separate token, or a GitHub account connected in the background. » Konsequenzen: Die Austrittskosten sind konstruktionsbedingt niedrig (ein git clone holt den Code), und die einzige Identität macht Token-Verwaltung überflüssig. Zu beachtende Nuance: nur der Code ist Standard — Konversation, Review, PR↔Channel-Verknüpfung und Beitragshistorie liegen in Buzz-spezifischen Nostr-event kinds. Ein in zehn Minuten durchführbarer Test: clone und anschließend push von einem reinen Git-Client gegen ein Buzz-Relay, ohne die buzz-CLI. ### Angekündigter Bestand vs. gelieferter Bestand Der einleitende Absatz nennt sechs Fragmente, die zusammengeführt werden sollen; der Abschnitt « What's next? » nennt, was existiert. | Im Vorspann genanntes Fragment | Im Bestand vom 18. August vorhanden | |---|---| | « A bug report lands in one tool » | ja — Issues | | « The discussion happens in another » | ja — mit dem Projekt verknüpfte Channels | | « The fix lives on a branch somewhere else » | ja — hosted git, Multi-Repo | | « Review happens in a comment thread attached to a diff » | ja — PRs, Reviews, Inline-Kommentare | | « CI runs in another system » | nein — unter den Versprechen genannt, im Bestand fehlend | | « Release notes get written later » | nein | Sechs Fragmente angekündigt, vier geliefert. Die Liste "repos, branches, pull requests, issues, CI, or all the related conversations" nicht als Bestand ausgelieferter Funktionen weiterverwenden. ### Wiederverwendbare Unterscheidung: Ausführen ist nicht dasselbe wie Präsentsein | Was ein Terminal einem Agenten gibt | Was Netzwerkpräsenz hinzufügt | |---|---| | ausführen, Dateien schreiben | eine stabile Identität, die andere ansprechen können | | lokaler, verwerfbarer Zustand | eine angehängte Historie, die die Session überdauert | | handeln | Rechenschaftspflicht für das Getane | Ein nützlicher Rahmen, um einen Tool-Agenten (aufgerufen) gegen einen Member-Agenten (adressiert) abzuwägen. Ein Korollar, das der Beitrag nicht behandelt: Eine dauerhafte Präsenz ist auch eine dauerhafte Angriffsfläche — siehe [[valente-zalewski-beyond-zero-enterprise-security-ai-era-2026-07-20]]. ### "Context is (almost) all you need" Wortlaut: « The more context we can make available, the better equipped the agents are, the more intelligent the whole network becomes. » Monotonie wird ohne Begründung behauptet: Weder die Kosten von Kontext noch seine Degradation noch seine Auswahl werden diskutiert, und das « (almost) » wird nie ausgeführt. Ein Vergleich mit dem bei Block selbst quantifizierten Token-Budget von [[patel-block-buzz-teams-tokens-benchmarks-2026-08-06]] lohnt sich. ### Die einzige Wirkungsbehauptung des Beitrags « We've already seen a number of examples where agents understood context humans didn't and helped course correct otherwise unproductive directions. » Kein Beispiel, keine Zahl, kein Erfolgskriterium. Korrekte Formulierung für die Weiterverwendung: « Block reports, without documenting them, cases where agents redirected unproductive directions using channel context. » Fiche erneut zu öffnen, falls Block diese Fälle veröffentlicht. ### Zitierhygiene 1. Zitierbar als architektonische Absicht von Block; nicht als Nachweis von Funktionsfähigkeit oder Adoption. 2. Stets die angegebene Reife mitführen: Tab Experiments, « fairly elementary », Buzz « still in beta ». 3. Unterscheiden zwischen Funktionen, die in Screenshots gezeigt werden, solchen, die unter « What's next? » aufgeführt sind, und solchen, die nur in Versprechenssätzen genannt werden (CI, Release Notes). 4. Die « agent trust protocols » sind eine angekündigte Richtung, ohne Schema, ohne Kriterium, ohne Zeitplan.