Nostr est-il vraiment décentralisé ? Une réponse technique

« X est-il décentralisé » reçoit presque toujours une réponse d'indifférence parce que la décentralisation est un spectre, pas un binaire. Cet article répond à la question pour Nostr spécifiquement, couche par couche, pour que vous puissiez dire quelles parties sont vraiment distribuées et quelles parties sont plus centralisées que la commercialisation ne le suggère.

Version courte

Nostr est décentralisé au niveau de la couche identité (complètement), de la couche transport (hautement), de la couche client (complètement), et de la couche données (modérément). Il est moins décentralisé à certaines couches pratiques où des produits spécifiques dominent. Le protocole lui-même n'a pas de point de défaillance unique ; des écosystèmes spécifiques en ont.

Quand vous êtes prêt, prenez votre adresse @nostr.blog →

Les cinq couches à évaluer

Chaque système social a une pile. La décentralisation de Nostr ressemble à quelque chose de différent à chaque couche.

Identité. Complètement décentralisée. Votre compte est une paire de clés cryptographiques sur votre appareil. Aucun registre central.

Transport (comment les messages se déplacent). Hautement décentralisé. N'importe quel relais peut accepter des événements ; n'importe quel client peut se connecter à n'importe quel relais.

Données (où les messages vivent). Modérément décentralisé. Les relais stockent indépendamment, mais des relais spécifiques reçoivent plus de trafic que d'autres.

Application (le client). Complètement décentralisé. N'importe quel développeur peut écrire un client ; les utilisateurs peuvent basculer librement.

Découverte et classement. Dépend du client. Certains clients délèguent à leur propre infrastructure (couche de mise en cache de Primal) ; d'autres parlent directement aux relais (Damus).

Chaque couche a des modes de défaillance différents et des niveaux différents de progression vers la centralisation. La réponse courte à « Nostr est-il décentralisé » dépend de la couche dont vous parlez.

Couche identité : complètement décentralisée

Votre compte Nostr est une clé privée sur votre appareil. Personne d'autre ne l'a. Aucune entreprise, aucun relais, aucun développeur. L'identité existe indépendamment de ce que tiers fait.

C'est la propriété de décentralisation la plus forte que Nostr possède. Vous ne pouvez pas être « déplateforcé » parce qu'il n'y a pas de plateforme à partir de laquelle vous déplateforcé. Votre identité se déplace entre les clients, survit à tout relais se mettant hors ligne, et ne peut pas être révoquée.

Le seul coût : si vous perdez la clé privée, aucune partie ne peut la récupérer. C'est le compromis de ne pas avoir une entreprise au milieu.

Couche transport : hautement décentralisée

Les relais sont la tuyauterie. Ils acceptent les événements et servent les abonnements. N'importe qui peut en exécuter un avec un seul binaire et un VPS ; il y a des milliers de relais publics en 2026.

Aucun relais n'est spécial. Aucun relais n'est « le serveur Nostr ». Votre client parle à tous les relais que vous configurez ; les clients de vos abonnés parlent à leurs relais configurés ; le réseau est l'union de toutes ces connexions.

Caveat pratique : la plupart des clients des utilisateurs par défaut se connectent aux mêmes relais populaires (relais Damus, nos.lol, relay.primal.net, etc.). Si ces relais spécifiques se mettaient tous hors ligne simultanément, les nouveaux utilisateurs verraient des flux vides jusqu'à ce qu'ils se reconfigurent. Le protocole le permet (basculer vers des relais différents) mais l'expérience utilisateur par défaut n'est pas aussi résiliente que le protocole lui-même.

Couche données : modérément décentralisée

Les événements sont répliqués sur les relais auxquels vous publiez. Un post que vous envoyez à cinq relais vit sur les cinq ; n'importe lequel d'entre eux peut servir le post à n'importe quel lecteur.

C'est décentralisé dans le sens où aucun relais unique n'a le monopole de vos données. C'est moins décentralisé dans le sens où l'ensemble des relais qui détiennent vos données n'est pas universel. Si vous publiez sur les relais A, B, C et que votre lecteur s'abonne à D, E, F, il ne voit pas votre post à moins qu'un relais ne relie les ensembles.

En pratique, la plupart des relais se chevauchent suffisamment en contenu pour que ce soit rarement un problème. Les utilisateurs qui veulent de la résilience publient sur plus de relais. Les utilisateurs qui veulent des performances publient sur moins de relais. Le compromis est ajustable.

Couche application : complètement décentralisée

Il existe des dizaines de clients Nostr. Aucun d'entre eux n'a d'autorité spéciale. Un nouveau client peut être écrit, publié et utilisé par des milliers de personnes en quelques semaines sans permission de quiconque.

Les clients concurrencent sur l'UX, la couverture des fonctionnalités et l'ajustement à l'écosystème. Les utilisateurs choisissent ce qui leur convient. Les coûts de basculement ne coûtent rien car l'identité est portable.

C'est peut-être la décentralisation la plus active dans l'écosystème : la couche client est vraiment compétitive et vraiment diverse. Aucun client n'a une position de winner-take-all.

Découverte et classement : varie selon le client

C'est ici que la décentralisation devient plus compliquée. Certains clients gardent la découverte neutre au protocole (s'abonner aux relais, filtrer les événements, vous montrer des posts). D'autres construisent leurs propres couches d'infrastructure.

Primal, par exemple, exécute un service de mise en cache et d'indexation sur sa propre infrastructure. Lorsque vous utilisez Primal, vous dépendez implicitement de ce service pour un chargement rapide des flux et les sujets en tendance. La mise en cache de Primal est une commodité centralisée superposée au protocole décentralisé.

Damus, en contraste, parle directement aux relais sans mise en cache intermédiaire. Votre expérience Damus est moins rapide au démarrage à froid mais plus purement protocolée.

Le choix dépend de vos priorités. Les deux sont des approches légitimes d'un protocole ouvert.

Où la centralisation s'infiltre pratiquement

Trois cas spécifiques à nommer.

Listes de relais par défaut. La plupart des clients livrent le même ensemble de relais par défaut. Un utilisateur qui ne change jamais les paramètres par défaut est implicitement concentré sur un petit nombre de grands relais. C'est une centralisation douce ; l'utilisateur peut se reconfigurer à tout moment, mais beaucoup ne le font pas.

Infrastructure de portefeuille. Les portefeuilles Lightning sont une couche séparée au-dessus de Nostr pour les zaps. Le monde des portefeuilles a sa propre dynamique de centralisation (quelques portefeuilles de garde populaires détiennent beaucoup de soldes d'utilisateurs). Cela affecte la couche économique de Nostr même si elle est externe au protocole.

Services de mise en cache client. La mise en cache de Primal est l'exemple le plus visible, mais d'autres existent. Tout service qui s'interpose entre les utilisateurs et les relais et ajoute des performances ajoute également un point central. Cela ne casse pas le protocole ; il façonne l'expérience utilisateur.

Ce que le protocole garantit par rapport à ce que l'écosystème offre

Le protocole garantit : propriété de l'identité, authenticité des événements, graphe social portable, pas de dépendance à un seul relais, pas de gardien de plateforme.

L'écosystème offre : niveaux variés de commodité grâce à des services centralisés en couches. Les utilisateurs peuvent accepter (cache Primal, Damus Wallet, le client web nostr.blog) ou refuser (relais auto-hébergés, Amethyst avec défauts personnalisés, signature basée sur Amber).

Les propriétés décentralisées que vous conservez proviennent des couches que vous utilisez et de la façon dont vous les configurez. Un utilisateur avec les paramètres par défaut dans un client courant obtient les fortes garanties du protocole plus une certaine centralisation pratique. Un utilisateur qui choisit des relais indépendants, exécute Amber et utilise un client minimal se rapproche davantage de la décentralisation complète au prix d'une plus grande friction.

« Décentralisé » est-il le bon mot à utiliser ici

Le mot est surchargé. Si par « décentralisé » vous entendez « aucune partie unique ne peut bannir votre compte », oui, Nostr l'est.

Si vous entendez « chaque utilisateur interagit avec chaque relais de manière égale », non ; la popularité des relais est inégale.

Si vous entendez « aucun service ne peut tomber en panne et casser le réseau », surtout oui ; le protocole est robuste mais des produits spécifiques peuvent avoir des pannes qui affectent leurs utilisateurs.

Si vous entendez « aucun algorithme de publicité vous optimisant pour l'engagement », oui, structurellement.

Si vous entendez « chaque morceau du système est décentralisé simultanément au même niveau de décentralisation », aucun réseau de taille significative ne l'est. Nostr est plus décentralisé que Bluesky, beaucoup plus décentralisé que la fédération centrée sur les instances de Mastodon, et incomparablement plus décentralisé que Twitter ou Threads.

L'impact pratique

Pour la plupart des utilisateurs, « Nostr est-il décentralisé » se traduit par « puis-je posséder mon identité, mon algorithme de flux m'appartient-il, puis-je être banni du réseau ». Les réponses sont oui, oui, non.

C'est la décentralisation qui affecte votre expérience quotidienne. L'architecture plus profonde est intéressante mais secondaire à la question de savoir si votre compte vous appartient vraiment, ce que Nostr gère aussi bien que n'importe quel protocole ne l'a jamais fait.