Nostr

Plateforme · l'analyse détaillée est élaborée à partir des pages officielles pages de la plateforme elle-même et des outils d'accompagnement.

Voir aussi : comment lire les fiches и sur les sources et sur la méthode.

Aperçu

Nostr n'est pas une plateforme, mais un protocole. Le nom est l'acronyme de Notes and Other Stuff Transmitted by Relays — «des notes et autres choses transmises par des relais». Le site nostr.com le décrit ainsi : «un réseau libre et ouvert que personne ne possède et que personne ne contrôle».

La structure est simple et tout le reste en découle. Il y a les relais — des serveurs qui conservent et distribuent les messages. Il y a les clients — des applications par lesquelles les gens lisent et écrivent. Et il y a les clés : la clé publique fait office de nom d'utilisateur, la clé privée de mot de passe ; ce sont les clés, et non une entreprise, qui vous donnent droit à votre identité. Comme l'identité appartient à la clé et non à l'application, vous pouvez passer d'un client à l'autre en conservant votre profil, vos abonnés et vos publications.

Techniquement, tout se ramène à un seul type d'objet. Le document de base du protocole énonce : le seul type d'objet existant est l'«événement» (event), les signatures et les clés utilisent le schéma de Schnorr sur la courbe secp256k1, et le relais expose vers l'extérieur un point websocket auquel le client envoie trois sortes de messages : EVENT pour publier, REQ pour s'abonner à une sélection et CLOSE pour la fermer.

Pour un annuaire, cela signifie ceci : Nostr n'a ni propriétaire, ni audience unique, ni régie publicitaire, ni règles de modération, ni programme de paiements. Ce qui suit examine ce qui existe à leur place.

Qui est présent ici

Le chiffre de l'audience de Nostr n'existe pas — et ne peut pas exister sous la forme habituelle. Il n'y a pas de serveur central qui compterait les utilisateurs : il y a une multitude de relais indépendants, dont chacun ne voit que les siens.

On ne peut juger qu'indirectement, relais par relais. Le client sur nostr.com se connecte par défaut à six relais et affiche leur liste directement dans l'interface : relay.nostr.com, relay.damus.io, nos.lol, nostr.bitcoiner.social, nostr.mom et relay.snort.social. Pour le catalogue des relais, le projet recommande l'outil tiers Nostr.watch, et pour le catalogue des clients, nostrapps.com (page sur les relais, page sur les clients).

Aucune répartition par langue ou par pays n'existe et ne peut exister : le protocole ne conserve pas ce genre d'information sur l'utilisateur. Le profil par défaut ne contient qu'un nom, une description et une image.

Comment commencer

Il n'y a pas d'inscription au sens habituel : le compte est une paire de clés générée par l'application. Ni confirmation d'adresse électronique, ni numéro de téléphone, ni modération de la demande.

D'où le principal risque, contre lequel le projet lui-même met en garde : la clé privée donne un accès complet au compte — elle permet d'écrire en votre nom, de modifier le profil et d'envoyer des messages ; si la clé est perdue et qu'il n'en existe pas de copie, il n'y a pas de bouton «mot de passe oublié». Conseil pratique du projet : n'introduisez pas votre clé privée dans n'importe quelle application — une extension de navigateur qui signe ou un signataire distant est plus sûr.

Il est possible d'obtenir un nom vérifiable, comparable à une «coche» : un document distinct du protocole décrit la liaison d'une clé à un domaine. Le client prend dans le profil une adresse de la forme nom@domaine, interroge https://domaine/.well-known/nostr.json?name=nom et compare la clé publique obtenue à celle de l'auteur de la publication. Pour une entreprise, c'est le moyen de confirmer que le compte est bien le sien : la confirmation vient du contrôle du domaine, et non de la décision d'un modérateur.

Il n'existe pas de compte professionnel distinct — pas plus qu'il n'existe de compte ordinaire. La présence d'une entreprise sur Nostr, c'est une clé liée à son domaine et, si elle le souhaite, son propre relais.

Ce que l'on peut publier

Les formats sont définis par les «sortes» d'événements, et ces sortes sont décrites dans des documents distincts — les NIP (Nostr Implementation Possibilities). Leur liste est tenue dans un dépôt ouvert et comprend, entre autres : les notes courtes et les fils de discussion, les textes longs, les images et les vidéos, les directs et les «spaces», les sondages, les événements de calendrier, les wikis, les torrents, les listes, les signets et les citations (liste des NIP).

Le protocole n'impose pas de limites de longueur ni de taille — c'est le relais qui les fixe, et il est tenu de les annoncer. Le document sur les informations relatives au relais décrit les champs suivants : max_message_length — la taille maximale du JSON entrant en octets (elle limite de fait la taille de l'événement), max_content_length — le nombre maximal de caractères du champ de contenu, max_event_tags — le nombre maximal d'étiquettes, max_subscriptions — le nombre d'abonnements simultanés sur une même connexion, max_limit — le plafond du nombre d'événements dans la réponse à une seule requête.

Voici ce que cela donne en pratique. À la date de la vérification, le relais relay.damus.io annonce une limite de message de 1 000 000 octets, 200 abonnements et un plafond de sélection de 500 événements ; le relais nos.lol — 131 072 octets, 20 abonnements, les mêmes 500 événements ; le relais relay.nostr.com — 131 072 octets, 200 abonnements, 500 événements. Ces chiffres appartiennent à chaque relais pris séparément, et sur un autre relais ils seront différents.

Le protocole ne comporte aucune interdiction de contenu. Il y a un balisage technique : un document distinct décrit le marquage des contenus sensibles, un autre les signalements d'événements, un troisième la demande de suppression. Notez le mot «demande» : la suppression dans Nostr est une requête adressée aux relais, et non une garantie. C'est le propriétaire du relais qui décide de ce qu'il accepte et conserve.

Comment se développer

Le protocole ne comporte pas de fil algorithmique. Ce qui est montré à l'utilisateur, c'est le client qui le décide, et quels événements sont fournis, c'est le relais. Le client sur nostr.com le montre directement : son interface propose les fils «abonnements», «global» et «le vôtre», et en dessous la liste des relais connectés.

D'où une conséquence pratique que le projet explique lui-même : si Nostr vous paraît lent ou vide, cela peut venir des relais ; certains relais sont rapides et fiables, d'autres se déconnectent et ne répondent pas, et ajouter quelques bons relais change beaucoup de choses. Se développer sur Nostr, c'est avant tout publier sur les relais où il y a réellement des lecteurs.

Il n'existe pas de régie publicitaire : le protocole n'a ni plateforme qui vendrait des impressions, ni mécanisme pour les comptabiliser. Il n'y a pas non plus de statistiques intégrées ; ce qui s'en rapproche le plus, c'est la requête COUNT, que le relais exécute dans la mesure du possible et de manière approximative.

Le protocole propose un moyen inhabituel de lutter contre le spam : le document sur la preuve de travail permet au relais d'exiger des nouveaux événements une complexité de calcul donnée. Le deuxième moyen, c'est l'argent : une partie des relais sont payants, ce qui réduit le spam, parce que l'entretien d'un relais coûte de l'argent et que les utilisateurs ont alors une raison de bien se tenir.

La voie vers la monétisation

Il n'y a pas de plateforme — donc pas de paiements versés par une plateforme. En revanche, il y a des paiements directs entre personnes, et ils sont décrits dans le protocole lui-même.

Le mécanisme s'appelle le «zap» — un paiement via le réseau Lightning. Le document du protocole introduit deux sortes d'événements : 9734 — la demande de zap, c'est-à-dire la sollicitation adressée par le payeur au portefeuille du destinataire pour obtenir une facture, et 9735 — le reçu, la confirmation par le portefeuille du destinataire que la facture est payée. Le déroulement est le suivant : le client prend dans le profil du destinataire l'adresse de son point de paiement, vérifie qu'il prend en charge Nostr, y envoie une demande signée et reçoit une facture ; après le règlement, le portefeuille publie le reçu. Le sens du reçu y est expliqué également : il permet aux clients d'afficher les paiements directement dans le fil — pour le plaisir ou comme moyen de lutte contre le spam.

Dans ce schéma, il n'y a pas de commission de plateforme — l'argent va d'un portefeuille à l'autre. Mais il n'y a pas non plus de garanties de plateforme : l'acheminement du paiement dépend du réseau Lightning et du fournisseur de portefeuille que vous avez choisi.

Outre les zaps, la liste du protocole contient d'autres mécanismes monétaires : les objectifs de collecte (zap goals), les badges, les portefeuilles Cashu et les «nutzaps», la connexion à distance d'un portefeuille et les événements de commande entre personnes. Chacun d'eux est mis en œuvre par le client s'il le souhaite.

Outils et automatisation

Nostr n'a pas d'«API officielle», pour la même raison qu'il n'a pas de propriétaire : le protocole lui-même est l'interface. N'importe quel programme peut ouvrir un websocket vers un relais et travailler directement avec lui (document de base). Il n'existe ni clés de développeur, ni demandes d'accès, ni modération des applications.

Avant de construire un outil, il vaut la peine de lire l'avertissement figurant dans la liste elle-même : «Les NIP ici ne sont pas une liste de contrôle du protocole. Rien n'oblige un programme quelconque à mettre en œuvre un NIP quelconque. Chaque application choisit le sous-ensemble nécessaire à sa tâche». Cela signifie qu'on ne peut pas compter sur une fonction du seul fait qu'elle est décrite : il faut vérifier si le relais concerné la prend en charge. Un moyen de vérification est prévu : le relais fournit par HTTP un document contenant la liste des NIP pris en charge, le nom du programme, sa version, les contacts et un lien vers ses conditions d'utilisation. Les trois relais cités plus haut annoncent le même ensemble : tous trois fonctionnent avec le programme strfry et prennent en charge les NIP 1, 2, 4, 9, 11, 28, 40, 45, 70 et 77.

Parmi les moyens prêts à l'emploi, le projet cite les extensions de navigateur pour la signature et les signataires distants, ainsi que son propre signataire Pomegranate. Les catalogues de clients et de relais sont tenus en dehors du protocole — sur nostrapps.com et Nostr.watch (page sur les clients, page sur les relais).

Limites et règles

• Il n'y a pas de règles communes. Il n'existe aucun document qui interdirait quoi que ce soit à tous les participants du réseau. Les règles sont fixées par le propriétaire du relais ; le protocole prévoit seulement un lien vers les conditions d'utilisation dans les informations relatives au relais.
• Les limites sont fixées par le relais, qui les annonce lui-même : taille du message, longueur du contenu, nombre d'étiquettes, nombre d'abonnements, plafond de sélection.
• Le relais peut exiger une connexion selon le protocole d'authentification ou une preuve de travail pour les nouveaux événements.
• La suppression n'est pas garantie : le document décrit précisément une «demande de suppression», et c'est chaque relais qui décide de l'exécuter ou non.
• La perte de la clé est irréversible. Il n'existe pas de récupération d'accès.
• Le réseau n'a pas de cadre juridique. La responsabilité incombe au propriétaire du relais et à l'auteur ; le protocole n'a pas de personne morale avec laquelle conclure un contrat. La liste des NIP elle-même est publiée dans un dépôt sans licence indiquée.

À qui cela convient

Cela convient aux projets pour lesquels l'indépendance vis-à-vis du propriétaire d'une plateforme compte : l'identité appartient à la clé et non à une entreprise, un compte ne peut pas être bloqué de manière centralisée, et s'il vous déplaît, il suffit de changer de relais. Cela convient aux développeurs : se connecter au réseau n'exige ni clé d'application, ni approbation.

Cela convient aux projets liés au bitcoin et à Lightning : les paiements sont intégrés au protocole sous la forme de zaps, et c'est la partie la plus développée de sa mécanique monétaire.

Cela ne convient pas si vous avez besoin d'une portée prévisible et de comptes rendus : il n'y a rien à mesurer ici — ni plateforme, ni statistiques, ni régie publicitaire. Cela ne convient pas non plus aux envois de masse ni à la «promotion» : le relais est en droit d'exiger un paiement, une connexion ou une preuve de travail, et de vous couper l'accès sans explication. Et cela ne convient pas si votre organisation exige un contrat avec un prestataire de services : le protocole n'a pas de partie de ce genre.

Données vérifiées issues de la base

Données vérifiées en bref, sur lesquelles s'appuie l'analyse détaillée.

À propos de la plateforme

la plateforme se décrit ainsi : «Nostr is a free and open-source protocol for social media and other things - controlled by users, not platforms.»

autodescription : il s'agit d'une déclaration de la plateforme sur elle-même, et non d'une évaluation indépendante

source, vérifié 2026-07-28

Nostr (Notes and Other Stuff Transmitted by Relays) est décrit comme un réseau libre et ouvert que personne ne possède et que personne ne contrôle ; les relais stockent et diffusent les messages, les clients permettent de les lire et de les écrire

C'est un protocole et non une plateforme : il n'a ni propriétaire, ni régie publicitaire, ni programme de paiements

source, vérifié 2026-07-28

il n'existe qu'un seul type d'objet — l'événement (event) ; les signatures et les clés utilisent le schéma de Schnorr sur la courbe secp256k1 ; le relais expose un point websocket, le client envoie EVENT pour publier, REQ pour s'abonner et CLOSE pour fermer l'abonnement

Document de base du protocole, NIP-01

source, vérifié 2026-07-28

Par où commencer

le seuil d'entrée dans nostr n'a pas de propriétaire unique des règles : «Nostr (Notes and Other Stuff Transmitted by Relays) is a free and open network that nobody owns or controls» ; le recueil des propositions relatives au protocole dit la même chose de lui-même : «NIPs listed here are not a protocol checklist. Nothing forces any software to implement any NIP»

citations littérales, langue de la source : l'anglais. La seconde provient du README du recueil des NIP : https://raw.githubusercontent.com/nostr-protocol/nips/master/README.md. Conclusion pratique pour le lecteur : il n'existe pas de conditions d'entrée uniques et obligatoires pour tout le réseau ; les conditions sont posées par chaque relais et chaque application, et elles diffèrent

source, vérifié 2026-08-07

un relais est en droit de fermer l'écriture, d'exiger une authentification par signature ou une preuve de travail : la liste des limitations de NIP-11 nomme «auth_required», «restricted_writes», «min_pow_difficulty», «payment_required» ; «Your client should expect that requests exceed these practical limitations are rejected or fail immediately»

citations littérales, la langue de la source est l'anglais, l'orthographe de la source est conservée. Il n'existe au niveau du protocole ni candidature, ni invitation, ni modération ; tout ce qui est énuméré relève d'un relais particulier, et on peut le connaître en demandant au relais son document d'information

source, vérifié 2026-08-07

Compte et accès

un compte est une paire de clés et non un enregistrement chez le propriétaire d'une plateforme : «Every account has Nostr keys. Your public key is like your username and can be shared with anyone. Your private key is like your password and must be kept safe. These keys give you ownership of your identity, rather than a company owning it for you»

citation littérale, langue de la source : l'anglais. Ni inscription, ni vérification d'identité, ni approbation ne sont nécessaires pour obtenir des clés : la paire de clés est engendrée sur l'appareil. Un nom vérifiable facultatif de la forme nom@domaine est décrit dans un NIP distinct, le NIP-05

source, vérifié 2026-08-07

le compte dispose d'une paire de clés : la clé publique sert de nom d'utilisateur, la clé privée de mot de passe ; l'identité appartient à la clé et non à l'application, on peut donc changer de client en conservant son profil et ses abonnés

Il n'y a ni inscription, ni confirmation par courriel, ni modération de la demande

source, vérifié 2026-07-28

en cas de perte de la clé privée sans copie de sauvegarde, l'accès est irrécupérable : le bouton «mot de passe oublié» n'existe pas

Le projet conseille de ne pas insérer la clé privée dans chaque application, mais d'utiliser une extension signataire ou un signataire distant

source, vérifié 2026-07-28

nom vérifiable de la forme nom@domaine : le client interroge https://domaine/.well-known/nostr.json?name=nom et compare la clé publique obtenue avec celle de l'auteur de l'enregistrement

Pour une société, c'est un moyen de confirmer le compte par le contrôle du domaine, et non par la décision d'un modérateur

source, vérifié 2026-07-28

Ce qu'on peut publier

la liste des NIP décrit notamment : les notes courtes et les fils, les contenus longs, les images et les vidéos, les directs et les spaces, les sondages, les événements de calendrier, les wikis, les torrents, les listes, les signets et les citations

La liste des NIP n'est pas un engagement : rien n'oblige un programme à implémenter tel ou tel NIP

source, vérifié 2026-07-28

Comment on est payé ici

Qui est accepté. il n'y a pas de seuil d'abonnés, de vues ni de nombre de publications pour les paiements : les zaps vont directement d'une personne à une autre par le réseau Lightning, et la seule condition est que le destinataire dispose d'un portefeuille avec une adresse lnurl — «Client calculates a recipient's lnurl pay request url from the zap tag on the event being zapped, or by decoding their lud16 field on their profile»

citation littérale, la langue de la source est l'anglais. Seuil nul : NIP-57 n'exige ni nombre d'abonnés, ni heures de visionnage, ni ancienneté du compte. Les montants limites sont fixés par le portefeuille du destinataire au moyen des champs «minSendable» et «maxSendable», et non par le réseau

source, vérifié 2026-08-07

il n'y a pas de commission de réseau et personne ne pourrait en prélever : l'argent passe à côté du protocole, par le portefeuille du destinataire, et nostr ne participe pas au règlement — NIP-57 ne décrit que deux types d'événements, l'enregistrement de la demande et l'enregistrement du reçu : «9734 is a zap request… 9735 is a zap receipt, representing the confirmation by the recipient's lightning wallet that the invoice issued in response to a zap request has been paid»

citation littérale, la langue de la source est l'anglais. Le portefeuille ou un nœud du réseau Lightning peut prélever sa propre commission — cela ne relève plus de nostr, et son montant n'est pas fixé dans NIP-57. Le réseau n'a ni commission, ni part, ni seuil de paiement, parce qu'il n'y a pas d'intermédiaire qui détiendrait l'argent

source, vérifié 2026-08-07

les paiements entre personnes sont décrits dans le protocole comme des «zaps» via le réseau Lightning : l'événement 9734 est la demande de zap, l'événement 9735 le reçu du portefeuille du destinataire attestant le paiement de la facture

Le schéma ne comporte aucune commission de plateforme : l'argent va de portefeuille à portefeuille ; la responsabilité de l'acheminement incombe au réseau Lightning et au fournisseur du portefeuille

source, vérifié 2026-07-28

la liste des NIP contient aussi les objectifs de collecte (zap goals), les badges, les portefeuilles Cashu et les nutzaps, la connexion distante d'un portefeuille et les événements de commande entre personnes

Chaque mécanisme est implémenté par le client s'il le souhaite

source, vérifié 2026-07-28

Combien ça coûte

le protocole ne prélève pas d'argent, mais un relais donné le peut : NIP-11 prévoit des champs pour le paiement — «Relays that require payments may want to expose their fee schedules» : «fees»: «admission» (frais d'admission), «subscription» (abonnement avec le champ «period»), «publication» (frais de publication, avec indication des types d'événements) ; la liste des limitations du relais comporte l'indicateur «payment_required»

citations littérales, la langue de la source est l'anglais. Les montants sont fixés par chaque relais lui-même, il n'existe donc pas de prix d'entrée unique pour le réseau. Exemple donné dans NIP-11 même comme modèle de réponse du relais nostr.wine : «fees»: «admission»: ({«amount»: 18888000, «unit»: «msats»}) — c'est une déclaration du relais dans l'exemple du document, et non notre calcul ni une promesse de prix actuel

source, vérifié 2026-08-07

Limites et restrictions

le relais déclare ses limites dans son document d'informations : max_message_length (taille du JSON entrant), max_content_length (caractères dans le champ de contenu), max_event_tags, max_subscriptions, max_limit ; une authentification et une preuve de travail peuvent être exigées

Document NIP-11 ; le protocole n'a pas de limites propres de longueur ni de taille

source, vérifié 2026-07-28

le relais relay.damus.io déclare à la date de la vérification une limite de message de 1 000 000 octets, 200 abonnements simultanés et un plafond de sélection de 500 événements ; programme strfry

Le nombre appartient à ce relais, sur un autre il est différent

source, vérifié 2026-07-28

le relais nos.lol déclare une limite de message de 131 072 octets, 20 abonnements et un plafond de sélection de 500 événements

Mesuré par une requête du document d'informations du relais

source, vérifié 2026-07-28

le relais relay.nostr.com déclare une limite de message de 131 072 octets, 200 abonnements et un plafond de sélection de 500 événements ; NIP déclarés : 1, 2, 4, 9, 11, 28, 40, 45, 70, 77

damus.io et nos.lol déclarent le même jeu de NIP

source, vérifié 2026-07-28

Restrictions

il n'existe pas de règles uniques : ce qu'il faut accepter et conserver est décidé par le propriétaire du relais ; le protocole prévoit seulement un lien vers les conditions d'utilisation dans les informations du relais

La suppression est décrite comme une «demande de suppression», dont l'exécution n'est pas garantie

source, vérifié 2026-07-28

moyens contre le pourriel : le relais peut exiger une preuve de travail d'une difficulté donnée ou une authentification ; une partie des relais sont payants, ce qui, selon l'explication du projet, réduit le pourriel

Nostr.watch est recommandé par le projet comme annuaire de relais, et nostrapps.com comme annuaire de clients

source, vérifié 2026-07-28

le fichier robots de nostr.com autorise l'exploration du site à tous les agents

Vérifié séparément

source, vérifié 2026-07-28

Aspects juridiques

le dépôt de la liste des NIP est publié sans licence indiquée

Le protocole n'a pas de personne morale avec laquelle il serait possible de conclure un contrat

source, vérifié 2026-07-28

Accès par API

le client sur nostr.com se connecte par défaut à six relais : relay.nostr.com, relay.damus.io, nos.lol, nostr.bitcoiner.social, nostr.mom, relay.snort.social

La liste est visible directement dans l'interface

source, vérifié 2026-07-28

il n'existe pas d'«API officielle» distincte : l'interface est le protocole lui-même, tout programme peut ouvrir un websocket vers un relais ; il n'existe ni clés de développeur ni modération des applications

La prise en charge de fonctions précises doit être vérifiée dans le document d'informations du relais

source, vérifié 2026-07-28

Langues

langue de l'interface de la page d'accueil : en

La langue provient de l'attribut du balisage, les versions des liens hreflang

source, vérifié 2026-07-28

Section du catalogue : tous les similaires Voir aussi : index du catalogue · comparaison des planificateurs · sélection selon la situation · restrictions des plateformes