Les Data Vending Machines Nostr (NIP-90) : la place de marché décentralisée d’IA et de calcul

Les Data Vending Machines (DVM) sont des services NIP-90 sur Nostr : vous publiez un event de demande de job (kinds 5000-5999), des fournisseurs concurrents répondent avec un résultat (kinds 6000-6999) et un feedback (kind 7000), et vous payez avec un zap Lightning ou une facture bolt11. Pas de compte, pas de clé API, pas de KYC. C’est un marché ouvert pour le calcul, y compris l’inference IA.

État de la spécification (2026) : la spécification NIP-90 est désormais marquée “unrecommended” dans le dépôt de protocole Nostr en amont — les mainteneurs disent qu’elle “got totally out of control” et orientent maintenant vers des micro-standards par cas d’usage. Lisez cela comme une mise en garde sur la spécification, pas sur l’activité : des jobs DVM live circulent toujours sur les kinds 5000–7000 et les mécanismes ci-dessous décrivent comment ils fonctionnent aujourd’hui. Traitez NIP-90 comme une convention fonctionnelle mais contestée, non comme une norme finalisée.

Si vous faites déjà tourner un node, détenez vos propres clés et penchez vers l’auto-garde et l’auto-hébergement, la pile IA centralisée ressemble à un recul : s’inscrire, fournir un numéro de téléphone, coller une carte de crédit, accepter les conditions, et laisser une seule entreprise journaliser chaque prompt. Les Data Vending Machines sont la réponse de l’écosystème Nostr à cela. Elles transforment le « calcul externalisé » en un marché sans permission, payé par job, où la seule identité dont vous avez besoin est une paire de clés et le seul rail de paiement est Lightning.

Ce guide couvre le fonctionnement des DVM au niveau du protocole (NIP-90), la boucle de paiement Lightning, ce qui les distingue à la fois des API IA centralisées et des marchés GPU DePIN, et comment en déployer une sur une pile d’inference auto-hébergée. La spécification NIP-90 et le registre communautaire des kinds sont les sources principales tout au long de ce texte.

Ce qu’est réellement une Data Vending Machine

Un DVM n’est pas un serveur sur lequel on se connecte. C’est un rôle que deux parties jouent sur le réseau de relays de Nostr. Le client annonce un job qu’il veut voir accompli et combien il paiera. Un ou plusieurs fournisseurs de service voient cette demande sur les relays qu’ils écoutent, décident si le travail en vaut la peine, exécutent le calcul hors protocole, et publient le résultat en retour. Le protocole ne fait pas passer les données par une API centrale ; il fait circuler des events via les relays, et le calcul réel s’exécute sur le matériel que le fournisseur choisit de faire tourner.

Parce que la demande est un event Nostr public (ou optionnellement chiffré), n’importe qui peut y répondre. C’est la décision de conception clé de NIP-90, rédigé par pablof7z et raffiné par la communauté Nostr : le flux est délibérément ambigu pour que les fournisseurs puissent concurrencer sur la vitesse, le prix, la qualité et le modèle de confiance. Il n’y a pas de gardien qui décide qui a le droit de vendre du calcul. Si votre DVM produit de meilleures transcriptions, les plebs dirigent leurs jobs vers vous ; s’il est lent ou faux, ils les dirigent ailleurs. C’est un marché libre pour le traitement de données bâti sur une couche de messagerie résistante à la censure.

Le flux d’events NIP-90 : demandes, résultats, feedback

NIP-90 réserve la plage de kinds 5000-7000 au trafic des machines distributrices et la découpe en trois rôles. La relation est simple : un résultat de job utilise toujours un kind exactement 1000 au-dessus de la demande à laquelle il répond (une demande de résumé 5001 est répondue par un résultat 6001).

Un cycle de vie typique ressemble à ceci. Le client publie une demande de kind 5000-5999 sur un ensemble de relays. Les fournisseurs qui surveillent ces relays la captent. Un fournisseur peut immédiatement publier un event de feedback kind 7000 avec un statut processing, ou avec un statut payment-required s’il veut de l’argent d’avance. Quand le travail est terminé, le fournisseur publie le résultat kind 6000-6999 et habituellement un feedback final success. Le client paie, et c’est toute la boucle. Il n’y a pas de session, pas de connexion persistante, pas d’état de compte de part et d’autre au-delà de leurs paires de clés Nostr.

À l’intérieur d’une demande de job

L’event de demande transporte tout ce dont un fournisseur a besoin dans ses tags. Les importants, directement tirés de la spécification :

• i — un ou plusieurs tags d’entrée, formés ["i", "<data>", "<input-type>", "<relay>", "<marker>"]. Le type d’entrée est url, event, job, ou text. Un url pointe vers un fichier à transcrire ; text est en ligne ; event référence une autre note Nostr ; job est le plus puissant (plus bas).
• output — le type MIME que vous voulez en retour (par exemple text/plain ou audio/mp3).
• param — paramètres de job clé/valeur, comme ["param", "language", "en"] ou une plage de temps de transcription.
• bid — le maximum que vous êtes prêt à payer, en millisats. C’est un plafond, pas une promesse ; les fournisseurs peuvent facturer moins ou refuser.
• relays — où les fournisseurs devraient publier leurs réponses.
• p — pubkeys optionnelles de fournisseurs spécifiques que vous voulez cibler. Omettez-le et la demande est un appel ouvert à tout le marché.

Deux fonctionnalités en font bien plus qu’une API glorifiée. Premièrement, le chaînage de jobs : vous pouvez alimenter la sortie d’un job dans un autre en utilisant ["i", "<result-event-id>", "job"]. Cela permet d’enchaîner un job de transcription dans un job de traduction dans un job de résumé, chacun potentiellement servi par un DVM spécialiste différent, sans orchestrateur central. Deuxièmement, les demandes chiffrées : si l’entrée est sensible, vous chiffrez les tags i et param vers la pubkey d’un fournisseur spécifique, placez le ciphertext dans le champ content, et ajoutez un tag ["encrypted"]. NIP-90 spécifie actuellement cela avec le schéma de DM chiffré NIP-04 (l’écosystème Nostr plus large migre le chiffrement vers NIP-44, donc attendez-vous à ce que ce détail évolue). Le résultat revient alors aussi chiffré — ce qui signifie que votre prompt et la réponse ne reposent jamais en clair sur un relay public.

La boucle de paiement Lightning-zap

Le paiement dans NIP-90 est volontairement flexible, et c’est là que le modèle gagne son nom de « machine distributrice ». Les events de résultats de job comme de feedback PEUVENT porter un tag amount formé ["amount", "<millisats>", "<optional-bolt11>"]. C’est une demande d’être payé. Le client peut la satisfaire de deux façons : payer directement la facture bolt11 incluse, ou zapper l’event pertinent sur le Lightning Network. Les fournisseurs qui incluent une facture devraient surveiller les deux.

La spécification est prudente sur un point : un tag amount n’est qu’une suggestion de paiement. Un fournisseur qui veut vraiment de l’argent avant de lever le petit doigt DOIT envoyer un feedback kind 7000 avec le statut payment-required ; jusqu’à ce que cette facture soit réglée, aucun travail supplémentaire n’a lieu. Cette règle unique donne aux fournisseurs la latitude de choisir leur propre posture de risque, et trois schémas ont émergé sur le terrain :

• Payer d’abord : envoyer payment-required immédiatement, ne rien faire tant que le zap n’est pas arrivé. Risque fournisseur le plus bas, friction la plus élevée pour le client.
• Échantillon puis payer : renvoyer un résultat partiel (quelques secondes de transcription, une image basse résolution) avec un statut partial, puis un payment-required pour débloquer le reste. Un juste milieu qui bâtit la confiance.
• Optimiste : évaluer l’historique de paiement d’un npub, livrer le résultat complet, et faire confiance au client pour zapper. Meilleure UX, et viable parce qu’un client qui floue les fournisseurs obtient rapidement une mauvaise réputation que d’autres DVM peuvent voir.

Le chaînage ajoute une subtilité que la spécification signale directement : un fournisseur peut démarrer le job suivant dès qu’il voit le résultat précédent, mais il attendra habituellement le zap d’abord — et c’est la réputation, non le protocole, qui maintient l’honnêteté de tous. Pour les plebs qui automatisent tout cela, Nostr Wallet Connect (NIP-47) est le tissu connectif : il permet à un client ou un DVM de surveiller les paiements entrants et de déclencher des zaps de façon programmatique sans exposer les identifiants complets de votre node.

Ce que les DVM peuvent faire aujourd’hui

Le registre communautaire des kinds définit un menu croissant de types de jobs. Ce sont des conventions, pas une loi de protocole stricte — un fournisseur peut servir n’importe quel sous-ensemble — mais elles créent le vocabulaire partagé qui permet aux clients et aux DVM de se trouver. Les kinds actuellement enregistrés :

Les kinds de découverte de la série 5300 sont discrètement les plus utilisés en pratique : ils alimentent les fonctionnalités de « fil algorithmique » dans les clients Nostr, où des DVM concurrents offrent chacun un algorithme de recommandation différent et vous choisissez celui dont les résultats vous plaisent. C’est la curation de contenu comme marché contestable plutôt qu’un classement corporatif opaque unique. Les kinds 5050 (génération de texte) et 5100 (génération d’images) sont l’histoire IA évidente : inference LLM et diffusion privée pour quiconque a une paire de clés et quelques sats. Les outils de surveillance comme DVMDash suivent l’écosystème live en temps réel — les fournisseurs actifs et les kinds qu’ils servent — et bien que le marché soit encore petit face à la Big Tech, il est réel et fonctionnel.

En quoi les DVM diffèrent des API IA centralisées et du DePIN

Il est facile de regrouper le « calcul décentralisé », mais les DVM, les API IA hébergées et les réseaux GPU DePIN résolvent des problèmes différents avec des modèles de confiance différents.

Le modèle mental le plus clair : une API centralisée vous vend un résultat mais exige un compte et journalise tout. Un marché GPU DePIN (pensez aux réseaux qui louent du temps brut de carte graphique) vous vend la machine — vous devez encore apporter le model, exécuter l’inference, et gérer la boîte. Un DVM vous vend le résultat comme une API, mais avec le marché sans permission et le rail de paiement d’un réseau DePIN, sans le bagage de compte. Le compromis est la maturité : les réseaux DePIN agrègent une capacité GPU sérieuse, tandis que le marché DVM est plus jeune et la qualité du résultat dépend entièrement du fournisseur qui répond. Nous couvrons le côté capacité brute dans notre aperçu des réseaux de calcul DePIN, et l’économie de le faire soi-même dans le vrai coût de l’inference auto-hébergée.

Faire tourner votre propre DVM sur une pile auto-hébergée

C’est ici que ça devient intéressant pour un Bitcoiner souverain : un DVM est quelque chose que vous pouvez faire tourner, pas seulement consommer. Si vous maintenez déjà un node sous tension, ajouter un DVM transforme du calcul inactif (ou une boîte d’inference dédiée) en un service qui gagne des sats et que personne ne peut déplatformer. Les pièces dont vous avez besoin :

1. Une identité Nostr et une connexion aux relays. Générez une paire de clés pour le DVM et connectez-vous à une poignée de relays où les clients publient des jobs. Une bibliothèque comme nostr-tools (JS), python-nostr, ou rust-nostr gère la signature et les abonnements.
2. Un cadre DVM. Vous n’avez pas à coder à la main la gestion des events. Les cadres communautaires — la boîte à outils Python « nostr-dvm » est la plus établie — implémentent la machine d’état demande/feedback/résultat et l’annonce NIP-89 pour que les clients puissent vous découvrir.
3. Un moteur d’inference local. C’est le calcul réel. Pour la génération de texte (5050), un runtime LLM sur appareil comme Ollama ou llama.cpp. Pour la transcription (5000), whisper.cpp. Pour la génération d’images (5100), un backend local Stable Diffusion tel que ComfyUI. Le model et le matériel sont entièrement votre choix — c’est le point.
4. Un récepteur Lightning. Pour être payé, pointez le DVM vers un node ou un portefeuille qui peut émettre des factures bolt11 et détecter les zaps. LNbits, Alby Hub, Phoenixd, ou Core Lightning fonctionnent tous ; Nostr Wallet Connect rend scriptable la boucle « surveiller le paiement, puis libérer le résultat ».
5. Une annonce (NIP-89). Publiez un event d’information de handler qui annonce quels kinds vous servez, vos indices de tarification, et vos relays, pour que les clients compatibles DVM vous listent au lieu que vous attendiez dans le noir.

Décidez de votre posture de paiement (payer d’abord est le plus sûr pendant que vous bâtissez votre réputation) et commencez par un kind que vous savez bien faire — la transcription est un point d’entrée populaire et bien défini. Les opérateurs rapportent d’emblée les réalités honnêtes : il y a du pourriel et des non-payeurs, la latence compte parce que les fournisseurs plus rapides gagnent la course pour une demande, et vos gains suivent la qualité et l’unicité de votre model bien plus que le simple temps de disponibilité.

Ce schéma — payer par inference, réglé en Bitcoin, servi depuis du matériel que vous contrôlez — est la même idée derrière notre travail sur une boucle de calcul souverain. Les DVM sont l’une des démonstrations publiques les plus claires que ça fonctionne, et elles reposent sur les épaules de toute la communauté Nostr et Lightning qui a construit les primitives.

Limites honnêtes

Les DVM sont prometteuses, pas terminées. L’ambiguïté qui rend le protocole flexible rend aussi la qualité inégale : rien n’oblige un fournisseur à renvoyer un bon résultat, et la résolution de litiges se résume à « ne pas payer et ne plus les utiliser ». La disponibilité est au mieux effort — si aucun fournisseur n’écoute votre kind, votre job reste simplement sans réponse. Les demandes chiffrées arrêtent l’espionnage passif des relays, mais le fournisseur que vous ciblez voit toujours votre entrée déchiffrée, donc un DVM est privé vis-à-vis du réseau, pas de l’opérateur que vous avez choisi. Traitez les DVM comme une option puissante et résistante à la censure dans votre boîte à outils, non comme un remplacement immédiat de chaque API hébergée aujourd’hui — la trajectoire d’un calcul sans permission, sans compte, natif Bitcoin est exactement là où les constructeurs orientés souveraineté veulent aller.

Questions fréquentes

Qu’est-ce qu’une Data Vending Machine Nostr en une phrase ?

C’est un service NIP-90 où vous publiez une demande de job comme un event Nostr (kinds 5000-5999), n’importe quel fournisseur peut répondre avec un résultat (kinds 6000-6999) et un feedback de statut (kind 7000), et vous payez par job avec un zap Lightning ou une facture bolt11 — aucun compte ni clé API requis.

Ai-je besoin d’un compte ou d’un KYC pour utiliser un DVM ?

Non. Votre seule identité est une paire de clés Nostr, et votre seul paiement est Lightning. Il n’y a pas d’inscription, pas de courriel, pas de numéro de téléphone, et pas de carte en dossier. Ce modèle sans compte et sans permission est la principale chose qui sépare les DVM des API IA centralisées.

Comment fonctionne le paiement, et qu’est-ce qui m’empêche de ne pas payer ?

Les events de résultats et de feedback peuvent porter un tag amount avec un prix en millisats et une facture bolt11 optionnelle ; vous le payez ou zappez l’event. Un fournisseur qui veut de l’argent d’avance envoie un feedback kind 7000 payment-required et ne travaille pas tant que vous n’avez pas payé. Les fournisseurs optimistes livrent d’abord et s’appuient sur la réputation — un npub qui floue habituellement les fournisseurs obtient un mauvais historique visible sur lequel d’autres DVM peuvent agir.

Mes prompts sont-ils privés sur un DVM ?

Ils peuvent être privés vis-à-vis du réseau de relays. NIP-90 vous permet de chiffrer les tags d’entrée et de paramètres vers la pubkey d’un fournisseur spécifique et de placer le ciphertext dans le champ content, et le résultat revient aussi chiffré. Le hic : le fournisseur que vous avez ciblé déchiffre et voit toujours votre entrée, donc c’est privé des observateurs passifs, pas de l’opérateur que vous avez choisi.

En quoi un DVM diffère-t-il d’un marché GPU DePIN ?

Un réseau GPU DePIN vous loue la machine brute — vous fournissez le model et exécutez l’inference vous-même. Un DVM vous vend le résultat terminé, comme une API, mais sur un marché Nostr ouvert payé en Bitcoin. Les DVM échangent une partie de l’échelle de calcul contre une friction bien plus basse et l’absence de compte ; le DePIN échange la commodité contre une capacité brute que vous contrôlez pleinement.

Un pleb ordinaire peut-il vraiment faire tourner son propre DVM ?

Oui. Vous avez besoin d’une paire de clés Nostr et d’une connexion aux relays, d’un cadre DVM (la boîte à outils Python nostr-dvm est un point de départ courant), d’un moteur d’inference local tel qu’Ollama, llama.cpp, whisper.cpp, ou un backend Stable Diffusion, d’un récepteur Lightning comme LNbits ou Alby Hub pour les factures et les zaps, et d’une annonce NIP-89 pour que les clients puissent vous trouver. Commencez par un kind bien défini comme la transcription et une posture payer-d’abord pendant que vous bâtissez votre réputation.