Jack Dorsey lance Buzz, qui combine chat d’équipe, agents IA et hébergement Git

• Block lance Buzz, un workspace open source qui relie employés, agents IA, conversations et dépôts logiciels au sein d’un même système d’identité, afin de réduire sa dépendance à Slack et GitHub
• Les messages, réactions, étapes de workflow, événements de code et validations sont stockés sous forme d’événements Nostr signés, avec paires de clés, appartenances aux canaux et pistes d’audit attribuées de la même façon aux humains et aux agents
• Les agents peuvent aller de la recherche dans les conversations à la soumission de patchs, la revue de code et l’exécution de workflows, tandis que les harnais Goose, Codex et Claude Code découplent le workspace des modèles sous-jacents
• L’auto-hébergement et la propriété des données sont proposés, mais toutes les lectures et écritures passent par un relais central unique ; l’opérateur doit donc assumer la disponibilité, les sauvegardes, la sécurité et les mises à niveau
• Chat, hébergement de code, automatisation, recherche et orchestration d’agents sont regroupés au même endroit, mais l’application mobile et les notifications push ne sont pas finalisées, et ni le taux d’adoption, ni les prix, ni le nombre de clients externes n’ont été communiqués

---

Un workspace unifié reliant humains et agents

• Buzz est un workspace open source auto-hébergeable qui place employés, agents IA, conversations et dépôts logiciels sous un même système d’identité
  • Jack Dorsey veut ainsi réduire la dépendance de Block à Slack et GitHub
  • Le dépôt public de Block documente aussi une build interne distincte adaptée au relais interne et aux fournisseurs d’agents de l’entreprise
• Autour d’un relais Nostr auto-hébergé, les messages, réactions, étapes de workflow, événements de code et validations sont stockés sous forme d’événements signés cryptographiquement
  • Employés comme agents disposent chacun d’une paire de clés unique, d’appartenances aux canaux et d’une piste d’audit
  • Grâce à l’identité partagée et aux événements signés, les agents peuvent participer au-delà du simple chatbot, comme des membres dont la responsabilité peut être retracée
• Les agents peuvent rechercher dans les conversations passées, parcourir des dépôts, soumettre des patchs, effectuer des revues de code, exécuter des workflows, modifier des canevas partagés et créer des canaux
  • Un CLI pour agents et des harnais Goose, Codex et Claude Code sont fournis afin de séparer les modèles sous-jacents du workspace
• La spécification du projet définit une forge logicielle intégrée utilisant le standard Git Smart HTTP
  • Les branches de fonctionnalités deviennent des canaux dédiés, où patchs, résultats d’intégration continue, commentaires de revue et décisions de fusion sont conservés dans le même historique
  • Les dépôts, conversations et historiques de workflow partagent un même index de recherche
• Les canaux, fils de discussion, messages directs, canevas partagés, médias, recherche, journaux d’audit, applications desktop et workflows basés sur YAML fonctionnent déjà
  • Des builds packagées sont fournies pour macOS, Windows et Linux, sous licence Apache 2.0

Architecture à relais unique et limites d’un produit encore jeune

• Dorsey a présenté Buzz comme un produit décentralisé et souverain, mais selon la documentation d’architecture, il n’existe aujourd’hui ni échange P2P d’événements entre relais, ni couche de gossip, ni fonction de réplication
  • Toutes les lectures et écritures passent par un relais unique qui authentifie les utilisateurs, vérifie les signatures, stocke les événements et les distribue
  • Les organisations possèdent leur propre relais, leur domaine et leurs données, et peuvent utiliser des paires de clés Nostr portables, mais au sein de chaque communauté ce relais reste le serveur d’autorité
  • Les hébergeurs peuvent exploiter plusieurs communautés isolées les unes des autres sur une infrastructure partagée
• L’auto-hébergement donne le contrôle de l’infrastructure et de l’emplacement des données, mais transfère à l’opérateur la responsabilité de la disponibilité, des sauvegardes, de la sécurité et des mises à niveau
  • Les événements signés facilitent l’attribution des actions et l’audit, sans pour autant éliminer les risques liés à l’exploitation du serveur
• Buzz peut être utilisé pour les tests et le développement, mais la documentation le classe à plusieurs reprises comme un produit inachevé
  • Le client mobile est en cours de développement et les notifications push ne sont pas encore disponibles
  • Les gates d’approbation de workflow comportent des composants de base de données, d’API et d’interface, mais pas encore de chemin d’exécution complet
  • La version 0.4.21 de l’application desktop est sortie le 21 juillet avec des ajouts et correctifs liés au contrôle par les agents, à l’authentification et à l’onboarding des workspaces
• Buzz vise à remplacer, au sein d’un même système d’événements, une partie du chat, de l’hébergement de code, de l’automatisation des workflows, de la recherche projet et de l’orchestration d’agents
  • Cette architecture unifiée peut réduire le travail d’intégration nécessaire pour fournir aux agents le contexte et les droits d’accès limités dont ils ont besoin
  • À l’inverse, les produits existants séparés par rôle permettent de remplacer un seul outil sans migrer toute la stack de développement
• Block est le premier cas client cité dans la documentation de Buzz, mais l’entreprise n’a communiqué ni taux d’adoption, ni prix, ni nombre de clients externes ; le projet en est aujourd’hui au stade de builds open source et d’appels à contributions

[GN⁺]

Commentaires de Hacker News

• Cette capture d’écran ressemble à une sorte de film d’horreur à la David Lynch. On dit « #engineering. Nouvelle direction. On migre le prototype vers Flutter » et des humains ainsi que des bots agents se mettent à discuter avec des noms mignons et des emojis du genre « J’ai fini la partie physique, qu’en est-il du shell UI @Honeybot ? »
  J’ai du mal à imaginer un monde où organiser le développement logiciel de cette façon paraît naturel, et le fait que ça utilise un truc qui ressemble à une blockchain fait aussi très typique
  https://github.com/block/buzz/blob/main/docs/assets/screensh...

  • Je me demande si la programmation du futur ne va pas susciter le même désespoir que Ian McKellen devant un fond vert. Un peu comme ce vétéran du théâtre shakespearien qui tournait The Hobbit sans vrais partenaires de jeu et s’est dit : « Mon métier, c’est de jouer avec d’autres personnes, pas tout seul. »
    https://www.theguardian.com/film/2013/nov/20/the-hobbit-gand...
  • L’une des raisons pour lesquelles je me suis lancé dans la recherche en IA quand j’étais jeune, c’était l’espoir qu’un jour il existerait des êtres intelligents capables de converser et d’interagir comme des humains. Maintenant que c’est réellement possible, tout le monde semble détester ça, mais moi j’aime toujours autant et je trouve cool l’idée de faire des agents IA des coéquipiers
    Cela dit, au lieu de simples copies qui ne font que flatter, il faut leur donner une vraie personnalité, afin que les différences entre agents soient nettes à la fois dans leurs capacités et dans leur comportement
  • Cet écran est une démo scriptée faite parce qu’il est difficile de synchroniser en temps réel les actions de plusieurs personnes et agents, et on peut aussi voir la PR correspondante dans le dépôt
    Il ne faut pas sous-estimer la mise en scène ludique quand il s’agit de rendre intuitivement perceptible quelque chose d’essentiellement nouveau. Comme chaque bot a un gestionnaire, des capacités et des permissions différents, son nom et son image servent de raccourci pratique pour distinguer les instances, et le côté mignon est optionnel
  • Il n’y a pas de blockchain ici. Nostr n’est qu’un standard de format de messages signés passant par de simples serveurs relais de stockage et retransmission
  • Comme tous les messages semblent être à 5 h 42, c’est probablement une capture faite avec des données de test préremplies ou une maquette basée sur cette capture

• Présenter ça comme « expliqué à un enfant de 5 ans » tout en disant « Buzz est un espace de travail open source auto-hébergé qui combine chat d’équipe, agents IA et hébergement Git via des événements Nostr signés » montre qu’on n’a pas tous la même idée du niveau attendu d’un enfant de 5 ans

  • C’est intéressant de voir comment ELI5, qui était à l’origine le nom d’un subreddit dérivé d’un fil AskReddit, est devenu une formule marketing courante dans la tech. Aujourd’hui, c’est presque un raccourci pour dire « explique à partir des premiers principes que le lecteur est supposé connaître », et beaucoup de gens du secteur semblent garder une certaine nostalgie du Reddit des années 2010
  • Il m’est déjà arrivé de taper eli5 (tâche) à un agent en craignant qu’il l’explique vraiment comme à un enfant de 5 ans. C’était une inquiétude irrationnelle, et l’agent comprend généralement l’intention réelle, contrairement aux commentaires sur HN
  • Je n’ai pas compris l’ELI5 que j’ai reçu hier non plus, donc l’étape suivante logique a été de demander ELI4
  • Ça veut plutôt dire : « Explique-le comme si tu le présentais à TechCrunch Disrupt »
  • Même en lisant Buzz, je n’y vois qu’un empilement de buzzwords et de jargon corporate, donc difficile de comprendre ce que ça fait réellement

• Je travaille chez Slack, mais je parle en mon nom. Le fait que des agents puissent voir tout ce que mes collègues et moi voyons est séduisant, mais dès qu’on veut réserver certaines informations à des personnes précises, ça se complique
  Il faut écrire et maintenir des règles d’accès par ressource assez complexes pour éviter que des agents multi-utilisateurs ne fassent fuiter des données. À l’inverse, les agents mono-utilisateur sont structurellement plus simples puisqu’ils agissent pour une seule personne, et l’essentiel est de les empêcher d’exporter des données privées vers un espace partagé sans autorisation explicite

  • Dans un vrai environnement collaboratif, les groupes privés sont ce qu’il y a de pire. J’aimerais que Slack ait un bouton pour publier tout un fil dans un canal public
  • Je suis peut-être biaisé parce que je viens d’Asana, mais je suis d’accord pour dire que les agents mono-utilisateur sont plus simples. Cela dit, des agents multi-utilisateurs qui comprennent tout le flux de travail restent extrêmement puissants
    Nous avons consacré beaucoup de réflexion et de temps à la protection de la vie privée et à éviter que les informations ne fuient vers les mauvais destinataires. Je n’ai pas encore essayé Buzz, mais j’apprécie les tentatives de penser autrement et de construire quelque chose d’intéressant
  • Dans Buzz, on dirait que les agents ne sont pas de simples intégrations d’apps, mais des utilisateurs de première classe. Si on crée un utilisateur nommé Claude et qu’on lui applique les ACL habituelles, est-ce qu’on a encore besoin de se soucier de savoir si c’est un humain ou un bot ?
  • Notre environnement d’exécution cloud distingue secrets partagés et secrets personnels. Les éléments authentifiés avec des secrets partagés peuvent être utilisés dans un environnement public, tandis que les éléments personnels ne sont accessibles que via des canaux de confiance, ce qui s’applique aussi à Slack ou Telegram
    L’agent Slack est très robuste sur ce point et garantit qu’aucune information privée ne fuit
  • On ne pourrait pas simplement utiliser l’ID du chat de groupe et des informations supplémentaires comme clé de conversation ?

• Désormais, quand je vois un nouveau projet logiciel, je pense d’abord à la part qui a été produite par des agents, et à l’instabilité ainsi qu’à la facilité d’abandon qui en découlent. Il y a 10 ans, j’aurais pu me faire une certaine idée de la qualité du produit, mais je ne parle pas spécifiquement de Buzz

  • Autrefois, la friction nécessaire pour construire quelque chose était en soi un signe qu’on y avait un minimum réfléchi, alors qu’aujourd’hui on a l’impression qu’on jette ça aux utilisateurs pour qu’ils déterminent eux-mêmes si ça a de la valeur
    Pour ce type de produit, les risques dépassent les avantages d’une adoption précoce, donc mieux vaut attendre quelques mois. Si le produit est viable sur le long terme, quelques mois de retard ne changeront pas grand-chose
  • La plupart des logiciels finissent par disparaître de toute façon, qu’ils utilisent ou non des agents, donc cette façon de penser a ses limites. Google a lui aussi lancé en 2010, avant les LLM, un produit social similaire appelé Google Buzz, qui a été abandonné 16 mois plus tard
    L’essentiel, c’est de savoir si le projet trouve son adéquation au marché ; le fait qu’il existe encore dans 2 ans est moins fortement lié à la qualité du code que les ingénieurs aiment à le croire
  • Je n’ai plus envie d’être un early adopter ; il me faut au moins 6 mois de validation pour voir si ce n’est pas juste un phénomène passager
  • Le plus sûr est de partir du principe que tout a été généré par des LLM
  • Le fait que l’abandon soit devenu si facile est bien réel. On fait générer une fonction et ses tests par l’IA, puis on fait modifier la fonction par l’IA, et quand les tests cassent, on efface tout avant de refaire générer les tests par l’IA

• J’ai travaillé autrefois chez Slack. C’est bien de remettre en cause le statu quo du chat, mais je reste sceptique sur la capacité de Slack et Teams à survivre à l’ère des agents ou à évoluer jusqu’à ce niveau
  Je me demande toutefois si Nostr est vraiment le bon protocole. Dans les grandes entreprises, il faut gérer d’innombrables clients, dont les téléphones et les agents locaux, ainsi que des agents par équipe. La structure d’identité actuelle convient aux agents hébergés de façon centrale, mais on ne sait pas si les agents personnels réutilisent les identifiants de l’utilisateur ou s’ils sont distingués séparément
  Je doute aussi que Git doive être une dépendance indispensable. Cela peut être nécessaire chez Block, mais cela ajoute de la complexité, donc on pourrait aussi séparer cela en fusionnant les événements de l’hébergeur de gestion de versions dans le journal d’événements de Buzz
  Je me demande aussi quels problèmes surgiront quand de nouvelles fonctions apparaîtront, comme lorsque Sol et Claude rendent des composants natifs dans la fenêtre de chat pour concrétiser des changements de design. J’aimerais aussi savoir pourquoi Rust a été choisi et quelles alternatives ont été étudiées

  • Un compromis de type Signal semble meilleur. Slack est devenu difficile à déloger des relations professionnelles de bureau, mais dans un contexte exposé à des cyberattaques 24 h/24, il serait préférable d’avoir une garantie de confidentialité et de sécurité via un système à divulgation nulle de connaissance plutôt que des promesses de l’entreprise
    Signal offre la meilleure expérience de messagerie multiplateforme parmi les clients que j’ai utilisés avec des groupes d’amis, et si on ajoutait une structure de type Slack à son architecture actuelle, cela aiderait à réduire le problème des canaux trop bruyants
  • Les informations partagées comme le code et les fichiers deviennent de plus en plus importantes pour maintenir l’alignement entre humains et agents, et comme les entreprises nativement IA dépendront davantage du code, l’intégration Git est logique
  • Je me demande pourquoi Rust paraît être un mauvais choix. D’après mon expérience de lancement de logiciels pour dispositifs médicaux, il a été excellent pour garder le code écrit par l’équipe cohérent et précis

• Google Buzz et Wave sont arrivés bien trop tôt dans ce monde
  https://en.wikipedia.org/wiki/Google_Buzz

  • On ne peut toujours pas créer un label Buzz dans Gmail
  • Dès que je l’ai vu, j’ai pensé à Google+ et à Buzz

• Mettre des bots dans le chat d’équipe n’est pas une mauvaise idée, donc j’expérimente depuis plusieurs mois. Slack fonctionne, mais aligner toutes les autorisations est pénible, et il faut recommencer pour chaque nouveau bot
  J’ai essayé Matrix comme alternative auto-hébergée, mais le chiffrement de bout en bout était trop strict et gênait le partage d’informations avec les bots. Je suis passé à Zulip il y a quelques semaines, et l’installation, la création d’utilisateurs bots et l’automatisation ont toutes été simples. L’automatisation faite avec Openclaw a été remplacée par du code basé sur Haystack dans un état moins chaotique
  Je l’ai appris après l’installation, mais la direction de Zulip a été recrutée par Anthropic. Jack Dorsey semble l’avoir annoncé en premier, mais Anthropic pourrait aussi avoir des projets similaires
  Les agents à l’échelle de l’équipe sont tout à fait pertinents. Plus l’organisation grandit, plus le coût de la collaboration augmente, ce qui en fait un bon candidat à l’optimisation par l’IA, et plus l’usage de l’IA augmente, plus il devient nécessaire de partager et de coordonner ce que l’on fait dans des canaux publics. Le chat d’équipe convient aussi bien aux processus complexes incluant des garde-fous communs et des relais entre humains et agents

  • Je me demande ce que vaudrait XMPP

• Cela peut occuper une niche utile, mais Anthropic et OpenAI pourraient très bien imposer leur propre produit dans les 6 à 12 mois
  En regardant les forges Git pour essaims d’agents, Radicle semblait manquer d’une couche d’identité, mais son modèle fédéré COB avait l’air intéressant, et Tangled n’a pas de support des dépôts privés, mais sa couche sociale était solide. En revanche, le fait de modéliser les issues comme des posts plutôt que comme des objets possédés par le dépôt paraît étrange
  Il y a donc une place pour une forge pensée d’abord pour les agents privés. Anthropic va déjà dans cette direction, et son produit le plus récent, Tag, est un modèle d’authentification pour exécuter des agents de façon asynchrone dans Slack
  L’étape suivante pourrait naturellement être une forge. Si l’UI des agents cesse de passer par GitHub, Anthropic pourra librement remplacer l’implémentation interne, et le chat multi-utilisateur ainsi que la gestion des dépôts et des projets ressemblent aux prochains composants de la plateforme

  • Je construis une nouvelle forge de code https://juju.bi. Ce n’est pas un produit orienté agents, mais en dehors de l’évolutivité, je ne vois pas de fonctions particulièrement nécessaires aux agents

• Si Slack existe en grande partie, c’est parce qu’IRC était insuffisant, faute de prendre en charge nativement l’historique des canaux, la recherche, etc. Pour que les agents IA prospèrent, Slack devra soit ouvrir complètement son réseau sous forme de protocole, soit finir par être remplacé
  J’aimerais que Slack adopte un chat basé sur AT Protocol et que des applis comme Buzz l’implémentent. Les utilisateurs pourraient avoir des handles de domaine comme @yourname.com, et les agents @agent1.yourname.com, tout en gardant un contrôle total

  • Je ne vois pas pourquoi ce serait à Slack de faire prospérer les agents. Je constate directement, à l’échelle du secteur, un renversement des priorités où l’on modifie les flux de travail pour l’IA ; les outils doivent fonctionner pour les humains, pas l’inverse
  • C’est similaire aux comptes bot et puppet de Matrix
  • Si j’ai aimé Slack au départ, c’est parce que c’était « IRC avec des commodités modernes ». Depuis qu’il a perdu face à Microsoft et a été vendu à Salesforce, il stagne de fait, et la plupart des changements ont rendu le produit pire
  • Le système d’autorisations ATProto, encore non finalisé, ne fournit pas le niveau de contrôle fin exigé par les entreprises. Des fonctions comme les groupes seront implémentées dans des app views, ce qui les centralisera de fait, et les ACL sont une approche datant de deux générations dans l’histoire de la gestion des identités et des accès
    Le chat non plus n’est pas un format particulièrement adapté à PDS/ATP. Roomy l’a aussi compris et construit son propre protocole dédié ainsi que des bridges
  • C’est plus proche de HipChat que de Slack, avec environ 15 ans d’erreur de timing

• C’est la première fois que je vis l’expérience désagréable d’un mouvement du curseur retardé de 0,5 seconde sur un site web