La semaine dernière, Retric, membre de la communauté CKB, a proposé le protocole de liaison Nostr.

Le protocole de liaison Nostr est utilisé pour créer un mappage un-à-un entre les événements Nostr et les cellules CKB. Les utilisateurs ordinaires peuvent créer et distribuer des actifs natifs sur le réseau social Nostr sur la base de ce protocole. Grâce à RGB++, ces actifs sur Nostr peuvent également être contrôlés par des adresses Bitcoin. Les développeurs clients peuvent y créer des produits. Contrairement à ETH dApp, qui est divisé en deux systèmes (l'un est un serveur hors chaîne et l'autre est un contrat intelligent en chaîne), le protocole de liaison Nostr apporte un nouveau paradigme de développement à dApp. Créez des dApps en utilisant un système cohérent avec différents niveaux de données. Il est rapporté que le protocole de liaison Nostr pourra être intégré de manière transparente au réseau CKB Lightning à l'avenir pour résoudre les problèmes de paiement natifs sur les réseaux sociaux.

Nostr est un protocole minimaliste de transfert d'informations basé sur des clés publiques et privées, dédié à la création d'un réseau social mondial résistant à la censure. Nostr utilise des relais pour stocker des données sociales (telles que des publications) et les transmettre aux utilisateurs, qui exécutent un logiciel appelé Clients.

Le 9 mars de cette année, lors de la première conférence Bitcoin Singapour co-organisée par la Fondation Nervos et ABCDE, Retric a donné un partage thématique sur « la situation et les enjeux actuels du développement écologique Nostr »👇

Voici le contenu compilé sur la base du partage de Retric, qui peut aider tout le monde à mieux comprendre le protocole Nostr :

Ce protocole Nostr devrait être la chose la plus simple de la réunion d'aujourd'hui. Comparé à certaines technologies ou protocoles évoqués par d’autres, c’est le plus simple à comprendre car il est aussi très simple. Ce que Nostr voulait faire au début était en fait un "Twitter", mais ce Twitter n'était pas contrôlé par Elon Musk, mais un Twitter plus décentralisé qui ne ferait pas de mauvaises choses ni ne ferait quoi que ce soit de mal. Allez bloquer les gens et avoir une certaine liberté d'expression. . Il veut faire cette chose à partir d'un point de départ plus réaliste, c'est-à-dire qu'il veut créer un tel logiciel. Pour cela, il a proposé un protocole décentralisé sur les réseaux sociaux appelé Nostr. Alors, maintenant, tout le monde commence à réaliser que ces choses ne servent pas seulement à créer un Twitter, mais plutôt à une meilleure structure Internet, sur laquelle nous pouvons créer diverses applications.

Permettez-moi d'abord de présenter brièvement le protocole Nostr. Il peut en fait être expliqué en une phrase : Il s'agit d'une donnée, signée par une clé privée, qui est propagée sur différents relais ou répéteurs, puis envoyée au client. Essentiellement, je signe des données au format fixe, et après la signature, je les envoie à certains répéteurs, puis je laisse d'autres utilisateurs extraire ces données de ces répéteurs via le client pour les lire.

L'élément central de Nostr est une structure Jason, qui aura différents champs, chaque champ représentant une signification. Par exemple, pubkey est la clé publique que j'ai utilisée pour signer les données que j'ai envoyées. Par exemple, elle a une colonne de contenu, ce qui signifie quel est le contenu des données que j'ai signées. Il peut s'agir de n'importe quelle chaîne. J'ai envoyé, ou il peut s'agir d'un numéro ou d'un élément crypté. Il n'y a aucune restriction dans le protocole. Il y aura également une signature ici, ce qui signifie que j'ai donné une garantie pour les données que j'ai envoyées, garantissant que les données ont bien été envoyées de ma part.

Le cœur de Nostr est donc aussi simple que cela. Cela signifie simplement que j'ai utilisé une certaine clé privée pour signer une certaine donnée que j'ai écrite localement. Une fois ces données envoyées sur Internet, la structure du réseau Nostr est également très simple, avec seulement deux structures, l'une appelée Relay et l'autre appelée Client.

Relay est un serveur que tout le monde peut configurer. La fonction de ce relais est qu'il fonctionne toujours sur Internet pour surveiller qui m'a envoyé les données que je viens de mentionner, puis les reçoit et les enregistre. Si un client me demande certaines données, je les lui donnerai à nouveau. .

La deuxième partie concerne la manière de diffuser ces données, c'est-à-dire un cahier des charges de diffusion, qui contient en fait de nombreux détails. Par exemple, si je transmets ces données à Relay, communiquent-ils entre eux ? Ou après les avoir transmis à Relay, Relay enregistrera-t-il complètement les données pour moi, puis me les donnera-t-il chaque fois que je le demanderai ? En fait, il existe de tels détails. La réponse de Nostr est "Je m'en fiche, vous pouvez y penser vous-même." Quoi qu'il en soit, c'est en fait une réaction un peu étrange, mais parfois je pense que c'est une stratégie plus intelligente. Parfois, il semble que peu importe que ce soit dans le monde réel ou en ligne, parfois cela fait mal à certaines choses en faisant trop attention, donc je pense qu'il est en fait très intéressant de laisser ça tranquille.

Par exemple, permettez-moi de vous donner un exemple simple Lorsque nous utilisons un réseau social centralisé traditionnel, le serveur centralisé enregistrera toutes vos données par défaut. Ensuite, quand vous me demandez quelque chose, je peux vous le donner à tout moment, mais comme Nostr s'en fiche, que va-t-il se passer ici ? Certains opérateurs Relay veulent devenir plus grands et plus forts, et ils veulent sauvegarder tous les messages. Une autre façon est que je suis un amateur, je veux juste construire un très petit nœud et j'accepte uniquement les données des utilisateurs que j'aime. Il y a aussi certaines données que je suis prêt à accepter de votre part, mais je ne les veux peut-être pas 30 minutes après les avoir reçues, je souhaite les supprimer car le disque de mon serveur peut être limité et je ne suis pas disposé à les enregistrer pour cela. long.

Cela évoluera donc vers de nombreux rôles différents, et ces différents rôles peuvent avoir différentes divisions du travail. Par exemple, si quelqu'un veut vraiment la gérer en tant qu'entreprise, je deviendrai alors un nœud de service professionnel et ferai de mon mieux pour fournir à chacun un service plus stable et à plus long terme. Il y a aussi des passionnés qui peuvent également gérer des choses comme LAN, donc cela évoluera vers différentes divisions de travail.

Un phénomène courant est que la plupart des nœuds relais sont disposés à recevoir certains de vos messages, mais ils ne peuvent pas garantir qu'ils seront enregistrés pendant une longue période. Cette structure semble en réalité plus adaptée à certains modèles sociaux de notre société humaine réelle. Un véritable modèle social. Par exemple, si je discute avec tout le monde ici aujourd'hui, vous pouvez m'entendre quand je parle, vous le saurez, puis quitterez la salle. Après deux jours, certaines personnes ont une mauvaise mémoire et ne se souviennent plus de ce dont je parle, mais certaines personnes achètent un magnétophone dans cet endroit et notent chaque mot que vous dites. Cela signifie que votre nouvelle ne restera pas éternellement.

Ceci est en fait très similaire à ce qui se passe dans notre réalité. Cette chose peut arriver parce que Nostr ne réglemente pas beaucoup de détails ou bien d'autres choses, et ne se soucie pas de savoir si Relay a besoin de communiquer avec Relay ou non. Il n'est pas nécessaire de synchroniser le Relay. des messages que chacun a, mais cela ne dit pas que vous ne pouvez pas. Par conséquent, de nombreux relais prétendront être un client et se rendront également vers d’autres relais pour récupérer leurs données et synchroniser toutes les données. Mais il n'impose pas d'exigences obligatoires, disant que vous devez communiquer. L'une des raisons est que si je fais cette exigence et que vous devez communiquer, alors chaque relais doit sauvegarder les données de chaque utilisateur sur l'ensemble du réseau, auquel cas il le fait. sera un très gros test pour le fonctionnement du Relay. Peut-être que seuls ces prestataires de services professionnels peuvent l'exploiter, et que les passionnés individuels ne peuvent pas l'exploiter. Voilà donc quelques-unes des considérations qui ont motivé la conclusion de cet accord simple.

Pour résumer, je pense que le protocole Nostr est très simple. Une autre chose intéressante est qu’à ce stade, nous avons Bitcoin et la blockchain. Ce que nous voulons, c’est un consensus, tout comme nous nous asseyons tous et disons que nous utilisons aujourd’hui une méthode unifiée. Elle apparaît en fait à un nœud très intéressant à utiliser. le format et le protocole unifié pour réaliser certains réseaux sociaux ou réaliser certains produits Internet. Mais maintenant, je pense qu'il y a une direction pour que ce nœud travaille dur, qui consiste à utiliser une structure de données très simple et un protocole d'échange très simple pour faire certaines des choses que font WeChat, Twitter, etc. Je pense donc que vous pourriez penser que c’est très simple et pas intéressant à première vue. Mais si vous réfléchissez à l’époque de son apparition, la signification de son apparition sera plus intéressante.

Un autre point est qu’en raison de sa structure, un grand nombre de vérifications ont lieu du côté client. Il n'y a en fait qu'une seule chose à vérifier ici : si les données que vous publiez sont bien envoyées par la paire de clés publique-privée que vous avez déclarée. Seule cette vérification est effectuée. Pourquoi faisons-nous cette vérification ? Parce que par exemple, si j'envoie un tweet et dis quelque chose que je ne devrais pas dire, cela sera envoyé à Relay. Relay est responsable de l'envoyer à d'autres utilisateurs. Si Relay ne le vérifie pas, Relay peut dire que j'ai forgé un dicton étrange que vous avez dit et que je l'ai envoyé à d'autres utilisateurs. Parce que j'ai une signature lorsque j'envoie les données, le client qui reçoit les données peut faire une vérification et dire que la signature qu'il a signée correspond exactement à ce qu'il a dit, donc Relay ne peut pas tromper les autres.

L'une de ses vérifications consiste donc à vérifier la signature. La vérification de cette signature est en fait la même que celle de notre Internet centralisé dans le passé, comme WeChat. Le serveur sur WeChat est contrôlé par lui-même et peut écrire n'importe quoi sur le site. serveur, vous n'avez aucun moyen d'être sûr qu'il ne vous ment pas, car toutes les données et tous les droits se trouvent sur le serveur. Mais tant qu'il y a la vérification la plus simple, nous pouvons en fait retirer les droits du serveur et les transmettre à l'utilisateur qui possède le compte. Tant que vous disposez d'une clé publique et privée, vous pouvez demander à vos amis de la vérifier pour vous assurer que personne d'autre ne prétend être moi ou ne dit autre chose de mal.

Alors, quel est le développement de Nostr ? Voici quelques données que j’ai trouvées en mars. Comme il s'agit d'un réseau distribué, ses données ne sont pas faciles à compter. Ce sont les données que j'ai obtenues sur le site Web nostr.band. Le nombre total d'utilisateurs Nostr peut être d'environ 370 000, et les utilisateurs actifs quotidiens ne sont que de 12 000. Le nombre total de relais, les relais qui sont apparus et le nombre de personnes qui ont traversé ce nœud peuvent être de plus de 2 000. Mais le nombre de ces nœuds qui sont réellement toujours en ligne est probablement inférieur à 200. C’est probablement le cas, il y a donc encore relativement peu d’utilisateurs.

A titre de comparaison, regardez une comparaison avec le protocole BlueSky. Bluesky aurait dû dire à la fin de l'année dernière qu'ils avaient atteint 2 millions d'utilisateurs. Les données à droite indiquent où quelqu'un a compté les utilisateurs qui ont quitté Twitter et où ils sont allés. Vous pouvez également voir que Mastodon se classe premier, et Mastodon est un. marque relativement ancienne. Après cela, certaines personnes sont allées à OST News, et certaines personnes sont allées à BlueSky. Nostr appartient en fait au cinquième échelon, ce qui représente une partie relativement petite.

Il s'agit d'une situation de développement difficile. Bien sûr, il y a beaucoup de choses derrière Nostr qui ne peuvent pas être vues dans ce type de données. Par exemple, certaines propositions ont été soumises au protocole et les développeurs y ont soumis des PR. Ces activités de développement ou discussions ne sont peut-être pas comptées, mais si vous cliquez sur ces liens, vous pouvez effectivement constater qu'il se passe encore beaucoup de choses et qu'un grand nombre de personnes souhaitent contribuer à ce protocole. Ce sont quelques-unes des choses pour lesquelles tout le monde utilise Nostr. Non seulement je crée vraiment un Twitter, mais il existe également de nombreuses applications liées à la musique, des applications de type YouTube et des applications de type blog.

Alors permettez-moi de résumer : nous pensons désormais que la plupart des utilisateurs sont en réalité des développeurs ou des créateurs. Ils sont intéressés par le protocole lui-même et veulent développer des choses dessus, ou je suis une personne qui veut faire quelque chose, je vais travailler sur votre protocole, et il y aura peut-être moins d'utilisateurs ordinaires.

Pourquoi Nostr est-il si simple ? La vision a l'air bonne, mais le développement n'est pas très satisfaisant. Je pense que c'est aussi parce que j'ai rencontré trois problèmes lorsque j'écrivais ce PPT, j'ai découvert qu'il y avait en fait beaucoup de petits problèmes avec d'innombrables détails, comme Du côté client, il y a certaines choses concernant l'expérience produit. Mais il est en réalité très difficile d’expliquer clairement ce genre de choses, c’est pourquoi je viens de mentionner trois points qui me semblent plus importants.

La première grande question est de savoir comment trouver le contenu publié par un utilisateur sur le réseau Nostr, car comme nous l'avons dit plus tôt, le fonctionnement de l'ensemble du protocole Nostr est que je signe les choses localement et que je les envoie ensuite à d'innombrables relais. D'autres utilisateurs peuvent récupérer les données que j'ai envoyées depuis ces relais et les lire. Ceci est un modèle. Mais il y a un problème avec ce modèle. Une fois mes données envoyées à Relay, lorsque mon ami veut lire ce message, comment sait-il sur quel Relay se trouve mon message ? je suis allé le lire. Alors maintenant, un gros problème d'expérience utilisateur est que lors de l'utilisation de Nostr, de nombreuses personnes demandent à leurs amis : « Hé, quel Relay utilisez-vous ? Je souhaite configurer le même Relay que vous afin que nous puissions échanger ces données ensemble. "C'est une méthode très stupide.

Bien sûr, de nombreux développeurs ont proposé des solutions détaillées. Par exemple, il existe une proposition NIP-65, qui signifie approximativement sur quels relais je mettrai mes données. Ensuite, je diffuse ce message à tous les Relays autant que possible, afin que mon ami aille d'abord sur Relay et pose une question sur l'endroit où mon ami envoie habituellement ses messages. Après avoir obtenu ces informations, il s'est rendu dans les relais que je publie souvent et leur a demandé les données. C'est une méthode.

Il est divisé en deux modes relativement détaillés, l’un s’appelle Inbox et l’autre s’appelle Outbox. Par exemple, comme Inbox, il permet aux utilisateurs de définir sur quels relais je lirai des nouvelles me concernant. Si vous souhaitez me @me sur Twitter ou faire autre chose, vous pouvez envoyer ce message à ce relais de boîte de réception. L'autre est Outbox Relay, qui précise que j'enverrai certains de mes messages à plusieurs relais A, B, C et D. Cela signifie probablement que j'enverrai en premier certains des messages Relay que je publie souvent sur Relay.

Mais un problème technique se pose : comment savoir où se trouve l’actualité ? Ce problème existe donc également, et certaines solutions consistent à utiliser des algorithmes pour télécharger autant d'informations que possible à partir de l'ensemble du réseau. Ensuite, à partir de certaines des preuves cachées de Relay mentionnées dans certains messages envoyés par d'autres, essayez de calculer la probabilité que les données publiées par une personne apparaissent sur quel Relay. Grâce à ce calcul de probabilité, essayez de trouver un relais qui nécessite des données, puis assurez-vous que les autres peuvent trouver vos données lorsqu'ils souhaitent les lire. D'autres permettent également aux utilisateurs de définir certains relais qu'ils utiliseront, de créer des groupes et de permettre à d'autres utilisateurs de vous trouver via ces groupes. Ce sont quelques solutions d'amélioration existantes.

Le deuxième problème est également plus sérieux, appelé Content Governance. Qu’il s’agisse de produits de contenu ou de réseaux sociaux, une grande partie de l’énergie doit être consacrée à la façon dont vous entretenez le contenu sur ce réseau social. Par exemple, vous n’avez absolument pas besoin de voir une vidéo de quelqu’un décapitant quelqu’un en parcourant Twitter, n’est-ce pas ? Des entreprises comme celle-ci effectueront de nombreuses opérations derrière elles, et elles ont besoin de beaucoup de personnes pour filtrer le contenu ou utiliser des algorithmes pour effectuer une correspondance de contenu. Dans cette partie, le marché est relativement vide. Il y a plusieurs raisons à cela. L’une d’elles est que tout le monde est très résistant aux algorithmes sur cette plateforme. Parce qu’il semble que que ce soit TikTok ou Youtube, les algorithmes nous contrôlent, mais en fait nous avons besoin d’algorithmes. Cela signifie simplement que ce dont nous avons besoin, c’est que je puisse changer d’algorithme.

Je ne veux pas dire que je ne peux qu’accepter l’algorithme obligatoire qui m’est donné par Youtube ou TikTok pour diffuser des publicités. J’espère disposer de nombreux algorithmes que je peux changer à tout moment. Si je n’aime pas cet algorithme, j’ai la possibilité d’arrêter. Ce point de vue est lentement accepté par sa conception. C’est juste que dans ce domaine, qu’il s’agisse d’opérations manuelles ou de certaines opérations sur le contenu, ou de certaines choses réalisées en technologie algorithmique, celles-ci font encore relativement défaut. Le principal problème dans cette partie est donc que notre réseau est composé de tout le monde. Il a besoin d’un mécanisme pour décider quel contenu est bon, quel contenu est mauvais, quel contenu vous intéressera et quel contenu pourrait vous intéresser. Pour ceux que cela n’intéresse pas, il s’agit en réalité d’une question de gouvernance du contenu.

Vous trouverez ci-dessous quelques plans d'amélioration existants que j'ai répertoriés, tels que les premières données d'étiquetage. Il existe un type spécial de données sur ce Nostr, qui permet aux utilisateurs de marquer à quel type de certaines données elles appartiennent ou quels sont leurs attributs. Utilisez simplement ce type d'étiquetage pour étiqueter une donnée, mais cela n'est pas largement utilisé car c'est très simple et personne n'est prêt à le faire. Personne n'est disposé à agir en tant que membre social et à vous aider à accomplir une partie de ce travail acharné. Les toutes premières sociétés Internet avaient ce genre d'esprit de construction. Désormais, les gens sont plus susceptibles de l'utiliser en tant que consommateurs. Bien sûr, certaines personnes ont suggéré que je puisse créer des API. Je me spécialise dans l'exécution de certains services. Je collecte les données de certaines entreprises sur l'ensemble du réseau, puis j'effectue un filtrage ou une classification pour obtenir des informations plus susceptibles d'être de bonnes nouvelles à envoyer aux utilisateurs. Cette solution est très simple à mettre en œuvre, mais elle pose un énorme problème, c'est-à-dire qu'on y retourne après avoir fait cela. Cela revient à dire que je ne demande pas de données au protocole Nostr, mais plutôt à dire que je recherche spécifiquement une API qui fonctionne particulièrement bien et que je demande des données au serveur de cette API. Ensuite, ce genre d’accord deviendra un autre Twitter ou un autre WeChat derrière cette API, donc cette solution est très bonne. Le problème c’est que les gens n’aiment pas ça. Si vous faites ça, tout le monde vous critiquera.

Il existe une autre solution appelée DVM. Ce qu'il veut faire, c'est utiliser le protocole Nostr pour effectuer une classification ou un algorithme de ces données en utilisant l'interface spécifiée par le protocole. Sa signification générale est que vous me donnez du Satoshi du Lightning Network, puis je vous renverrai les données que vous souhaitez. Vous spécifiez le format des données, mais cela pose quelques problèmes.

L'autre est Noscript, qui est une autre idée. Nous utilisons directement ces algorithmes de filtrage ou certaines technologies nécessaires à la classification, et utilisons ces codes directement comme contenu, les mettons directement sur Nostr et laissons Relay les stocker. Ensuite, le client extrait directement ces codes et effectue un filtrage local ou fait des recommandations. Bien sûr, l’évolution de cette situation sera encore pire, car maintenant il n’y a que quelques idées et certaines personnes en discutent.

Le troisième problème plus grave est en réalité un problème entrepreneurial, PMF. De nos jours, le grand nombre de produits ou de développeurs de Nostr ne peuvent pas trouver PMF car il doit faire face à une forte concurrence. D'une part, il y a les produits traditionnels centralisés, et d'autre part, il peut s'agir de la blockchain Web3. Ils ne font rien sans émettre de jetons, donc il manque en fait certains modèles commerciaux et est également confronté au problème des effets de réseau, car moins de personnes se déplacent ici, ce qui signifie que moins de personnes continueront à s'y déplacer. Le PMF est donc un gros problème.

Le plus gros client de Nostr s’appelle Damus. Je ne sais pas si vous l’avez utilisé. Son développeur a envoyé un tweet à la fin de l’année dernière, disant que 2024 pourrait être la dernière année de Damus. Parce qu’il n’a presque plus d’argent pour continuer à le faire. S’il n’y parvient pas d’ici 2024, il ne pourra pas gagner d’argent. Il s’agit donc aussi de trouver une orientation de développement durable pour les biens publics des réseaux sociaux.

En fait, je pense que tous les problèmes ici sont aussi des opportunités. Par exemple, comme le dernier PMF, je pense que si nous pouvons avoir plus de lieux d'intégration avec la blockchain, avoir des modèles commerciaux plus réalisables et procéder à une certaine intégration avec les fonds blockchain, nous pourrons peut-être résoudre ce problème de financement des biens publics. .

Enfin, je pense que Nostr est une nouvelle solution pour développer des applications alternatives. Si vous souhaitez créer des produits alternatifs, il n’y a peut-être pas seulement deux extrêmes, l’un s’appelle blockchain et l’autre s’appelle Twitter. Ce n’est pas le seul, il existe peut-être un juste milieu appelé Nostr, qui n’est pas basé sur la blockchain, mais ce n’est pas non plus un logiciel propriétaire. Merci.