Projects in Buzz

À retenir

1. Date / source. 18 août 2026, blog Block Engineering, ~1 800 mots, signé Thomas Petersen (Principal Designer & Builder). Aucun lien sortant, aucun chiffre.
2. Cadrage clé. Buzz Projects est une forge dont la conversation est un artefact de premier rang — les projets sont liés aux canaux, et « Instead of reconstructing why something happened after the fact, the history is already there. » ### Le modèle de confiance : deux paragraphes à lire ensemble | Section du billet | Verbatim | Ce qu'il installe | |---|---|---| | 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. » | suppression de la contrainte préalable | | 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. » | enregistrement signé de l'acte | | même paragraphe, fin | « we are already exploring ideas around agent trust protocols informed by past behavior » | dérivation de la confiance depuis l'historique | La position est architecturale : dans un réseau où la délégation est illimitée, l'autorisation a priori passe mal à l'échelle, la signature oui. C'est la version « réseau » de ce que [[longwell-block-buzz-workspace-agents-nostr-2026-07-21]] posait en juillet au niveau de l'identité (« authorization does not erase authorship »). Deux limites que le billet n'aborde pas : un enregistrement ex post ne prévient pas le premier dommage, et un historique signé prouve ce qui a été fait, non l'exhaustivité de ce qui est présenté — un registre négatif (PR refusées, régressions, incidents) serait nécessaire à une réputation, et n'est pas mentionné. ### Ce que la signature garantit, et ce qu'elle ne garantit pas | Garanti | Non garanti | |---|---| | l'événement a bien été produit par cette clé | que la clé ait produit tout ce qu'on en montre | | l'intégrité de chaque événement isolé | l'exhaustivité du lot présenté | | le lien agent → humain autorisant | la découvrabilité des événements hors du relais d'origine | Point d'architecture à ne pas attribuer à ce billet : le relais est source unique de vérité, sans réplication ni échange pair-à-pair. Cela vient de l'ARCHITECTURE.md de Block consolidé dans [[buzz-block-panorama-deep-research-2026-08-12]], et non de ce texte, qui n'en dit rien. Conséquence : la souveraineté proposée est un droit de sortie, pas une garantie de disponibilité. ### Interopérabilité Git : l'affirmation la plus vérifiable Verbatim : « 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. » Conséquences : le coût de sortie est faible par construction (un git clone récupère le code) et l'identité unique supprime la gestion de jetons. Nuance à conserver : seul le code est standard — la conversation, la revue, la liaison PR↔canal et l'historique de contribution vivent dans des event kinds Nostr propres à Buzz. Test réalisable en dix minutes : clone puis push depuis un client Git nu contre un relais Buzz, sans le CLI buzz. ### Inventaire annoncé vs inventaire livré Le premier paragraphe énumère six fragments à réunir ; la section « What's next? » liste ce qui existe. | Fragment nommé en ouverture | Présent dans l'inventaire du 18 août | |---|---| | « A bug report lands in one tool » | oui — issues | | « The discussion happens in another » | oui — canaux liés au projet | | « The fix lives on a branch somewhere else » | oui — hosted git, multi-dépôts | | « Review happens in a comment thread attached to a diff » | oui — PR, revues, commentaires en ligne | | « CI runs in another system » | non — citée dans les promesses, absente de l'inventaire | | « Release notes get written later » | non | Six fragments annoncés, quatre traités. Ne pas reprendre la liste « repos, branches, pull requests, issues, CI, or all the related conversations » comme un inventaire de fonctionnalités livrées. ### Distinction à réutiliser : exécuter n'est pas être présent | Ce qu'un terminal donne à un agent | Ce qu'une présence réseau ajoute | |---|---| | exécuter, écrire des fichiers | une identité stable que d'autres peuvent adresser | | un état local, jetable | un historique attaché qui survit à la session | | agir | être tenu pour responsable de ce qui a été fait | Cadre utile pour arbitrer entre un agent-outil (qu'on invoque) et un agent-membre (qu'on adresse). Corollaire non traité par le billet : une présence persistante est aussi une surface d'attaque persistante — voir [[valente-zalewski-beyond-zero-enterprise-security-ai-era-2026-07-20]]. ### « Context is (almost) all you need » Verbatim : « The more context we can make available, the better equipped the agents are, the more intelligent the whole network becomes. » La monotonie est postulée sans être argumentée : ni le coût du contexte, ni sa dégradation, ni sa sélection ne sont discutés, et le « (almost) » n'est jamais explicité. À mettre en regard du budget de tokens chiffré chez Block même par [[patel-block-buzz-teams-tokens-benchmarks-2026-08-06]]. ### Seule affirmation d'effet du billet « We've already seen a number of examples where agents understood context humans didn't and helped course correct otherwise unproductive directions. » Aucun exemple, aucun nombre, aucun critère de succès. Formulation correcte pour une reprise : « Block rapporte, sans les documenter, des cas où des agents ont réorienté des directions improductives à partir du contexte de canal. » Fiche à rouvrir si Block publie ces cas. ### Hygiène de citation 1. Citable comme intention architecturale de Block ; pas comme preuve de fonctionnement ni d'adoption. 2. Toujours porter la maturité annoncée : onglet Experiments, « fairly elementary », Buzz « still in beta ». 3. Distinguer les fonctionnalités montrées en capture, celles inventoriées dans « What's next? », et celles seulement nommées dans les phrases de promesse (CI, notes de version). 4. Les « agent trust protocols » sont une piste déclarée, sans schéma ni critère ni calendrier.