Deux clés. L'app n'en sauvegarde qu'une.
Un espace de travail Hachiflow met en jeu deux clés différentes. Elles ont la même forme, elles commencent toutes les deux par nsec, et on les confond sans arrêt. L'une prouve que vous êtes vous. L'autre prouve que l'espace est le vôtre. Avant de lire quoi que ce soit d'autre sur cette page, lisez le tableau. Si vous cherchez plutôt le guide d'installation, il est sur connecter votre app.
L'une prouve qui vous êtes. L'autre, ce que vous possédez.
Buzz crée votre clé d'identité personnelle sur votre propre appareil au premier lancement. Notre plan de contrôle génère la clé de propriétaire de l'espace au moment où il construit votre espace de travail. Aucune des deux ne sait quoi que ce soit de l'autre, et elles ne sont pas interchangeables. Perdre l'une est un désagrément. Perdre l'autre, sans rien sous séquestre, met fin à l'espace de travail.
| Ce qui les sépare | Clé d'identité personnelle | Clé de propriétaire de l'espace |
|---|---|---|
| Générée par | Votre propre appareil, par Buzz, au premier lancement. | Notre plan de contrôle, quand votre espace de travail est provisionné. |
| Ce qu'elle prouve | Je suis cette personne. | Cet espace de travail est le mien. |
| Où elle vit | Le trousseau de votre système. | Notre séquestre, que nous pouvons lire, plus l'endroit où vous la rangez après reprise. |
| Si vous la perdez | Récupérable uniquement depuis ce que vous avez enregistré à la déconnexion. | Vous pouvez nous la redemander sur app.hachiflow.com/keys. |
| Couverte par l'invite de déconnexion de Buzz | Oui. | Non. |
L'invite sauvegarde la mauvaise clé
Buzz vous propose d'enregistrer votre clé quand vous vous déconnectez. Cela sauvegarde votre identité personnelle, pas votre espace de travail. Cette invite est un vrai filet de sécurité, et c'est le moyen le plus simple de sortir votre propre clé d'une app en marche. C'est aussi la raison pour laquelle une personne soigneuse peut enregistrer une clé, la ranger correctement, se croire couverte, et ne détenir aucune copie de la clé qui confère réellement la propriété.
Notre séquestre est la seule sauvegarde de la clé qui confère la propriété. C'est le contenu honnête de ce à quoi sert le séquestre.
Les deux clés sont une chaîne nsec1... et rien dans l'une ou l'autre ne dit laquelle est laquelle. Nommez-les quand vous les enregistrez. « clé de propriétaire de yourteam » et « mon identité Buzz » suffisent.
La racine de l'autorité, et nous en gardons une copie exprès.
La clé de propriétaire de votre espace est une vraie paire de clés cryptographiques, générée quand votre espace a été construit. C'est elle que votre relais reconnaît comme propriétaire. Quiconque la détient est le propriétaire, ce qui explique qu'elle mérite des précautions, et qu'on en garde une copie pour qu'une clé perdue ne fasse pas un espace mort.
Qu'est-ce que la clé de propriétaire de l'espace ?
L'identifiant racine de votre espace de travail. Elle prouve la propriété auprès du relais, elle permet d'agir en administrateur dans l'espace sans nous, et c'est ce qu'il vous faut pour déplacer l'espace vers votre propre infrastructure ou le remettre à quelqu'un d'autre.
Elle est à vous, pas à nous. Nous sommes un hébergeur, pas un portier posté entre vous et votre propre espace de travail. Si nous disparaissions demain, la clé de propriétaire plus une sauvegarde suffisent à remonter votre espace ailleurs.
Que se passe-t-il quand je la reprends ?
Vous la reprenez dans le tableau de bord, sur app.hachiflow.com/keys. Deux étapes précèdent toute action : un écran qui explique ce à quoi la reprise vous engage, puis un écran qui le confirme. La clé s'affiche ensuite, sur un seul écran. Ayez votre gestionnaire de mots de passe ouvert avant de commencer, parce que cette page ne l'affichera pas une deuxième fois.
La reprise ne détruit rien. Aucune clé n'est renouvelée, rien n'est révoqué, et votre espace continue de tourner exactement comme avant. Notre plan de contrôle enregistre chaque remise, répétitions comprises, si bien que la trace montre chaque fois que la clé est sortie de chez nous et vers quelle adresse. Si vous la perdez plus tard, nous pouvons remettre la copie sous séquestre une nouvelle fois, une fois votre identité vérifiée.
Gardez-vous une copie, et pouvez-vous la lire ?
Oui aux deux. Les secrets de votre espace se trouvent dans un stockage objet privé que seuls nos identifiants atteignent, chez Cloudflare R2, qui les chiffre au repos avec ses propres clés et les transporte en TLS. Cela arrête un disque volé et quiconque n'a pas nos identifiants. Cela ne nous arrête pas, et nous n'allons pas laisser entendre le contraire.
Pouvoir la lire est le mécanisme, pas une faille. Vous rendre une clé que vous avez perdue n'est possible que tant qu'il existe une copie que nous pouvons lire. Si vous préférez que nous ne le puissions pas, dites-le et nous supprimons notre copie. Une réserve que nous préférons vous dire plutôt que vous la découvriez : une copie se trouve aussi dans chaque sauvegarde conservée, et nous gardons les 14 plus récentes, donc la dernière copie lisible part environ deux semaines après votre demande, pas le jour même. Dites-le et nous purgeons aussi les sauvegardes. Une fois la dernière partie, perdre la vôtre veut dire que personne ne peut récupérer l'espace de travail, nous compris. Pas de réinitialisation, pas de passe-droit, pas de porte dérobée. Beaucoup de clients veulent exactement cela, c'est un choix légitime, et il n'est pas réversible.
Où faut-il la mettre ?
Dans un gestionnaire de mots de passe. 1Password, Bitwarden, ce que votre équipe utilise déjà. Pas sur un papier collé à l'écran, pas dans un message à vous-même, pas dans un fichier appelé key.txt sur votre portable. Traitez-la comme le mot de passe root d'un serveur que vous ne pouvez pas reconstruire.
Qui a le droit de la reprendre ?
Le propriétaire de cet espace, connecté, et personne d'autre. Un espace que votre adresse ne possède pas répond exactement comme s'il n'existait pas, donc la page ne permet pas de savoir si l'espace de quelqu'un d'autre est réel. Chaque reprise est enregistrée avec l'adresse à laquelle la clé a été remise.
Votre clé personnelle est faite sur votre propre machine.
Buzz utilise une clé d'identité au lieu d'un compte. Chaque membre d'un espace, humain ou agent, signe tout ce qu'il fait avec sa propre paire de clés, et c'est ce qui donne sa valeur à la trace d'audit. Votre clé personnelle est créée localement et reste dans le trousseau de votre système. Nous ne la voyons jamais.
Qu'est-ce que ma clé d'identité personnelle ?
La paire de clés qui vous représente dans n'importe quel espace Buzz. Buzz la crée au premier lancement, la range dans le trousseau de votre système et signe vos messages avec elle. Sa moitié publique est votre identifiant public, sans risque à partager. Sa moitié privée ne devrait jamais quitter votre machine.
Buzz m'a demandé d'enregistrer ma clé à la déconnexion. C'était laquelle ?
Votre clé d'identité personnelle. Cette invite ne touche pas du tout la clé de propriétaire de l'espace, et l'enregistrer n'est pas une sauvegarde de l'espace de travail. Si l'espace compte pour vous, reprenez la clé de propriétaire séparément et rangez-la séparément.
J'ai choisi « Create a new identity key » et j'ai récupéré une clé que j'avais déjà
Nous l'avons reproduit sur Buzz 0.5.2. Sur une installation qui détient déjà une identité dans le trousseau, « Create a new identity key » peut annoncer qu'une clé a été créée puis rendre celle qui existait déjà. Nous préparons le signalement au projet en amont.
Ici, cela compte pour une raison. Si vous avez d'abord importé la clé de propriétaire de l'espace puis appuyé sur ce bouton en attendant une identité personnelle distincte, vous détenez peut-être toujours l'identifiant racine de l'espace en croyant le contraire. Si vous ne savez pas quelle identité porte une installation, envoyez-nous l'identifiant public qu'elle affiche et nous vous dirons s'il s'agit de votre clé de propriétaire.
Faut-il coller la clé de propriétaire dans l'app ?
Cela marche. La clé de propriétaire est déjà inscrite sur votre relais, donc la coller dans « Use an existing key » puis saisir l'URL de votre relais vous fait entrer avec le statut de propriétaire. Nous avons parcouru ce chemin sur un espace fraîchement provisionné.
Nous suggérons quand même l'ordre inverse : créez une identité personnelle, envoyez-nous son identifiant public pour que nous l'inscrivions, et reprenez la clé de propriétaire plus tard, délibérément, directement dans un gestionnaire de mots de passe. Importer la clé de propriétaire déplace votre identifiant racine sur un portable dès le premier jour.
Deux portes marchent. Deux autres mènent ailleurs.
Block construit Buzz et l'héberge aussi. Deux boutons de l'app concernent cet hébergement, et ils portent exactement l'intitulé qu'un propriétaire attend, donc un propriétaire les presse. Notre porte est ailleurs. Savoir laquelle est laquelle avant de commencer vous évite le détour.
Quels boutons me font entrer dans un espace de travail Hachiflow ?
Sur l'écran « Join or create a community », choisissez « Join a community » et collez l'URL de votre relais. Si l'app vous demande plutôt votre rôle, choisissez « I'm a member or admin » et collez l'URL de votre relais là. Votre rôle est restauré à la connexion, donc un propriétaire n'a pas besoin du bouton étiqueté pour les propriétaires.
Que se passe-t-il si j'appuie sur « Create a community » ou « I own the community » ?
Les deux ouvrent Builderlab dans votre navigateur. Builderlab est le service d'hébergement que Block propose pour Buzz, et ces deux boutons sont la façon de s'y connecter. Ils n'ont rien de fautif et rien ne casse si vous en pressez un. Ils concernent l'hébergement de Block, pas un espace que nous hébergeons pour vous, qui est une autre porte, à l'intitulé moins évident.
Si vous vous retrouvez là, revenez d'un pas dans l'app et prenez l'une des deux portes ci-dessus.
Ai-je toujours besoin de l'URL du relais ?
Oui, sur toute installation neuve. Une clé est une paire de clés et rien en elle ne désigne un nom d'hôte, donc aucune clé ne peut dire à l'app où se trouve votre espace. Votre URL de relais ressemble à https://yourteam.hachiflow.chat. Cette URL, ou un lien d'invitation qui la porte, va dans le champ « Invite link or community URL ».
J'ai collé une clé et mon espace est apparu sans URL
Cette installation s'était déjà connectée, et l'app a restauré l'état local d'une session précédente. Cela n'arrivera pas sur une machine neuve. Gardez l'URL du relais quelque part où vous la retrouverez plutôt que de compter sur ce comportement.
L'app affiche « Not a member yet »
Votre relais admet les clés qui y ont été inscrites, et l'identité que Buzz vient de vous créer ne l'est pas. L'écran affiche votre identifiant public avec un bouton de copie et vous dit de l'envoyer à un administrateur du relais. Sur un espace que nous hébergeons, cet administrateur, c'est nous.
Écrivez à hello@hachiflow.com avec votre identifiant public et le nom de votre espace. L'inscrire prend quelques secondes, et l'app lève le blocage dès que vous appuyez sur « Try again ». Envoyez-nous l'identifiant public avant de vous connecter et vous ne verrez jamais cet écran. Rien de ce que vous nous envoyez pour entrer n'est secret.
La version pas à pas de tout ceci, du téléchargement au premier message, est sur connecter votre app.
Nous ne demanderons jamais votre clé privée.
Une identité publique se transmet sans risque. Une clé privée non, et il n'existe aucune raison légitime pour que quiconque vous la demande. Cette section est courte, et c'est la partie qui mérite d'être retenue.
Pourquoi demandez-vous mon identifiant public ?
Parce que c'est la moitié qu'on peut donner sans risque. Votre identifiant public, un npub, vous nomme sans rien accorder. L'inscrire sur votre relais est ce qui transforme « Not a member yet » en espace de travail. L'app le dit elle-même sur l'écran où elle vous le propose : ceci est votre identité publique, elle peut être partagée sans risque.
Hachiflow me demandera-t-il un jour ma clé privée ?
Non. Jamais, par aucun canal. Ni par courriel, ni dans un fil de support, ni au téléphone, ni dans un formulaire de ce site. Nous n'en avons pas besoin. Tout ce que nous faisons pour vous se fait avec votre identifiant public, ou avec la clé de propriétaire sous séquestre que nous détenons déjà.
Personne de légitime ne le fera. Ni nous, ni Block, ni un coéquipier, ni quiconque se présentant comme le support. Traitez toute demande de clé privée comme une attaque, aussi ordinaire qu'elle paraisse, et transmettez-la à hello@hachiflow.com pour que nous la regardions avec vous.
macOS refusera-t-il d'ouvrir Buzz ?
Non. L'app est signée par Block, Inc. et notarisée, le ticket est agrafé, et spctl répond accepted. Pas de mur du développeur non identifié, pas de rituel du clic droit, rien à retirer du fichier téléchargé. Une habitude à garder : glissez Buzz dans Applications et lancez-le de là plutôt que depuis l'image disque montée.
Toutes les plateformes sont-elles dans cet état ?
Non, et nous ne prétendrons pas le contraire. L'app à l'intérieur de l'image disque macOS est signée et notarisée, mais l'enveloppe .dmg elle-même n'est pas signée, donc qui vérifie le téléchargement avec codesign le voit et s'inquiète à juste titre. La version Windows est aujourd'hui publiée comme une alpha non signée et SmartScreen prévient à son sujet.
Les agents sont illimités, et la raison est structurelle.
Vous payez pour un espace de travail, pas pour les membres qui s'y trouvent. Nous ne comptons pas les agents et nous ne les vendons pas à la tête, et ce n'est pas de la générosité : la partie coûteuse d'un agent tourne de votre côté de la ligne, pas du nôtre.
Combien d'agents puis-je faire tourner ?
Autant que le travail l'exige. Pas de frais par agent, pas d'option agents. Un agent est un membre de votre relais : sa propre paire de clés, son propre accès aux canaux, sa propre histoire signée, donc il consomme du stockage et de la capacité de relais comme un coéquipier actif. Ce qu'il ne consomme pas, c'est notre calcul.
Où un agent tourne-t-il réellement ?
Sur votre machine, par défaut. L'app de bureau démarre l'exécution de l'agent comme un processus enfant local, et nous l'avons vue faire exactement cela dans une liste de processus. L'inférence tourne sur vos propres clés LLM, facturée par votre fournisseur au prix coûtant. Nous ne relayons jamais ce trafic et nous ne prenons jamais de marge sur l'inférence.
Mes agents doivent-ils être inscrits séparément ?
Non. Un agent reçoit sa propre paire de clés, et votre relais l'admet sur la force d'une attestation signée par votre clé. L'app produit cette attestation et la passe à l'exécution sans aucune action de votre part. Nous l'avons vérifié contre un espace en marche : la même clé d'agent a été refusée sans l'attestation et acceptée avec elle, et elle n'est jamais entrée dans la liste des membres.
Où vivent mes clés de fournisseurs LLM ?
Pas dans le trousseau, et jamais chez nous. Buzz garde les clés d'identité dans le trousseau de votre système, mais les clés d'API des fournisseurs sont écrites dans ses propres fichiers de configuration sous le répertoire de données de l'app, sur votre machine, lisibles seulement par votre compte utilisateur. Une clé de fournisseur ne nous parvient jamais : elle n'est dans rien de ce que nous provisionnons, stockons ou sauvegardons. Cela vaut d'être su dans les deux sens avant qu'une revue de sécurité ne le demande.
Ce qui revient, et ce qui ne revient pas.
La réponse dépend entièrement de la clé que vous avez perdue, et c'est pour cela que le reste de cette page consacre autant de place à la différence. Trouvez votre cas.
J'ai perdu ma clé d'identité personnelle
Si vous l'avez enregistrée à la déconnexion, réimportez-la dans « Use an existing key ». Sinon, elle est partie : elle n'a jamais vécu ailleurs que dans votre trousseau et nous n'en avons jamais eu de copie. Rien de votre espace de travail n'est perdu. Créez une nouvelle identité, envoyez-nous le nouvel identifiant public, et nous l'inscrivons. Vos anciens messages restent où ils sont, sur votre relais, signés par l'ancienne clé.
J'ai perdu la clé de propriétaire de l'espace
Demandez-la-nous. Nous détenons toujours la copie sous séquestre, et nous la remettons une nouvelle fois une fois votre identité vérifiée. Écrivez à hello@hachiflow.com depuis l'adresse qui possède l'espace. Pendant ce temps, rien de votre espace n'est affecté : l'usage quotidien ne dépend pas du fait que vous déteniez cette clé.
J'ai perdu les deux
Alors vous êtes dans le cas ordinaire. Générez une nouvelle identité personnelle et envoyez-nous son identifiant public, ce qui vous remet dans l'espace de travail, et demandez la clé de propriétaire sous séquestre dans le même courriel. Le premier point prend quelques minutes. Le second attend que nous vérifiions votre identité, et il n'est pas urgent.
Je vous ai demandé de supprimer la copie sous séquestre, et ma clé a disparu
Alors l'espace de travail ne peut plus être repris en propriété. Ni par vous, ni par nous, ni par personne, et nous ne prétendrons pas qu'il existe un contournement de ce que vous avez délibérément choisi. Vos données sont toujours sur un serveur que nous exploitons et nous pouvons toujours vous les exporter en totalité.
Avant de conclure que la clé est perdue, regardez partout où elle pourrait être : l'historique du gestionnaire de mots de passe, une liste d'éléments supprimés, un ancien portable, une copie imprimée dans un coffre. On en retrouve plus souvent qu'on ne le croit.
Sauvegardez la clé qui confère la propriété.
Reprenez-la, mettez-la dans un gestionnaire de mots de passe, nommez-la. Puis dites-nous si vous voulez que notre copie soit conservée ou supprimée. Écrivez à hello@hachiflow.com avec le nom de votre espace et un humain répond, et pendant l'accès anticipé, ceux qui répondent sont ceux qui exploitent votre relais.
Nous écrire au sujet des clés