Tu publies une première version d’un dossier sur IPFS. Le hash obtenu est partagé, des gens l’utilisent, tout va bien. Le lendemain, tu corriges une coquille dans un fichier. Le nouveau hash n’a rien à voir avec l’ancien, et tous tes liens sont cassés. C’est là qu’IPNS intervient. Pas comme une solution miracle, mais comme un mécanisme qui te permet de pointer vers un contenu sans que l’adresse change à chaque modification.
On va poser les bases rapidement, puis entrer dans ce qui coince vraiment quand on passe du stade de la démo à celui d’un service qui doit fonctionner plusieurs jours.
Pourquoi un hash seul ne suffit pas
IPFS utilise le content-addressing: l’adresse d’un fichier est le hash de son contenu. Change une virgule, le hash change. Pour un site statique, c’est parfait si tu ne le mets jamais à jour. Pour un blog, un profil, un dossier partagé qui évolue, c’est un calvaire: chaque nouvelle version impose de redistribuer une nouvelle adresse.
IPNS a été conçu pour ça. Au lieu d’utiliser le hash du contenu comme identifiant, tu utilises une paire de clés cryptographiques. L’adresse IPNS est un hash de ta clé publique. Tu signes avec ta clé privée un enregistrement qui dit: « cette adresse pointe vers tel hash IPFS ». Quand tu mets à jour le contenu, tu signes un nouvel enregistrement qui pointe vers le nouveau hash. L’adresse, elle, ne change jamais.
Ce qui rend la chose utilisable, c’est que le réseau IPFS peut résoudre cette adresse en interrogeant la DHT. Mais la DHT, pour IPNS, n’a pas la même fraîcheur que pour un hash de contenu. On va voir pourquoi ça coince.
Ce qui se passe vraiment quand tu résous une adresse IPNS
Derrière la commande ipfs name resolve, il y a une série d’étapes où le temps de réponse peut varier du simple au centuple selon la topologie du réseau et l’état du cache de ton nœud.
Tu as la clé privée. Tu signes un enregistrement IPNS avec un TTL et une cible. Cet enregistrement est distribué dans la DHT. Quand quelqu’un veut résoudre ton adresse, son nœud cherche dans la DHT un enregistrement signé et encore valide. S’il le trouve, il extrait le hash IPFS et le renvoie. S’il ne le trouve pas à temps, il attend. Si plusieurs enregistrements coexistent, il prend le plus récent selon le numéro de séquence.
Où le cache vous sauve la mise
Le nœud qui résout met en cache l’enregistrement jusqu’à expiration du TTL. Le premier accès depuis un nœud froid est lent. Le deuxième est quasi immédiat. C’est pour ça qu’une application qui utilise IPNS sérieusement maintient une couche de cache côté serveur, avec un nœud IPFS toujours chaud, plutôt que de résoudre en direct depuis le navigateur de chaque visiteur.
Pourquoi le TTL ne règle pas tout
Le TTL par défaut d’un enregistrement IPNS est de 24 heures. Monter le TTL améliore la rapidité de résolution pour les nœuds qui l’ont déjà en cache, mais tu perds en réactivité si tu veux publier des mises à jour fréquentes. Descendre le TTL à quelques minutes augmente la charge sur la DHT et rend la résolution plus lente pour tout le monde, parce que les enregistrements expirent avant que le cache ait servi. Choisir le TTL, c’est choisir entre disponibilité et réactivité. Et il n’y a pas de valeur magique.
Tu peux publier un nouvel enregistrement avec ipfs name publish et l’option --ttl. Mais ce que tu gagnes en contrôle, tu le perds en simplicité de débogage quand quelqu’un te signale que le site ne charge pas pour lui alors que chez toi tout roule.
Créer une adresse IPNS et la faire vivre
La partie opérationnelle est simple en apparence, mais quelques détails transforment une démo en brique stable.
Générer la clé
ipfs key gen mon-projetTu obtiens une sortie avec l’identifiant de la clé et l’adresse IPNS (quelque chose comme /ipns/k51qzi5u...). La clé privée est stockée dans le keystore local d’IPFS. Si tu perds la machine et que tu n’as pas sauvegardé la clé, tu perds le contrôle du nom. Sauvegarder cette clé n’a rien d’optionnel.
Publier un enregistrement
ipfs name publish --key=mon-projet /ipfs/hash-de-mon-contenuÀ ce stade, l’enregistrement est diffusé. Les premiers essais échouent souvent parce que la propagation n’est pas instantanée. Attendre quelques minutes et relancer la résolution avec l’option --nocache évite de tourner en rond sur un cache local périmé.
Une application qui fait ça proprement automatise la publication, stocke la clé dans un secret, et planifie une vérification périodique de la résolution depuis un nœud distant. Sinon, on finit par apprendre qu’un enregistrement a expiré quand un visiteur râle.
Renouveler avant expiration
Un enregistrement IPNS n’est valide que pendant la durée de son TTL. Si personne ne republie, l’adresse ne pointe plus vers rien. La pratique courante est de republier bien avant expiration, avec un système de cron ou un service dédié. Les implémentations comme ipns-publisher font ça pour toi.
IPNS et la lenteur: ce n’est pas une régression, c’est le protocole
La première chose que tout le monde remarque, c’est que résoudre une adresse IPNS prend plusieurs secondes, parfois une dizaine. La raison n’est pas un défaut d’optimisation logicielle, mais le fait que la recherche d’un enregistrement signé dans une DHT avec des millions de nœuds oblige à parcourir des pairs jusqu’à trouver ceux qui stockent la donnée.
Le problème de la DHT et des nœuds publics
Les nœuds IPFS publics ne conservent pas les enregistrements IPNS très longtemps s’ils ne sont pas sollicités. Si personne ne résout régulièrement l’adresse, l’enregistrement finit par être évincé et la résolution suivante doit attendre que l’éditeur republie ou que le réseau retrouve un pair qui l’avait gardé. Un service qui veut une résolution rapide déploie ses propres nœuds, avec un stockage persistant et une bande passante correcte.
Ce que tu peux faire côté client
Si tu contrôles la résolution (application, backend), tu peux:
- Maintenir un nœud IPFS qui résout en boucle pour garder l’enregistrement chaud.
- Utiliser un résolveur HTTP dédié (comme celui de Cloudflare ou d’Infura) qui maintient un cache conséquent.
- Court-circuiter la DHT en distribuant l’enregistrement signé directement à tes services via une API privée, et n’utiliser la DHT que comme fallback.
Pour un simple fichier partagé entre deux machines, la lenteur n’est pas un problème. Dès que l’adresse est chargée par des dizaines de visiteurs qui ne vont pas attendre, la stratégie de cache devient le sujet principal. Si ta connexion Internet est déjà sous-dimensionnée, les choses se corsent encore plus: entre la résolution DHT et le chargement du contenu IPFS, le moindre goulot d’étranglement rend l’expérience inacceptable. Les mêmes principes qui dégradent ta visio s’appliquent ici: une ligne instable ou un réseau encombré n’accélère pas la résolution.
Les usages où IPNS cartonne, et ceux qui cassent
IPNS est né pour les systèmes de fichiers personnels et les profils décentralisés où un auteur veut publier des mises à jour sans dépendre d’un serveur central. On le trouve dans:
- Le partage de dossiers collaboratifs (un hash racine qui change, une adresse IPNS qui reste).
- L’hébergement de blogs statiques décentralisés (un article, puis un autre, sans casser les liens entrants).
- Les profils utilisateurs dans des applications pair-à-pair (l’utilisateur re-signe quand il change sa photo, sa bio).
En revanche, IPNS n’est pas fait pour:
- Des milliers de mises à jour par minute (le coût de publication et la charge DHT explosent).
- Remplacer un CDN pour un site à fort trafic (chaque visiteur qui résout l’IPNS depuis zéro est une promesse de temps de chargement à deux chiffres).
- Des records DNS pour des services où quelques secondes de latence supplémentaire coûtent des conversions.
Beaucoup de projets arrivent à cette conclusion après avoir essayé de faire tenir un service de messagerie temps réel sur IPNS. La signature d’un enregistrement pour chaque message, couplée à un TTL court, sature le nœud et rend l’UX pire qu’avec HTTP/2.
IPNS n’est pas un DNS
La confusion est fréquente: un hash encodé en base36 précédé de k51qzi5u... n’est pas un nom de domaine. Pour obtenir un joli nom lisible, on utilise des couches au-dessus d’IPNS.
DNSLink est la plus répandue pour les sites web: tu fais pointer un enregistrement TXT de ton domaine vers /ipns/ton-adresse-ipns. Ensuite, le site est accessible via un gateway IPFS.
ENS (Ethereum Name Service) propose de faire la correspondance entre un nom .eth et une adresse IPNS, en stockant le lien sur la blockchain. C’est utile pour les applications décentralisées où l’utilisateur connaît déjà l’écosystème Ethereum.
Sans ces surcouches, IPNS reste une adresse cryptographique. Pour un utilisateur qui voudrait un simple lien à partager, ce n’est pas mieux qu’un hash IPFS.
Ce qui casse quand on oublie IPNS dans un projet plus large
Des équipes présentent des maquettes de décentralisation en conférence, puis reviennent un an plus tard avec des architectures hybrides. Le motif récurrent est le suivant: elles ont sous-estimé la maintenance des clés et la lenteur de propagation.
La rotation de clé est un chantier
IPNS n’a pas de mécanisme intégré pour faire tourner une clé sans perdre l’historique de l’adresse. Si ta clé privée fuit, tu crées une nouvelle adresse, et tous les liens précédents sont morts. Tu peux signer un dernier enregistrement qui redirige vers une nouvelle adresse, mais cela dépend d’un tiers de confiance ou d’une infrastructure de mise à jour qui doit rester en ligne. La plupart des implémentations professionnelles finissent par déléguer la publication à un service dédié, avec une clé stockée dans un HSM ou un vault chiffré, et des backups hors ligne.
L’interaction avec les resolvers gateway
Quand un utilisateur accède à https://ipfs.io/ipns/ton-adresse, le gateway résout l’IPNS pour lui. Si le gateway n’a pas de cache chaud, l’utilisateur voit un délai énorme, voire une erreur de résolution. Certains gateways mettent en cache les enregistrements plus longtemps que le TTL, ce qui casse la fraîcheur. D’autres ne résolvent qu’à la demande et expirent en mémoire rapidement. Pour un service en production, il faut tester le comportement avec plusieurs gateways avant de les recommander, ou pousser les utilisateurs vers un résolveur local. La politique de cache des gateways est aussi opaque que celle des scripts de newsletter qui cassent le LCP sans prévenir.
La dépendance à la disponibilité du nœud de publication
Même après publication, le nœud qui a signé n’a pas besoin de rester en ligne pour que l’enregistrement persiste, en théorie. En pratique, si aucun autre nœud ne relaye l’enregistrement, et si le nœud d’origine était le seul à fournir le contenu IPFS en même temps, la résolution peut échouer. Un réseau vraiment résilient nécessite qu’au moins quelques pairs stables hébergent à la fois l’enregistrement IPNS et les blocs IPFS correspondants. Le concept est élégant sur le papier; en pratique, c’est une couche de supervision à implémenter.
Questions fréquentes
Quelle est la différence entre IPFS et IPNS?
IPFS attribue un identifiant unique à un contenu et ne le change jamais. IPNS attribue un identifiant à un auteur ou à une ressource qui peut changer de contenu dans le temps. IPFS répond à « qu’est-ce que c’est », IPNS répond à « où est la dernière version ».
Peut-on utiliser IPNS sans IPFS?
Non. IPNS est un système d’enregistrement de pointeurs qui ne stocke pas les données. La cible d’un enregistrement IPNS est toujours une adresse IPFS (ou un autre chemin IPNS). Sans IPFS derrière, le lien ne mène nulle part.
Comment augmenter la vitesse de résolution d’une adresse IPNS?
En augmentant le TTL si la fraîcheur n’est pas critique. En maintenant un nœud IPFS dédié qui résout en permanence. En utilisant un résolveur HTTP centralisé qui fait office de cache. Enfin, en évitant de résoudre depuis un navigateur utilisateur final sans cache local.
IPNS fonctionne-t-il avec tous les gateways IPFS publics?
La plupart des gateways (ipfs.io, dweb.link, cloudflare-ipfs.com) supportent la résolution IPNS, mais les performances varient. Certains limitent la durée de résolution, d’autres mettent en cache sans respecter exactement le TTL. Toujours tester avec le gateway choisi avant de distribuer l’URL.
Une adresse IPNS peut-elle contenir des sous-chemins?
Oui. Une adresse IPNS se comporte comme une racine mutable. /ipns/ton-adresse/dossier/fichier.pdf pointe vers le fichier à l’intérieur du hash IPFS référencé par l’enregistrement IPNS. Pratique pour exposer une arborescence complète sans multiplier les clés.
Combien de temps un enregistrement IPNS reste-t-il valide?
Par défaut, 24 heures. L’éditeur peut spécifier un TTL différent, mais un TTL trop long retarde la propagation de la mise à jour, et un TTL trop court augmente la charge. Sans republication avant expiration, l’adresse cesse de fonctionner.
Votre recommandation sur ipns
Quelques questions rapides pour adapter la recommandation à votre cas.
Merci, voici notre conseil personnalisé sur ipns.
D'après vos réponses, le mieux est de reprendre l'article ci-dessus en focalisant sur les passages qui parlent de votre situation : c'est là que se trouvent les recommandations les plus concrètes pour vous. Bonne lecture !
