La plupart des projets d’IA et de cryptomonnaies que je découvre commencent par le jeton et brodent ensuite une histoire autour. Kite m’a donné l’impression de suivre la démarche inverse, et c’est ce qui m’a donné envie de continuer à lire.
Ce qui m’a marqué, ce n’est pas la vitesse. C’est la séparation des identités. L’utilisateur à la racine, un agent en dessous avec une autorité déléguée, puis une session qui expire. Ça ressemble à de la paperasse jusqu’à ce qu’on imagine l’alternative… un agent disposant de la clé complète d’un portefeuille et d’une consigne vague du genre « achète ce qu’il faut ». Un mauvais prompt, un plugin compromis, et le solde disparaît.
Avec une couche de session, le pire scénario se limite au budget accordé à cette seule tâche. À mon avis, c’est l’idée la plus concrète de toute la conception. Des plafonds de dépenses et des limites de temps appliqués sur la chaîne, plutôt que de simples promesses dans une page de conditions d’utilisation.
J’ai tout de même une réserve. Les limites ne protègent que les personnes qui les définissent correctement. Depuis des années, je vois des utilisateurs passer les écrans OAuth sans lire la moindre autorisation. Pourquoi en irait-il autrement avec les budgets des agents ? Certains fixeront le plafond à « illimité » parce que, sinon, la tâche échoue sans cesse. La chaîne peut faire respecter une règle. Elle ne peut pas en rédiger une qui soit judicieuse.
Le véritable test pourrait donc bien être les paramètres par défaut. Est-ce que les outils incitent les utilisateurs ordinaires à choisir des limites strictes et peu excitantes… ou est-ce que la facilité l’emporte ?
$KITE L’utilité se déploie par étapes : d’abord les incitations, puis le staking, la gouvernance et les frais. C’est la gouvernance que je suivrais de près, car quelqu’un finira par décider de ce que signifie un « paramètre sûr par défaut » pour tout le monde.
Je suis encore en train de lire la documentation, alors considérez ceci comme un avis provisoire.
Cette décision devrait-elle revenir au protocole ou à chaque utilisateur ? #KiteBBW
@KITE AI 中文
Ce qui m’a marqué, ce n’est pas la vitesse. C’est la séparation des identités. L’utilisateur à la racine, un agent en dessous avec une autorité déléguée, puis une session qui expire. Ça ressemble à de la paperasse jusqu’à ce qu’on imagine l’alternative… un agent disposant de la clé complète d’un portefeuille et d’une consigne vague du genre « achète ce qu’il faut ». Un mauvais prompt, un plugin compromis, et le solde disparaît.
Avec une couche de session, le pire scénario se limite au budget accordé à cette seule tâche. À mon avis, c’est l’idée la plus concrète de toute la conception. Des plafonds de dépenses et des limites de temps appliqués sur la chaîne, plutôt que de simples promesses dans une page de conditions d’utilisation.
J’ai tout de même une réserve. Les limites ne protègent que les personnes qui les définissent correctement. Depuis des années, je vois des utilisateurs passer les écrans OAuth sans lire la moindre autorisation. Pourquoi en irait-il autrement avec les budgets des agents ? Certains fixeront le plafond à « illimité » parce que, sinon, la tâche échoue sans cesse. La chaîne peut faire respecter une règle. Elle ne peut pas en rédiger une qui soit judicieuse.
Le véritable test pourrait donc bien être les paramètres par défaut. Est-ce que les outils incitent les utilisateurs ordinaires à choisir des limites strictes et peu excitantes… ou est-ce que la facilité l’emporte ?
$KITE L’utilité se déploie par étapes : d’abord les incitations, puis le staking, la gouvernance et les frais. C’est la gouvernance que je suivrais de près, car quelqu’un finira par décider de ce que signifie un « paramètre sûr par défaut » pour tout le monde.
Je suis encore en train de lire la documentation, alors considérez ceci comme un avis provisoire.
Cette décision devrait-elle revenir au protocole ou à chaque utilisateur ? #KiteBBW
@KITE AI 中文
