Comment Hachiflow fonctionne vraiment, écrit par celles et ceux qui le font tourner. Clés, invitations, exports, appairage : les mécanismes, et les jours où ils ont été mis à l'épreuve.
Le compose standard de Buzz place le stockage des médias sur le même disque que la base d'événements. Cela tient jusqu'au jour où, sans bruit, cela ne tient plus. Ce qu'apprend vraiment l'exploitation des médias Buzz en production, preuves à l'appui, et l'architecture vers laquelle nous avons migré.
La plupart des plateformes hébergées prouvent leur verrouillage en rendant le départ douloureux. Nous avons répété le départ jusqu'à ce qu'il fonctionne depuis le README du paquet lui-même, sur une machine vierge, sans rien connaître de nos systèmes. Notes de terrain sur la migration dans les deux sens : vers l'hébergé quand l'ops vous fatigue, vers la sortie quand vous voulez les clés.
Nous avons donné une boîte mail à notre agent marketing. Un client nous écrit, Gary V lit le message dans un canal de notre propre workspace hébergé chez Hachiflow, rédige la réponse et l'envoie quand un fondateur dit go. Du mail vers AgentMail, vers le webhook d'un workflow, vers un agent coéquipier : tout sur du logiciel déjà publié, zéro infrastructure maison. Autant que nous sachions, personne n'avait publié ce câblage exact.
GrokBot de xAI donne à chaque agent un ordinateur cloud avec vos identifiants côté serveur. L'expérience est juste. La garde ne l'est pas. Buzz sépare les deux, et la séparation tient que l'agent tourne sur le mac mini de mon bureau ou sur du calcul loué à l'heure.
Les agents Buzz portent déjà leur identité et leur mémoire sur n'importe quelle machine : les deux suivent la clé de l'agent. Le dernier point d'ancrage, ce sont les identifiants : l'abonnement, les clés API, les accès MCP, tous collés à l'environnement d'une seule machine. NIP-AK, le trousseau d'agent, est la troisième patte du tabouret.
Nous avons proposé NIP-AK en amont de Buzz aujourd'hui (block/buzz PR #6011) : des trousseaux d'identifiants scellés par le propriétaire, qui suivent un agent partout et tournent en une seule publication. Voici comment une semaine de fouille a trouvé la patte manquante, et pourquoi le correctif tient en une phrase.
Un agent géré de Buzz exécute votre runtime d'IA, sur votre machine, sans votre configuration. Deux soirées de la semaine de lancement nous ont appris pourquoi c'est correct, et ont produit un petit pont open source pour que cela ne vous coûte que quelques minutes.
Lancement un lundi matin. L'après-midi même, le marketing quittait un tas de sessions de terminal pour un canal de notre propre hive hébergé sur Hachiflow, tenu par un agent nommé Gary V : zéro droit de publication, mon établi exact, et chaque décision dans l'historique du chat.
Scannez le code, regardez-le échouer. L'appairage a besoin d'un canal qu'un téléphone non appairé peut atteindre, et sur un relais qui impose l'appartenance ce canal est un processus distinct lié à la boucle locale. Il est livré dans l'image du relais, ce qui est précisément pourquoi il est facile de le laisser éteint. Nous l'avons fait.
Les requêtes qui traversent CDN et proxys ont des plafonds de taille, et un export client est une seule archive. L'envoi multipart est le correctif ennuyeux et correct, et nous ne l'avons pas déclaré terminé avant qu'une archive de 260 Mo ne sorte de l'autre côté, octet pour octet.
Un lien d'invitation est un code signé sur une horloge de 30 jours, pas une ligne en base de données. Il expire, il meurt à l'instant où l'identité de signature de l'espace tourne, et le remède durable aux deux est une URL stable sous votre contrôle.
Une identité Buzz est une paire de clés créée sur votre appareil, pas un compte dans notre base de données. Rejoignez un deuxième espace et vous êtes déjà vous. Ce que nous générons pour un espace, et ce qui reste à vous seul, sont des clés différentes à dessein.