Buzz

Buzz — Technologie. architecture : Relais Nostr écrit en Rust (Axum WS + REST) sous Apache 2.0, avec Postgres pour les événements et la recherche plein texte, Redis pour pub/sub, présence et saisie, stockage objet S3/MinIO pour les médias via Blossom, client desktop Tauri + React ; 127 event kinds, NIP-01, NIP-42, NIP-98, NIP-34 · code source : Ouvert : code, spécifications de protocole, vecteurs de test, sections sécurité et modèles formels publiés sur github.com/block/buzz ; site buzz.xyz · confidentialité : Télémétrie et annulation en messages éphémères chiffrés, mémoire et comptabilité de coûts chiffrées mais durables ; le serveur ne voit que des métadonnées de routage. L'inférence peut être routée vers la machine d'un pair autorisé, le trafic modèle chiffré circulant directement entre eux · décentralisation : L'ARCHITECTURE.md pose le relais comme source unique de vérité, sans échange pair-à-pair, sans gossip ni réplication : un relais autoritaire par communauté, donc un point de défaillance unique. La décentralisation revendiquée est une souveraineté organisationnelle (auto-hébergement + identité portable), pas une redondance réseau · définition : Espace de travail auto-hébergeable de Block (21 juillet 2026, Apache-2.0) bâti sur Nostr, où humains et agents partagent les mêmes canaux ; chaque participant est une paire de clés, chaque événement est signé dans un journal append-only · identité des agents : Chaque agent reçoit sa propre paire de clés ; son propriétaire signe une autorisation étroitement délimitée et l'agent signe son travail en son propre nom — « authorization does not erase authorship ». Révocation d'un agent sans remplacement de l'identité humaine, déconnexion en cascade si le propriétaire est retiré · interopérabilité : Claude Code, Codex, goose et tout agent parlant Agent Client Protocol peuvent y travailler ; changer de modèle ou de harness préserve l'identité, les permissions et l'historique du projet · limites de sécurité : Autorisation à la maille du canal et non par outil ou action ; agents lancés en --dangerously-skip-permissions hors bac à sable ; pas d'observabilité de l'activité des agents ; journal signé tamper-evident mais non tamper-resistant ; messages non chiffrés de bout en bout sur le relais hébergé · maturité : Version 0.4.21 ou 0.4.22 au lancement selon les sources, puis 0.5.x ; dépôt créé le 6 mars 2026, premières releases publiques le 3 mai 2026, lancement public le 21 juillet 2026. Environ 25 900 étoiles GitHub à la mi-août 2026. Binaires Windows non signés, docs éparses, UI de forge Git précoce ; aucun prix publié pour l'hébergement géré · positionnement : Présenté aux actionnaires comme un système interne de collaboration d'agents, de communication et de dépôts de code destiné à réduire les délais de coordination — cadrage productivité, complémentaire du cadrage ouverture protocolaire (Apache-2.0, Nostr, ACP) documenté ailleurs dans ce corpus · rôle : Destination déclarée des enseignements de Berd : l'espace partagé humains+agents · statut : Workspace humains+agents sur Nostr, en bêta au 18 août 2026 · stockage Git : Dépôts stockés en packfiles immuables adressés par contenu sur stockage objet, plus un pointeur de manifeste mutable avancé par compare-and-swap conditionnel qui constitue le point de commit ; protocole spécifié en TLA+ et model-checké, avec suite de conformité obligatoire par backend · vérification formelle : Spécification d'isolation multi-tenant mécanisée en TLA+, propriétés d'autorisation vérifiées en Tamarin, protocole de stockage Git model-checké — niveau de formalisme inhabituel pour une version 0.x, mais portant sur l'identité et le stockage, non sur l'autorisation d'outil · équipes d'agents : Les agents s'appellent entre eux : un SmartBee délègue un sous-ensemble à un WorkerBee, attend, relit et renvoie, sans relais humain. Chaque agent a un nom, une persona, une mémoire et sa propre présence dans le canal — un siège plutôt qu'une session