Comment fonctionne réellement Nostr : le protocole, sans jargon

La plupart des explications de Nostr s'arrêtent à « c'est un protocole social décentralisé » et laissent la partie intéressante de côté. La partie intéressante c'est que le protocole entier tient dans un court document. Pas d'astuce maligne, pas de complexité cachée. Juste quelques primitives qui fonctionnent ensemble.

Ce guide parcourt ces primitives dans l'ordre où elles apparaissent quand vous utilisez réellement Nostr : comment un événement est construit, comment il est signé, comment il atteint les relais, comment les clients s'abonnent, et à quoi ressemble le flux quand vous aimez un message, recevez une réponse, ou recevez un zap. Pas de comparaisons blockchain, pas de grand récit. Juste la mécanique.

TL;DR. Nostr est du pub/sub sur WebSockets avec des signatures cryptographiques. Les clients publient des objets JSON signés (événements) sur des relais (petits serveurs), et les autres clients s'abonnent aux relais avec des filtres qui correspondent aux événements qu'ils veulent. Les signatures préviennent la falsification ; les relais multiples préviennent les points de défaillance unique. C'est tout le protocole ; tout le reste c'est des conventions de formatage pour différents types de contenu.

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

Le bloc de construction : un événement

Tout sur Nostr est un événement. Un message est un événement. Une réaction est un événement. Une mise à jour de profil est un événement. Un message direct est un événement. Un reçu de zap est un événement.

Un événement est un objet JSON avec exactement cette forme :

{
  "id": "abc123...",
  "pubkey": "0a4f7b1a3d9a1529a3080c3ae5ee553e0af0a01d86d01677c0bb270592923f88",
  "created_at": 1776329035,
  "kind": 1,
  "tags": [
    ["t", "nostr"],
    ["p", "3bf0c63f..."]
  ],
  "content": "hello nostr",
  "sig": "def456..."
}

Six champs font un travail significatif. id est un hash du contenu propre de l'événement ; il l'identifie uniquement. pubkey est l'auteur (une clé publique de 64 caractères hexadécimaux). created_at est un timestamp Unix. kind est un entier décrivant ce que représente l'événement (plus d'informations ci-dessous). tags est une liste d'annotations structurées telles que les hashtags (t), les mentions (p pour pubkey, e pour event), et des dizaines d'autres. content est la charge utile de forme libre, généralement du texte.

sig est la signature Schnorr, faite avec la clé privée de l'auteur, sur le hash dans id. C'est le champ qui prévient la falsification : n'importe qui peut calculer le hash, mais seul le détenteur de la clé privée peut produire une signature valide sur lui.

Qu'est-ce qu'une « sorte »

Le champ kind indique aux clients comment interpréter l'événement. Le nombre est tout le type sémantique.

Quelques sortes en usage actif :

Les nouvelles sortes sont proposées et standardisées via NIPs (Nostr Implementation Possibilities). N'importe qui peut en proposer une. Celles qui sont largement adoptées deviennent de facto des parties du protocole ; celles qui ne le sont pas restent simplement niche sans rien casser.

Comment un événement est publié

Quand vous appuyez sur « publier » dans un client Nostr, cette séquence s'exécute :

1. Le client assemble le JSON. Remplissez pubkey, created_at, kind, tags, content.
2. Le client calcule l'id. Lance SHA-256 sur une sérialisation canonique de ces champs. C'est le hash que la signature couvre.
3. Le client signe l'id avec la clé privée. Signature Schnorr sur secp256k1, la même courbe que Bitcoin utilise. La signature de 64 octets devient le champ sig.
4. Le client ouvre des connexions WebSocket à chaque relais configuré. Ou réutilise les connexions existantes ouvertes si elles sont actives.
5. Le client envoie l'événement en tant que message. Le format sur le fil est un tableau JSON : ["EVENT", {...event...}].
6. Chaque relais valide la signature. Rejette l'événement si la signature ne vérifie pas contre la pubkey revendiquée. Accepte et stocke sinon.
7. Chaque relais envoie l'événement aux abonnés. Tout client avec un abonnement ouvert dont le filtre correspond à cet événement reçoit l'événement en temps réel.

Le trajet complet prend 50 à 300 millisecondes selon les emplacements des relais. Si un relais est lent ou hors ligne, les autres relais publient toujours l'événement. Vous n'avez besoin que d'un seul relais pour l'accepter pour que l'événement existe sur le réseau.

Comment un client récupère les messages

La lecture est le miroir de la publication.

Votre client ouvre des connexions WebSocket à une liste de relais. Pour chacun, il envoie un message d'abonnement :

["REQ", "sub_id_1", { "authors": ["pubkey1", "pubkey2", ...], "kinds": [1, 6], "limit": 50 }]

Cela demande au relais jusqu'à 50 événements des auteurs de la liste, de sorte 1 (note courte) ou sorte 6 (partage). Le relais :

1. Interroge sa base de données locale pour les événements correspondants, les envoie (du plus ancien au plus récent par défaut, jusqu'à la limite) en tant que messages EVENT au client.
2. Envoie un message EOSE (fin des événements stockés) pour que le client sache que le vidage historique est complet.
3. Garde l'abonnement ouvert. Tout nouvel événement qui correspond au filtre (publié par quelqu'un d'autre plus tard) est envoyé au client en temps réel.

C'est ainsi que votre flux devient vivant. Vous ne sondez pas ; le relais diffuse.

Votre client le fait en parallèle sur tous les relais configurés. L'union des réponses est votre timeline. Les événements en double sur les relais sont dédupliqués par id.

Comment les signatures préviennent réellement la falsification

C'est la partie que la plupart des explications escamotent.

Quand un client reçoit un événement, il recalcule le hash sur la sérialisation canonique (de la même façon que l'éditeur l'a fait) et exécute la vérification Schnorr : compte tenu de pubkey, id, et sig, la signature vérifie-t-elle cryptographiquement ?

Si oui, l'événement est authentique. L'auteur de cet événement était le détenteur de cette pubkey au moment de la signature. Chaque client exécute cette vérification sur chaque événement. Un relais qui expédie un événement forgé avec une mauvaise signature se fait juste l'événement rejeté silencieusement par chaque client qui le voit.

C'est important car cela signifie que les relais ne sont pas de confiance. Un relais malveillant ne peut pas mettre des paroles dans votre bouche. Il peut refuser de servir vos messages, il peut injecter les messages (légitimes) de quelqu'un d'autre dans votre flux, mais il ne peut pas produire un message valide signé par vous sans votre clé privée, et il ne peut pas en modifier un de vos messages existants sans casser la signature.

Le coût de cette propriété est exactement une vérification Schnorr par événement, ce qui est assez rapide pour que même les clients mobiles le gèrent à des dizaines de milliers d'événements par seconde.

Ce que les relais font réellement

Un relais est un tuyau bête et rapide avec trois tâches :

1. Acceptez les événements et validez les signatures. Rejeter tout ce qui ne vérifie pas ou échoue les vérifications de politique (filtres spam, limites de taille, clés publiques bloquées).
2. Stockez les événements. Généralement dans une base de données SQLite ou PostgreSQL indexée par id, pubkey, kind, et les valeurs de tags.
3. Servez les abonnements. Correspondez les filtres REQ entrants à la base de données (pour l'historique) et aux événements en direct (pour le temps réel).

C'est tout. Un relais ne classe pas, ne recommande pas, ne sélectionne pas, ne monétise pas, n'affiche pas de publicités, n'applique pas d'algorithme, et ne fait rien ce qu'une plateforme ferait. Il transmet les octets signés.

L'absence de ces autres tâches c'est pourquoi les relais peuvent être minuscules. Un seul VPS à 5 $/mois peut exécuter un relais servant des centaines d'utilisateurs actifs. La même fonction à l'échelle de Twitter coûte des milliards car Twitter fait toutes les autres choses.

Les politiques des relais diffèrent. Certains sont sans permission et servent tout événement signé. D'autres nécessitent un paiement (le modèle « relais payant »), d'autres se limitent à une communauté spécifique (employés d'une entreprise, membres d'un serveur Discord), et d'autres encore sont agressifs sur le filtrage du spam. Vous choisissez quels relais utiliser ; votre choix affecte quels messages vous voyez et lesquels atteignent vos followers.

Un exemple complet : quelqu'un aime votre message

En reliant les points, voici ce qui se passe de bout en bout quand Alice aime un message que Bob a écrit.

1. Bob publie. Le client de Bob construit un événement kind:1 avec le contenu « hello world », le signe, l'envoie aux cinq relais configurés de Bob. Chaque relais accepte et stocke.
2. Alice s'abonne. Le client d'Alice a un abonnement ouvert sur deux de ces relais avec un filtre qui inclut la pubkey de Bob dans authors. Les relais envoient l'événement de Bob down the subscription. Le client d'Alice affiche le message dans sa timeline.
3. Alice appuie sur like. Le client d'Alice construit un événement kind:7 avec le contenu « + » (la convention Nostr « like »), étiquette le message auquel il réagit (["e", "bob_post_id"]) et l'auteur (["p", "bob_pubkey"]). Signe et publie sur les cinq relais configurés d'Alice.
4. La réaction se propage. Tout relais qui a un abonnement actif correspondant au filtre { "#e": ["bob_post_id"], "kinds": [7] } (ce que le client de Bob utilise pour regarder les réactions à ses propres messages) envoie la réaction à Bob. Le client de Bob agrège les likes et affiche le compte sous le message.

Remarquez ce qui ne s'est pas passé. Aucun service centralisé « bouton like » n'a été appelé. Aucun backend n'a décidé si le like compte. Le like est juste un événement signé, annoncé sur les mêmes canaux que le message lui-même.

Ce que Nostr ne fait explicitement pas

Cinq choses omises du protocole de base à dessein, car elles appartiennent au client ou au relais, pas au format de fil partagé.

• Vérification d'identité. Nostr prouve seulement « cette pubkey a signé ce message ». Que la pubkey appartient à un être humain spécifique est une question distincte répondue par NIP-05 et le contexte hors chaîne.
• Modération de contenu. Le protocole ne décide pas ce qui est visible. Les clients filtrent, les relais filtrent, les utilisateurs filtrent. Chaque couche indépendamment.
• Recherche. Il n'y a pas de point de terminaison de recherche global. Certains relais supportent la recherche textuelle sur leur pool d'événements local ; il n'y a pas de garantie de protocole qu'un relais peut trouver n'importe quel message.
• Classement algorithmique. Pas de flux « pour vous » dans le protocole. Le classement se fait dans le client si du tout.
• Récupération de compte. Pas de réinitialisation par email, pas de réinitialisation par téléphone, pas de système de litige central. Perdez la clé privée, perdez l'identité. C'est un compromis, pas un bug.

Ces absences c'est ce qui rend le protocole petit. C'est aussi ce qui rend la construction d'une expérience utilisateur polie plus difficile que de construire sur une plateforme centralisée, ce qui est le coût honnête.

Pourquoi la conception fonctionne du tout

La conception repose sur une propriété simple : les signatures sont bon marché à vérifier, la falsification est impossible sans la clé privée, et les relais sont libres de remplacer.

Ces trois faits se composent. La vérification bon marché signifie que chaque client peut vérifier chaque événement. La falsification impossible signifie que les relais ne doivent pas être de confiance. Le remplacement libre signifie qu'aucun relais n'a de pouvoir sur quiconque.

Ensemble, vous obtenez un réseau social où la couche plateforme est interchangeable et la couche identité est détenue par l'utilisateur. C'est ce que « décentralisé » signifie réellement en pratique, par opposition à la façon dont le marketing utilise généralement le mot.

Si vous voulez voir le flux entier du côté utilisateur (une paire de clés, une identité NIP-05, une liste de relais, un portefeuille, prêt à publier), l'inscription de nostr.blog réduit ces étapes en une seule page. La mécanique décrite ici c'est ce qui fonctionne réellement sous ce flux.