Nostr sur l’IA auto-hébergée : apportez votre identité à votre propre stack d’inférence

Pourquoi l’identité compte pour l’IA auto-hébergée

Les deux tiers de cette audience font déjà tourner des modèles en local. LM Studio sur le portable. Ollama sur un serveur à la maison. Open WebUI devant une 3090. Quelques plebs courageux qui font tourner un 70B quantifié sur un empilement de P40 parce qu’ils refusent d’envoyer un autre token à OpenAI.

Le matériel est réglé. Les modèles sont réglés (assez). Ce qui n’est pas réglé, à l’échelle du pleb, c’est la couche d’identité de tout ça. Trois questions pratiques :

1. À qui ce modèle parle-t-il ? Nom d’utilisateur + mot de passe est une réponse Web2 à un problème Web3. Les clés d’API sont pires — elles fuient, elles tournent, elles vous lient à un fournisseur.
2. Comment vérifier ce que le modèle a dit ? La sortie d’un modèle hébergé, aujourd’hui, n’est qu’une chaîne de caractères à l’écran. Personne ne l’a signée. Personne ne peut prouver que le modèle l’a réellement produite. Personne ne peut prouver qu’elle n’a pas été altérée en transit ou après coup.
3. Comment payer au prompt sans comptes ? Si votre ami veut utiliser votre boîte Ollama, ou si votre modèle veut offrir ses tokens au public, il vous faut une façon de facturer qui ne soit pas « envoyez-moi une facture Stripe ».

Nostr répond aux trois avec ses primitives existantes — événements signés, identité par paire de clés, zaps — et il y répond d’une façon qui compose avec le reste du Sovereign Stack du pleb.

Apporter l’identité Nostr à Open WebUI / LM Studio / Ollama

Les trois outils que la plupart des plebs auto-hébergent sont Open WebUI (par Timothy J. Baek et contributeurs — le frontal à la ChatGPT), Ollama (par l’équipe Ollama — le runtime de modèle), et llama.cpp (par Georgi Gerganov — le moteur d’inférence sous la plupart de tout ça). LM Studio occupe le même créneau qu’Open WebUI pour les utilisateurs de bureau. Sur les épaules des géants : rien de tout ça ne se bâtit sans ces projets, et ils ont fait le gros du travail pour rendre l’inférence locale une affaire d’un clic.

Ce vers quoi ils défaillent tous encore, c’est l’auth Web2. Open WebUI livre un système local nom d’utilisateur / mot de passe. LM Studio ne se donne pas la peine d’avoir de l’auth parce qu’il suppose qu’il n’est jamais que sur localhost. Ollama expose une API HTTP sans aucune auth jusqu’à ce que vous colliez un reverse proxy devant.

La réponse du pleb, c’est de mettre un shim d’auth-par-npub devant l’endpoint d’inférence. Le patron est simple et roule déjà dans la nature :

1. Placez un petit reverse proxy devant votre API Ollama / Open WebUI (nginx, Caddy, ou une couche FastAPI/Express maison — choisissez ce que vous connaissez).
2. Exigez un événement HTTP signé de type NIP-98 à chaque requête — un court événement Nostr éphémère qui prouve que l’appelant contrôle un npub donné.
3. Optionnellement, vérifiez le npub contre une liste blanche. Seulement votre propre clé. Seulement vos amis. Seulement les abonnés payants dont le dernier zap a moins de 30 jours.

Pas de comptes. Pas de base de données de mots de passe hachés. Pas de clés d’API qui tournent. Juste une requête signée depuis une paire de clés que vous reconnaissez.

Le guide d’initiation à l’IA auto-hébergée couvre la stack de base ; superposez l’auth-par-npub une fois la boîte en marche.

Les DMs chiffrés NIP-44 comme transport

C’est là que ça devient élégant. Au lieu de bâtir une interface de chat personnalisée devant votre modèle, vous pouvez utiliser n’importe quel client Nostr comme frontal, et utiliser les DMs chiffrés comme transport.

Le NIP-44 est la spec moderne de DMs chiffrés Nostr (remplaçant l’ancien NIP-04). ChaCha20-Poly1305, versionné, révisé. Tout client conforme — Amethyst, Damus, Coracle, 0xchat — peut envoyer et recevoir des messages NIP-44.

Le patron :

1. Attribuez à votre agent IA une paire de clés Nostr. Son npub devient le « handle » du chatbot sur le réseau.
2. Un petit processus passerelle s’abonne aux DMs adressés à ce npub, les déchiffre avec la nsec de l’agent, nourrit le texte déchiffré à votre modèle local, et répond en publiant une DM chiffrée au destinataire.
3. Du point de vue de l’utilisateur, il « DM un bot » depuis le client Nostr de son téléphone. Sous le capot, le « bot » est votre boîte Open WebUI / Ollama assise derrière un reverse proxy dans votre garde-robe.

Vous venez de bâtir une interface de chat privée, chiffrée de bout en bout, vers votre modèle auto-hébergé, depuis n’importe quel appareil, sans aucune application à installer au-delà du client Nostr que l’utilisateur a déjà. Et la seule identité impliquée des deux côtés est une paire de clés.

Zaps-pour-prompts

Faire tourner de l’inférence coûte de l’électricité. Si votre rig est une 3090 ou une paire de P40 dans un Hashcenter, chaque heure de génération de tokens, ce sont des sats qui sortent. La façon la plus propre de récupérer ce coût — ou de laisser des amis utiliser votre boîte contre de la valeur — c’est les zaps-pour-prompts.

La mécanique, avec les primitives que vous avez déjà :

1. Votre endpoint d’inférence déclare un prix par requête en sats (disons, 10 sats par 1k tokens de sortie).
2. Un appelant envoie un prompt. L’endpoint retourne une facture Lightning — LNURL-pay, ou un BOLT-11 généré sur votre propre nœud Lightning.
3. L’appelant paie. La facture est marquée comme réglée. L’inférence s’exécute. La réponse revient.
4. Optionnellement, l’endpoint publie un reçu de zap sur Nostr pour qu’il y ait un registre public de la transaction — utile pour la réputation, inutile pour la vie privée, alors rendez ça opt-in.

Ce n’est que des zaps réaffectés à la facturation d’API. Pas de Stripe. Pas de KYC. Pas de carte de crédit en dossier. N’importe quel portefeuille Lightning avec support des zaps peut payer ; n’importe quel npub peut être le compte de facturation. Un pleb à Buenos Aires qui fait tourner Mutiny peut acheter de l’inférence à un pleb à Lagos qui fait tourner Phoenix, et la transaction entière se règle en deux secondes sans qu’aucun des deux ne rencontre un rail fiat.

L’upgrade évident : des soldes prépayés indexés sur npub. L’utilisateur zappe 10k sats d’avance, l’endpoint crédite son npub de 10k sats de budget d’inférence, les requêtes subséquentes ne font que débiter le solde jusqu’à ce qu’il tombe à zéro. Le même truc que fait BTCPay Server pour les marchands, appliqué aux tokens.

Sortie de modèle signée

Chaque token que votre stack auto-hébergée produit peut — et pour les usages agentiques devrait — être emballé dans un événement Nostr signé.

Le patron :

1. L’opérateur du modèle a un npub (le sien, ou un dédié par modèle).
2. Après la génération d’une réponse, l’endpoint d’inférence construit un événement Nostr de kind 1 (ou un kind personnalisé) contenant le hash du prompt, le nom + la quantification du modèle, la sortie, et les métadonnées pertinentes (température, seed, horodatage).
3. L’événement est signé avec la nsec de l’opérateur et optionnellement publié sur un relais.
4. N’importe qui — l’utilisateur, un tiers, un vérificateur — peut vérifier après coup que la sortie provient de la clé de cet opérateur et n’a pas été altérée.

C’est de la provenance cryptographique sur la sortie IA. Ça ne prouve pas que le modèle est honnête. Ça ne prouve pas que l’opérateur est honnête. Mais ça rend la revendication de ce qui a été dit falsifiable, ce qui est une énorme amélioration par rapport à « capture d’écran sur un forum ». Combiné avec des builds reproductibles des poids et des quantifications du modèle, c’est la fondation d’un écosystème d’IA agentique auditable.

Le patron de sortie signée est aussi la bonne réponse à « ce billet / cette image / ce résumé est-il généré par IA ? ». Au lieu de bidouilles de filigrane qui se font retirer, publiez la sortie avec une signature. Si la signature tient la route face à un npub d’agent connu, vous savez exactement quel modèle l’a produite. S’il n’y a pas de signature, présumez humain (ou non vérifié).

Esquisse : topologie minimale relais + agent

Voici la stack souveraine IA + Nostr la plus mince possible qui exerce tout ce qui précède.

 [ téléphone de l'utilisateur (n'importe quel client Nostr) ]
            |  DMs chiffrées (NIP-44)
            v
 [ votre relais auto-hébergé ]  <-- depuis /run-your-own-nostr-relay-bitcoiners/
            |
            v
 [ processus passerelle sur votre serveur maison ]
    - s'abonne aux DMs pour le npub de l'agent
    - vérifie que le npub appelant est autorisé (ou a payé)
    - pour le payant : émet une facture LNURL via votre nœud LN
            |
            v
 [ Ollama / Open WebUI / llama.cpp ]
            |
            v
 [ la passerelle signe la réponse, publie une DM chiffrée en retour ]

Matériel : un vieux NUC ou un Raspberry Pi 5 pour le relais et la passerelle, une boîte GPU pour l’inférence. Les deux peuvent être sur le même LAN. Ni l’un ni l’autre ne parle à OpenAI, Anthropic, Google ou Cloudflare pour l’auth, la facturation ou le transport. Toute la chose tourne sur les primitives Bitcoin + Nostr.

Voilà toute la stack. Elle rentre dans un petit rack domestique. Elle coûte moins qu’une auto usagée. C’est l’équivalent moral Web3 de la stack LAMP, et le pleb arrive à posséder chaque couche.

Futur : minage agentique + identité Nostr pour des bots autonomes

Là où ça devient vraiment intéressant, c’est quand l’« utilisateur » de l’autre côté du npub n’est pas du tout un humain.

Un agent de minage autonome — un DCENT_axe, une grappe de Bitaxe, un nœud de minage agentique — peut porter sa propre paire de clés, signer ses propres événements de télémétrie, recevoir des zaps d’humains qui se soucient de sa production, payer sa propre facture d’électricité à l’opérateur de son Hashcenter, et négocier avec d’autres agents. Nostr est la couche d’identité qui rend ça cohérent. Lightning est la couche monnaie. Bitcoin est la couche règlement. Le matériel de minage est la couche physique. Les quatre piliers existent déjà ; la composition, c’est le travail.

On n’y est pas encore. On s’en rapproche. Le manifeste IA souveraine pour Bitcoiners esquisse l’arc. Ce billet est le pas concret — « donnez aujourd’hui une identité Nostr à votre stack d’inférence » — qui commence à rendre la vue d’ensemble traitable.

Mettez un npub sur votre boîte Ollama. Laissez vos amis la DM. Voyez ce qu’ils bâtissent.

Pour la suite du chemin : Nostr pour les Bitcoiners, Faites tourner votre propre relais Nostr, et le hub Souveraineté qui lie les piliers entre eux.