Le protocole Nostr, expliqué simplement

Un protocole est un ensemble de règles pour la manière dont les programmes communiquent entre eux. Une plateforme est une entreprise qui exécute ces programmes en votre nom. Twitter est une plateforme. Email est un protocole. Nostr est un protocole.

Cette distinction importe car les protocoles et les plateformes ont des modes de défaillance différents, des structures de coûts différentes et des avoirs différents. Ce guide explique ce qui fait de Nostr un protocole spécifiquement, ce que cela signifie en pratique, et pourquoi la conception reste volontairement petite.

TL;DR. Nostr est un protocole de messagerie pub/sub avec signatures cryptographiques. Il définit un petit format d'événement et une façon simple pour les clients d'envoyer et de recevoir ces événements via des relays. Aucune entreprise ne le possède. N'importe qui peut écrire un client, gérer un relay ou proposer des extensions. La spécification de base tient sur quelques pages.

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

Ce qu'est réellement un protocole

Email est une bonne comparaison. Lorsque vous envoyez un email de Gmail à Outlook, Gmail n'a pas besoin de la permission d'Outlook. Les deux services parlent SMTP (le protocole email), et SMTP définit tout ce qui est nécessaire pour qu'un serveur de courrier remette un message à un autre. Les serveurs sont des entreprises différentes. Le protocole est un accord neutre.

Nostr fonctionne de la même manière. Un événement Nostr (un message, un like, un suivi) est un objet JSON avec une forme spécifique définie dans le protocole. Un relay est n'importe quel serveur qui accepte, stocke et transfère les événements conformes à cette forme. N'importe quel deux clients qui parlent Nostr peuvent interagir via n'importe quel relay qui parle Nostr, indépendamment de qui a fait quoi.

Le protocole est un accord neutre. Les implémentations sont libres d'être n'importe quoi.

La spécification Nostr, en le moins de phrases possible

Trois règles couvrent à peu près tout.

1. Un événement est un objet JSON avec id, pubkey, created_at, kind, tags, content, sig. L'id est un hash des autres champs ; le sig est une signature Schnorr sur l'id utilisant la contrepartie privée de la pubkey.
2. Un relay accepte les événements valides sur WebSocket et fournit les abonnements qui filtrent les événements par auteur, kind, tag ou temps.
3. Un client signe les événements et les publie sur les relays ; lit les événements en s'abonnant aux relays avec des filtres.

C'est le protocole de base. Chaque fonctionnalité avancée (articles longs, zaps, DM, communautés, listes) est une extension qui s'inscrit dans ce cadre sans le modifier.

Pourquoi le protocole reste petit

La plupart des protocoles croissent par accrétion. Chaque cas d'usage ajoute à la spécification ; chaque décennie la spécification est plus grande que la décennie précédente. HTTP fait maintenant des centaines de pages. Email a grandi d'une poignée de RFC à un fouillis. Nostr a évité cela par conception.

Le mécanisme est les NIP (Nostr Implementation Possibilities). Les nouvelles fonctionnalités ne sont pas ajoutées à la spécification de base ; elles sont proposées comme des NIP optionnels. Les clients implémentent les NIP qui les intéressent. D'autres clients les ignorent. Un NIP populaire devient partie du protocole pratique car suffisamment d'implémentations le parlent ; un NIP impopulaire disparaît sans cérémonie.

Cela signifie que le cœur reste à jamais petit (les invariants importants : événements signés, relays ouverts, identité portable) et les bords restent à jamais flexibles (les nouvelles fonctionnalités évoluent sans casser les clients existants). Un client Nostr de 2022 fonctionne toujours en 2026 car le cœur n'a pas changé ; il fait simplement moins de choses que les clients plus récents.

Protocole versus plateforme, concrètement

Cinq différences pratiques que vous pouvez ressentir en tant qu'utilisateur.

Identité. Sur une plateforme, votre compte est détenu par l'entreprise. Sur un protocole, votre compte est une identité cryptographique que vous possédez. Personne ne peut vous la prendre.

Données. Sur une plateforme, vos messages vivent dans leur base de données. Sur un protocole, vos messages vivent sur plusieurs relays indépendants. Si l'un disparaît, les autres les ont toujours.

Vitesse des fonctionnalités. Sur une plateforme, les fonctionnalités se déploient quand l'entreprise le décide. Sur un protocole, les fonctionnalités se déploient quand n'importe quel implémenteur les écrit. C'est plus lent à certains égards (pas de feuille de route centrale) et plus rapide à d'autres (nombreuses expériences en parallèle).

Monétisation. Sur une plateforme, l'entreprise capture toute la monétisation. Sur un protocole, la monétisation est ce que les utilisateurs et les implémenteurs acceptent. Nostr a les zaps (pourboires peer-to-peer sur Lightning) car cela correspondait à la culture ; une communauté de protocole différente pourrait arriver à des normes différentes.

Mode de défaillance. Une plateforme peut disparaître complètement. Un protocole ne peut pas ; tant qu'au moins un implémenteur reste actif, le protocole vit. Nostr est conçu de sorte que même si fiatjaf (l'auteur original) disparaissait demain, le réseau continuerait à fonctionner sans changement.

Ce que le protocole ne fait explicitement pas

Cinq choses laissées hors de la spécification à dessein.

Modération. Le protocole ne décide pas quel contenu est acceptable. Chaque relay a ses propres règles ; chaque client a ses propres filtres ; chaque utilisateur a sa propre liste de silence. La modération se produit aux bords, pas au cœur.

Recherche. Il n'y a pas de recherche définie par le protocole. Certains relays indexent le texte ; d'autres non. Les clients qui veulent une recherche s'appuient soit sur des relays compatibles avec la recherche, soit exécutent leur propre indexation. L'absence est délibérée ; elle maintient le protocole neutre sur ce qui est trouvé.

Classement. Pas de flux « Pour vous ». Pas de pondération de l'engagement. Les clients affichent les événements par timestamp par défaut ; tout autre classement est une décision au niveau du client, pas du protocole.

Découverte. Pas de moteur de recommandation. Trouver de nouveaux comptes à suivre est une fonctionnalité de client, pas une fonctionnalité de protocole. Certains clients y investissent beaucoup (Primal) ; d'autres le laissent aux utilisateurs (Damus).

Récupération. Pas de réinitialisation de compte. Perdez la clé privée, perdez le compte. Le protocole pourrait inclure la rotation des clés mais ne le fait pas, car les compromis sont réels et la communauté n'a pas accepté de mécanisme spécifique pour l'instant. C'est un domaine en cours (brouillons NIP-26, NIP-41).

Chaque omission est un choix. Les protocoles restent petits en refusant de résoudre chaque problème au niveau du protocole.

Qui décide ce que devient Nostr

Personne et tout le monde.

Il n'y a pas de Fondation Nostr. Pas de groupe de travail d'entreprise. Pas de comité directeur. L'autorité la plus concentrée n'importe où dans l'écosystème est le repo GitHub de fiatjaf où les NIP sont proposés, et même cela n'est qu'un point de coordination, pas un gardien.

Les NIP proposés sont lus par les développeurs de clients. Les populaires sont implémentés. Un NIP qu'implémentent trois clients majeurs est effectivement partie du protocole ; un NIP qu'un développeur a écrit mais avec lequel personne d'autre ne se soucie est juste un document sur GitHub.

Ce processus est désordonnée. Il y a des problèmes de coordination, des propositions dupliquées et de la politique occasionnelle. C'est aussi résilient d'une manière spécifique : aucune partie unique ne peut la ruiner en prenant une mauvaise décision, car les mauvaises décisions n'sont simplement pas adoptées. Le protocole évolue dans des directions approximatives par le poids des choix des développeurs, pas par décret.

Quand le modèle de protocole gagne

Les protocoles battent les plateformes dans des conditions spécifiques :

• Quand la propriété importe plus que le vernis. Les protocoles sont généralement moins polis que les plateformes. Ils gagnent quand vous vous souciez de ce que le vernis ne peut pas vous donner (identité permanente, résistance à la censure, interopérabilité ouverte).
• Quand l'effet réseau est la fonctionnalité. La valeur d'un protocole croît avec l'adoption par les implémenteurs, pas seulement par les utilisateurs. Plus de clients et de relays renforcent le réseau d'une manière qu'une plateforme ne peut pas copier.
• Quand l'horizon à long terme importe. Les plateformes sont achetées, vendues, fermées ou pivotent. Les protocoles survivent à tout implémenteur unique. Email est plus ancien que la plupart des entreprises ; Nostr parie sur la même dynamique.

Si votre cas d'usage ne correspond à aucun de ces éléments, une plateforme est généralement plus rapide et plus facile. C'est honnête. Nostr n'est pas universellement meilleur que Twitter pour chaque cas d'usage possible. C'est mieux des manières spécifiques où un protocole bat une plateforme.

Lire la spécification réelle

Si ce guide vous a donné envie de lire le protocole directement, le dépôt NIPs contient la liste complète. NIP-01 est le cœur ; les NIP numérotés après lui sont des extensions. Vous n'avez pas besoin de comprendre aucun d'eux pour utiliser Nostr, mais lire NIP-01 prend environ dix minutes et clarifie beaucoup.