Schéma futur des communications sociales : les débuts de Nostr et la prochaine étape des communications sociales
TechFlow SélectionTechFlow Sélection
Schéma futur des communications sociales : les débuts de Nostr et la prochaine étape des communications sociales
Ouvrir la « porte merveilleuse » des protocoles sociaux de communication.
Dédié à des analyses Web3 approfondiesCeci est le deuxième article d'une série intitulée « la trinité des infrastructures sociales Web3 ». Cette série part de l'ère de l'ordinateur mondial d'Ethereum, prenant comme point de bascule vers une « nouvelle trinité » la publication du livre blanc de Binance Greenfield, pour explorer les rôles fondamentaux respectifs de trois piliers dans l'écosystème Web3 : le calcul décentralisé, le stockage décentralisé et la communication décentralisée. Depuis longtemps, le calcul décentralisé occupe le devant de la scène à travers le débat entre couches L1 et L2 ; le potentiel du stockage décentralisé a été largement mis en lumière grâce à l'appui fort de Binance ; quant à la troisième pièce du puzzle — la « communication décentralisée » — elle s'apprête à devenir le prochain grand point d'intérêt prometteur. C’est précisément ce fil conducteur que suit cette série.
Dans le précédent article de cette série, nous avons revisité la vision initiale de la « trinité » à l’aube d’Ethereum, puis examiné à travers le cas de Greenfield de Binance les solutions actuelles et orientations futures du stockage décentralisé. Dans cet article, nous prendrons comme point de départ et objet d’analyse Nostr, premier protocole phénoménal dans le domaine de la communication décentralisée, afin d’explorer quelles conditions doivent être réunies pour construire une communication décentralisée mature, au-delà du modèle extrêmement minimaliste incarnant pleinement l’esprit fondamentaliste du Bitcoin qu’est Nostr.
Nostr : ouvrir la « porte aux mille merveilles » des protocoles sociaux
Un mois après son essor, les poussières soulevées par Damus (Damo), l’application la plus populaire sur le protocole Nostr, sont retombées à leur point de départ. Damus a réussi grâce à sa simplicité radicale, mais s’est aussi effondré à cause d’elle. L’anarchisme inhérent au protocole a successivement attiré les cris d’enthousiasme des idéalistes, un afflux massif d’utilisateurs s’entraînant mutuellement, puis finalement conduit à une situation envahie par la publicité. Après avoir reclassé diverses études sur Nostr et plongé dans les documents destinés aux développeurs, nous concluons que Nostr n’est qu’une gare de départ des communications sociales. En tant que réseau expérimental, il joue davantage le rôle d’un « trompettiste » que d’un outil véritablement applicable. Il a certes fait entrer la communication décentralisée dans le champ de vision du grand public, mais faute de conditions techniques et conceptuelles nécessaires, il n’a pas su aller au bout de sa mission. Globalement, Nostr constitue un prototype de protocole de communication qui ne possède pas de caractère antifragile. Après ce coup de sifflet inaugural de Nostr, nous sommes convaincus que des développeurs chevronnés peuvent désormais forger les protocoles de communication de nouvelle génération. À la fin de cet article, nous tenterons d’explorer de meilleures alternatives aux réseaux de relais.
Aperçu des données de Nostr
Données de l’écosystème Nostr
Source des données : https://nostr.directory/stats
Déploiement des relais
Actuellement, Nostr compte 132 relais publics, 49 relais restreints (Restricted Relays) et 74 relais hors ligne (Offline Relays).
Les relais sont principalement déployés en Amérique du Nord : 92 aux États-Unis, 37 au Canada, suivis par l’Allemagne avec 35 relais.
Le cœur de Nostr : Dumb server, Smart client
Bases techniques
Client : composant logiciel client, supportant diverses fonctions sociales. Complexe et hautement personnalisable.
Relay (relais) : serveur intermédiaire. Communique avec les clients, assure le stockage et l’indexation. Sa simplicité permet l’interopérabilité.
Événement (Event) : objet ou type de données de base utilisé par les relais, facilitant l’envoi et la récupération des messages entre relais et clients. La structure des événements et leurs balises (tags) sont très extensibles, offrant une grande liberté aux développeurs.
-
sig : signature garantissant l’authenticité de l’événement, générée côté client.
-
tags : balises ouvertes et arbitraires. Par exemple, une réponse à un événement est marquée par « the e tag ».
Processus technique : le client envoie un événement au serveur-relais, incluant un pointeur vers un relais spécifique. Le relais stocke et indexe ces événements. D'autres clients peuvent alors communiquer avec les relais qu'ils « connaissent » pour demander les événements déjà reçus et stockés.
Toute la complexité est reportée côté client, tandis que les relais doivent simplement respecter un minimum de normes de consensus, offrant ainsi une grande flexibilité et un seuil d’entrée très bas aux développeurs.
*Les clients actuels ne sont pas des applications directement connectées aux relais, mais des interfaces web, restant donc vulnérables aux blocages.
Relais interchangeables : des portes dimensionnelles infinies
Comme tout serveur traditionnel, un « relais » peut être saturé de spam, recevoir des contenus nuisibles, ou bloquer malicieusement certains utilisateurs ou contenus inoffensifs. La solution de Nostr ne consiste pas à multiplier indéfiniment les relais ni à donner aux utilisateurs le pouvoir de choisir ceux correspondant à leurs critères (comme le fait Mastodon), mais plutôt à minimiser les coûts de déploiement des relais et de changement d’un relais à un autre, assurant ainsi une liberté dynamique à moindre coût.
Une porte dimensionnelle peut toujours mener vers un autre relais. D’une part, la faible barrière à l’entrée garantit que les relais ne seront jamais épuisés ; d’autre part, la facilité de migration permet aux utilisateurs de quitter un relais à tout moment tout en conservant la possibilité de reconstruire leurs relations sociales. Ce mécanisme fonctionne comme suit :
1) L'utilisateur publie depuis son ancien relais une recommandation vers un nouveau relais. Les clients connectés à l’ancien relais détectent automatiquement cette recommandation et ajoutent le nouveau relais à leur liste de relais connus. Ainsi, les autres utilisateurs continuent de recevoir ses messages même après son départ.
2) Si un utilisateur est banni simultanément par de nombreux relais empêchant la diffusion de sa recommandation, il peut informer manuellement ses amis de son nouveau relais par d’autres moyens.
Il est crucial de noter que les relais ne permettent pas le transfert automatique des données entre eux, rendant impossible la transition fluide des relations sociales existantes et des données accumulées lors d’un changement de relais.
Nostr et la topologie de l’espace social
« Simple mais robuste » représente notre meilleure conception d’un protocole de communication sociale, et incarne également l’esthétique protocolaire du fondamentalisme bitcoin tel qu’exprimé par Nostr. La « simplicité » implique de sacrifier tous les détails techniques superflus, juste assez pour atteindre la fonctionnalité. Mais dans ses choix de simplification, Nostr n’a pas trouvé l’équilibre, allant jusqu’à compromettre la fonctionnalité même du système :
« Simple… »
Pourquoi Nostr est-il simple ? Parce que l’espace social, en tant qu’espace, est lui-même simple et entièrement passif. Les opérateurs de relais sont des gardiens, non des « gestionnaires » (contrairement à Mastodon). L’accès et le départ constituent les seules fonctions de cet espace, définissant ainsi les limites des espaces d’intersection.
Au-delà de ces frontières, toutes les autres fonctionnalités sont assurées par les « clients ». Cela rapproche le protocole Nostr de la réalité des interactions sociales : tout comme le stockage illimité n’existe pas, le recherche illimitée et l’accessibilité universelle n’existent pas non plus. Seuls subsistent les « espaces communs ». Le concept de « co-présence » devient ici une notion sur la carte relationnelle, cohérente avec tous les processus naturels de socialisation : intersection → suivi ; rester dans un espace commun approfondit les liens ; en sortir rompt la relation.
L’approche de Nostr concrétise les espaces d’intérêt abstraits. Sur WeChat, Telegram, WhatsApp ou d’autres plateformes, le concept de groupe est fondamentalement abstrait, sans ancrage technique concret. Nostr, lui, lie directement les groupes aux « relais » déployés physiquement, les ancrant à des serveurs-nœuds spécifiques.
« Mais pas robuste. »
Cette approche soulève un problème majeur : celui du stockage. Puisque les relais ne communiquent pas entre eux et n’échangent aucune donnée, « quitter » ou être exclu d’un relais revient exactement à quitter ou être banni d’une plateforme Web2 spécifique : on ne peut emporter les données sociales générées. Quand un utilisateur quitte WeChat, Facebook ou Xiaohongshu, il ne peut pas emporter ses relations sociales, car WeChat ne « communique pas avec Facebook ou Xiaohongshu ». Nostr ressemble davantage à un protocole Web2 qu’à un protocole Web3 : les multiples relais de Nostr effectuent plusieurs sauvegardes des données sociales des utilisateurs (avec possibilité de sauvegarde personnelle), mais ne garantissent pas la sécurité de ces sauvegardes elles-mêmes.
Les « clients » s’appuient donc sur ces sauvegardes isolées et non interconnectées pour implémenter différentes fonctionnalités. Cela revient à construire de nouveaux bâtiments sur un château de sable extrêmement instable. Chaque construction sollicite à nouveau les couches précédentes, mais avec l’augmentation du nombre d’utilisateurs et du temps écoulé, la « perte définitive » passe d’un risque probabiliste à une certitude. Et dans ce cas, aucune institution centralisée ne peut en assumer la responsabilité. Les relais sont anonymes, et nous ne pouvons pas supposer que chaque utilisateur déploiera personnellement un relais pour sauvegarder ses données.
Ce saut entre portes arbitraires, causé par l’absence d’interopérabilité des données, se rapproche davantage du fédéralisme tardif des plateformes Web2 que de l’embryon d’un véritable réseau Web3.
Le « Dumb Relay » est-il vraiment la meilleure solution pour un réseau de relais ?
Sous réserve de décentralisation, le « relais » peut techniquement prendre de nombreuses formes non contraintes. Le « Dumb Relay » n’est qu’une option parmi d’autres. Une autre voie serait d’autoriser les « Dumb Relays » à « parler ». Le « discours » est la condition préalable au consensus : seul un échange de données entre nœuds-relais peut permettre une synchronisation protocolaire des données. Une telle synchronisation n’est pas une redondance inutile, mais un fondement technique nécessaire à la sécurité des données et à la prévention des pannes uniques. Derrière le « consensus », c’est la sécurité globale du réseau qui est en jeu.
Nostr ressemble davantage à une « maquette de protocole » qu’à une solution prête à l’emploi à grande échelle. Un protocole de communication doit toujours anticiper le prochain milliard d’utilisateurs, et à cette échelle, les problèmes de sécurité et de récupération des données, auparavant secondaires, deviennent centraux pour tout développeur de couche protocolaire.
Du point de départ de Nostr à la prochaine étape des protocoles de communication
En somme, nous pouvons identifier plusieurs caractéristiques que Nostr ne possède pas (ou pas complètement), mais que devrait intégrer tout futur réseau idéal de relais :
- Consensus entre nœuds, pour prévenir la perte définitive de données due à une panne unique ;
- Extensibilité : en raison de l’approche « Dumb server, Smart client », bien que le seuil de déploiement des relais soit abaissé, le protocole Nostr ne permet pas de mise à l’échelle ciblée sur un relais particulier ;
- Comptes abstraits (plutôt que des paires clé publique/clé privée irrécupérables) ;
- Couche d’incitation économique, pour soutenir un nombre suffisant de relais face à une base massive d’utilisateurs.
Ces critères ne sont pas impossibles à atteindre simultanément. Compte tenu de l’importance stratégique du protocole de communication décentralisée dans l’écosystème, ainsi que de la valeur utilisateur et du potentiel économique qui y sont associés, les réseaux de relais ou protocoles décentralisés existants évolueront inévitablement dans cette direction. PUSH, XMTP, Dialect, Notifi, Hal, Tenderly, ainsi que Status — qui hérite en partie du legs de Whisper d’Ethereum — sont autant d’exemples dignes d’attention. Dans le prochain article, nous présenterons sous forme d’étude de cas le protocole ayant atteint à ce jour le plus haut niveau de maturité et de rapidité, en tant que référence pour la communication décentralisée.
Remerciements
Merci à ArNostr pour son microblog, à George Zhang Tengji d’Unipass, et à Aaron Sponge de Plancker DAO pour leur aide dans la rédaction de cet article.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
