Qu'est-ce qu'un relais Nostr ? Un guide en français simple

Chaque message Nostr passe par un relais. Votre client envoie des événements signés aux relais ; les clients d'autres utilisateurs récupèrent les événements des relais ; et cela se répète pour chaque message, like, suivi et message direct. Le relais n'est pas une composante glamour, mais c'est la composante qui fait fonctionner le réseau.

Ce guide couvre ce qu'est réellement un relais, ce qu'il fait et ne fait pas, et comment réfléchir à l'importance des relais pour vous.

TL;DR. Un relais est un petit serveur qui accepte les événements Nostr signés sur WebSocket, les stocke et les transmet aux abonnés. Il n'existe pas « un » relais Nostr ; le réseau se compose de milliers de relais indépendants qui ne se coordonnent pas. Votre client se connecte à plusieurs simultanément ; l'union est votre vue du réseau.

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

Ce qu'un relais fait

Trois fonctions, toutes simples.

Accepter les événements. Un client ouvre une connexion WebSocket et envoie un message EVENT avec un objet JSON signé. Le relais vérifie la signature (correspond-elle à la clé publique revendiquée), vérifie optionnellement les politiques (spam, limites de débit, listes de blocage), et accepte ou rejette. Les événements acceptés vont en stockage.

Stocker les événements. Les relais utilisent une base de données locale (généralement SQLite ou PostgreSQL) indexée par ID d'événement, clé publique de l'auteur, type d'événement et valeurs de balises. Cela leur permet de répondre efficacement aux filtres d'abonnement.

Servir les abonnements. Un client envoie un message REQ avec un filtre (« donne-moi les événements de ces auteurs, de ces types, depuis ce timestamp, limité à 100 »). Le relais interroge sa base de données pour les événements stockés correspondants, les transmet en continu, puis envoie EOSE (fin des événements stockés) et maintient l'abonnement ouvert. Tout nouvel événement correspondant au filtre est poussé au client en temps réel.

C'est toute l'API du relais, avec des variantes mineures. Un relais ne fait rien d'autre : pas de classement, pas de recommandation, pas de modération au-delà de ses propres politiques, pas de coordination entre relais.

Ce qu'un relais ne fait pas

Plusieurs choses qu'un relais pourrait théoriquement faire mais ne fait généralement pas.

Communiquer avec d'autres relais. Les relais sont indépendants. Ils ne se synchronisent pas entre eux. Si un message est sur le relais A mais pas sur le relais B, quelqu'un qui lit seulement depuis B ne le voit pas. La réplication se produit parce que les clients publient sur plusieurs relais, pas parce que les relais se reproduisent les uns les autres.

Appliquer des règles globales. Chaque relais a ses propres règles. Ce qu'un rejette, un autre l'accepte. Il n'y a pas d'autorité de politique globale.

Vérifier les affirmations hors chaîne. Un relais accepte les événements signés ; il ne vérifie pas que « alice@example.com » dans un champ NIP-05 correspond réellement à la clé publique de l'événement. C'est le travail du client.

Agir comme une plateforme. Un relais n'est pas un site web avec une page d'accueil, un fil d'actualité ou une marque. C'est un backend. Les utilisateurs n'interagissent jamais directement avec les relais ; les clients le font.

Pourquoi cette conception est inhabituelle

La plupart des réseaux ont des serveurs qui font beaucoup de choses. Une instance Mastodon n'est pas seulement un relais ; c'est une application web complète semblable à Twitter avec des utilisateurs, des profils, des fils d'actualité, des outils de modération, des tableaux de bord d'administration. Un serveur XMPP a des utilisateurs, des salons, MUC, pubsub. Un serveur de base Matrix est une infrastructure logicielle lourde.

Le relais Nostr est délibérément minimal. Un relais ne sait pas qui sont ses utilisateurs (pas de comptes utilisateurs sur le relais). Un relais ne possède pas son contenu (l'authenticité du contenu vient des signatures, pas de qui l'a stocké). Un relais ne fédère pas (pas de coordination au niveau du protocole avec d'autres relais).

Cette minimalité explique pourquoi il y a autant de relais. En faire fonctionner un est bon marché parce qu'un relais fait très peu. Un VPS de 5 $/mois peut faire fonctionner un relais servant des centaines d'utilisateurs actifs. Comparez cela à faire fonctionner une instance Mastodon, qui à une échelle similaire nécessite beaucoup plus de ressources et de maintenance.

Relais par défaut vs relais personnalisés

Chaque client Nostr est livré avec une liste par défaut. Les entrées communes en 2026 :

• wss://relay.damus.io (exploité par Damus, grand volume)
• wss://nos.lol (exploité par la communauté, gratuit)
• wss://relay.primal.net (exploité par Primal)
• wss://offchain.pub (communauté, stable)
• wss://relay.nostr.band (focus sur l'agrégation)
• wss://nostr.wine (payant, filtré anti-spam)

Ceux-ci fonctionnent pour la plupart des utilisateurs. Les trois premiers gèrent la plupart du trafic quotidien. Les remplacer n'est pas nécessaire à moins d'avoir une raison. (Si vous vous êtes inscrit via nostr.blog, une liste de relais par défaut organisée est déjà configurée pour vous ; vous pouvez la régler plus tard dans les paramètres.)

Raisons de personnaliser :

• Performance. Un relais plus proche de vous géographiquement est plus rapide. Si vous êtes en Asie, ajouter un relais en Asie accélère les lectures.
• Confidentialité. Si vous ne voulez pas qu'un relais majeur spécifique voit vos modèles d'abonnement, utilisez d'autres.
• Spécialisation par sujet. Certains relais se concentrent sur des sujets ou des communautés spécifiques. S'y connecter augmente votre exposition à ce contenu.
• Tolérance au spam. Si vous êtes submergé de spam, un relais payant filtré anti-spam pourrait valoir la peine.

Combien de relais devriez-vous utiliser

Trois ou quatre est généralement le bon équilibre. Plus n'est pas toujours mieux.

Trop peu (1-2). Une panne d'un seul relais vous rend silencieux temporairement. Pas assez de redondance.

Juste à point (3-6). Vos messages arrivent à suffisamment d'endroits pour que les pannes n'aient pas d'importance. La performance en lecture est bonne parce que le client peut faire des requêtes en parallèle.

Trop (10+). Chaque relais ajoute de la latence et du transfert de données. Les clients doivent les interroger tous ; les lents ralentissent tout le fil. La batterie et la bande passante augmentent sans bénéfice proportionnel.

En cas de doute, utilisez les valeurs par défaut. Si vous poursuivez une raison spécifique, ajustez progressivement.

Les politiques de relais comptent

Chaque relais a des règles écrites ou non écrites sur ce qu'il accepte. La plupart sont indulgentes ; certaines sont strictes. Quelques types de politiques courants :

Écriture ouverte, lecture ouverte. N'importe qui peut publier, n'importe qui peut lire. La plupart des relais communautaires.

Écriture payante, lecture ouverte. Vous payez une petite redevance pour publier ; n'importe qui peut lire vos messages. La plupart des relais payants. Réduit dramatiquement le spam.

Liste d'approbation. Seuls les comptes approuvés peuvent publier. Utilisé pour les relais d'entreprise ou communautaires.

Filtré par sujet. Accepte seulement les événements correspondant à certains critères (hashtag, type, longueur).

Géocloisonné. Accepte seulement les utilisateurs de régions spécifiques. Peu courant.

Avant de vous fier à un relais, vérifiez ses politiques écrites (généralement sur /.well-known/nostr.json ou le point de terminaison d'information du relais). Si votre modèle de publication ne correspond pas aux politiques du relais, les écritures échoueront silencieusement.

Faire fonctionner votre propre relais

Étonnamment facile. Une configuration de base :

1. Louez un VPS (la gamme 5 $/mois est fine).
2. Installez une implémentation de relais. strfry et nostream sont les deux choix open-source courants.
3. Ouvrez le port 443 ou 8080 ; pointez le DNS vers le serveur.
4. Démarrez le relais.

Temps total : moins d'une heure pour quelqu'un à l'aise avec Linux. Aucune configuration complexe requise en dehors de la boîte. Faire fonctionner un relais pour vous-même ou une petite communauté ajoute de la résilience au réseau et vous donne un contrôle explicite sur une partie de vos données Nostr.

Un guide dédié à cela se trouve dans run-your-own-relay.

Relais et confidentialité

Chaque relais auquel vous vous connectez voit :

• Votre adresse IP
• Les filtres auxquels vous vous abonnez (quelles clés publiques vous lisez, quels hashtags vous suivez)
• Vos messages (leur contenu, puisque vous les avez publiés ici)
• Synchronisation de votre activité

Les relais ne voient pas :

• Contenu des messages directs chiffrés (seulement le texte chiffré)
• Votre clé privée

Pour les utilisateurs qui se soucient de minimiser la fuite de métadonnées au niveau du relais :

• Utilisez Tor ou un VPN.
• Répartissez vos lectures sur de nombreux relais pour qu'aucun ne voit le tableau complet.
• Utilisez des clients qui font tourner les relais pour différents types d'abonnement.

La plupart des utilisateurs n'ont besoin d'aucun de cela. Le modèle de confidentialité du protocole suppose que les relais sont une infrastructure semi-fiable et semi-publique ; il n'est pas conçu pour masquer vos modèles d'activité à leur égard.

Choisir des relais : une règle simple

Si vous êtes nouveau : gardez les valeurs par défaut.

Si vous êtes spécifiquement frustré par quelque chose (spam, vitesse, fiabilité) : ne changez que ce qui vous frustre. Ajoutez un ou deux relais, ou remplacez celui qui vous ennuie.

Si vous êtes avancé : sélectionnez intentionnellement. Choisissez 4-6 relais qui répondent à vos besoins (géographie, sujets, niveau de confiance) et gérez-les soigneusement.

Si vous êtes paranoïaque : répartissez sur suffisamment de relais indépendants pour qu'aucun opérateur ne voit votre activité complète. Utilisez Tor. Mélangez les régions.

Le mauvais geste est d'ajouter des dizaines de relais en espérant que plus c'est mieux. Des clients lents et une bande passante gaspillée en sont le résultat, pas une meilleure expérience.