La nouvelle année des médias sociaux : principes Nostr et questions clés de gestion
De nouvelles conceptions de médias sociaux sous la Cinquième Droite sont explorées depuis des années, sans aucun signe d’adoption massive. Au cours de l'année écoulée, avec le développement continu de la technologie de cryptage et les inquiétudes concernant l'acquisition de Twitter par Musk, le réseau social décentralisé a ouvert la voie à de nouvelles opportunités.
Les problèmes que ces réseaux sociaux tentent de résoudre pourraient inclure le renforcement de la censure, la modération des contenus plus flexible et la réduction du pouvoir des grandes sociétés de médias sociaux de façonner et de suivre ce dont les gens parlent en ligne, entre autres.
À mesure que de nouvelles plateformes émergent et se développent, le choix de réseaux sociaux alternatifs s’accompagne souvent de considérations politiques. Des sites comme Getr, Parler, Gab et Truth Social s'adressent tous à la droite en se présentant comme des alternatives à la liberté d'expression à Twitter.
Ce dont nous allons discuter aujourd'hui est Nostr-Damus, un nouveau protocole de médias sociaux qui a récemment reçu beaucoup d'attention et qui est quelque peu innovant. Ceux-ci incluent les principes techniques de Nostr, les principaux problèmes de gestion à résoudre et la manière d'inciter le relais à continuer de fonctionner.
Présentation de Nostr
Lancé en 2020, Notre est un protocole décentralisé qui permet aux utilisateurs de posséder leur identité et de vérifier les publications à l'aide de signatures numériques utilisant un cryptage à clé publique-privée. Ces publications sont ensuite propagées vers un réseau de serveurs interconnectés. Le protocole n’utilise pas de blockchain, qui s’est avérée lors des premières expériences trop lente pour les réseaux sociaux. Mais il existe des similitudes structurelles, et Nostr a trouvé très tôt une niche dans le monde des crypto-monnaies grâce à sa philosophie libertaire et open source.
Mastodonte contre Nostr
Le protocole Nostr et le premier serveur relais ont été créés par le développeur fiatjaf fin 2020. Avant de susciter une large attention, Nostr était un protocole de niche discret visant à être une solution légère aux problèmes de Twitter et Mastodon.
Mastodon, un réseau open source fondé en 2016, permet à quiconque de mettre en place un serveur. Le design est souvent décrit comme « fédéré » et peut ou non s'inscrire dans la ligne floue du « Web3 », selon la façon dont cela est défini. Mastodon permet aux utilisateurs de rejoindre des communautés organisées avec des règles de modération de contenu personnalisées. À l'heure actuelle, le nombre d'utilisateurs enregistrés a atteint plus de 200 w et est devenu un refuge pour les libéraux, les journalistes et les universitaires.
In Twitter ainsi que le Mastodonte systèmes, les identités/noms d’utilisateur sont contrôlés par celui qui gère le serveur.
La principale différence dans Nostr est que chaque utilisateur utilise une paire de clés publique/privée pour gérer la fonction plutôt que d'utiliser un nom d'utilisateur appartenant à l'opérateur du serveur, ce qui rend Nostr résistant à la censure. Il s’agit de l’un des éléments de base de la construction de l’ensemble du protocole Nostr.
événement: Il s'agit du type d'objet/données de base utilisé par les clients et les serveurs relais auxquels ils se connectent afin d'envoyer et de récupérer des messages. L'idée générale du protocole est que les clients envoient des événements à un serveur relais, qui les stocke et les indexe ensuite, et que d'autres clients peuvent communiquer avec le serveur relais pour demander les événements qu'ils ont reçus et stockés. Dans la version originale PIN 01, trois types d'événements différents ont été définis :
- Envoyez des métadonnées sur l'utilisateur, telles que le nom d'utilisateur, la photo, la biographie, etc.
- Envoyer des SMS et du contenu de base
- Recommander le serveur relais aux personnes qui suivent le créateur de l'événement pour se connecter
Tous les événements sont structurés d'une manière spécifiquement définie. Inclut la clé publique du créateur, l'horodatage de la création, le type (ou type dans les spécifications), la charge utile du contenu et la signature du créateur de l'événement. Alternativement, il peut y avoir des balises faisant référence à d'autres événements ou utilisateurs et ayant une valeur d'identification qui est un hachage de tout sauf la signature du créateur (similaire au TXID d'une transaction Bitcoin).
Cela permet aux utilisateurs de vérifier la signature (et qui possède la clé, si elle n'a pas été compromise) pour garantir que le message a bien été créé par le propriétaire de la clé publique qu'il contient et que le message n'a pas été modifié depuis la signature. il.
Tout comme une transaction Bitcoin ne peut pas être modifiée après sa signature sans l'invalider, un utilisateur ne peut pas la modifier après que le créateur de la transaction ait été créé. Notre l'événement l'a signé sans en faire une fraude évidente.
Le système de type événement a été considérablement étendu par rapport à l'original PIN. Il existe un type d'événement pour les messages chiffrés directs qui créent un secret partagé en combinant la clé privée de l'expéditeur avec la clé publique du destinataire, dont le résultat est le même que celui que vous obtenez en combinant la clé publique de l'expéditeur avec la clé privée du destinataire. sont identiques (c'est ainsi que fonctionnent le BIP 47 et les paiements tacites).
Il existe également des types d’événements remplaçables et éphémères. Dans le cas d'événements remplaçables (évidemment), ils sont conçus pour que le créateur original de l'événement puisse signer un nouvel événement pour remplacer l'ancien. Les serveurs relais suivant cette spécification supprimeront automatiquement les anciens événements de leur stockage et commenceront à proposer des versions plus récentes aux clients dès réception.
Les événements éphémères sont conçus de telle manière que lorsqu'ils sont envoyés à un relais, ils seront diffusés à toute personne abonnée à leur créateur, mais le serveur relais ne doit pas les stocker. Cela crée la possibilité que seuls ceux qui sont en ligne verront le message lors de sa diffusion. Il existe même un type d'événement pour représenter les réactions aux événements d'autres personnes (comme les likes ou les emojis).
En parlant de la dernière question, les événements peuvent également contenir des balises. Actuellement, il existe des types de balises pour le événement (faisant référence à un événement Nostr exact), Clé publique (pour taguer ou faire référence à un autre utilisateur), et Sujet (pour imiter une fonctionnalité, comme un sujet d'e-mail).
Tous ces éléments peuvent inclure des pointeurs vers des serveurs relais spécifiques à partir desquels les données sont récupérées afin que les utilisateurs puissent réellement interagir sur différents serveurs, c'est-à-dire qu'un utilisateur publie son contenu sur un serveur relais avec lequel il peut interagir et être référencé par un autre utilisateur sur un autre serveur. serveur relais afin que tout utilisateur puisse obtenir de manière cohérente l'ensemble du fil d'interaction dans le bon ordre sans avoir à savoir où se trouvent les données pertinentes dans un grand nombre d'opérations complexes.
Dans la version originale PIN, une spécification a été donnée sur la façon dont un client interagit avec un serveur relais en s'abonnant à une structure de message/données qui inclut des filtres pour quels événements le client souhaite recevoir. Ces filtres peuvent spécifier la clé publique de l'utilisateur, l'événement exact, le type d'événement ou même une période spécifique qu'il souhaite appliquer en fonction de critères précédents.
Les utilisateurs peuvent même soumettre des clés publiques ou des préfixes d'ID d'événement, tels que « 1xjisj… » et recevoir un ou plusieurs événements à partir d'une clé publique commençant par cette courte chaîne (cela est utile pour masquer aux serveurs relais ce que vous voulez réellement voir) .
Dans l'ensemble, le protocole est un schéma général très simple pour transmettre des messages entre utilisateurs, couvrant des éléments importants tels que la garantie de l'intégrité des messages et l'utilisation d'identités de clé publique pour l'envoi de messages, tout en facilitant également la centralisation des serveurs de relais d'infrastructure finale ou la possibilité pour les utilisateurs d'exécuter des messages. leurs propres serveurs de relais personnels tout en interagissant de manière transparente les uns avec les autres et sans provoquer de chaos massif au cas où les utilisateurs seraient interdits d'utiliser un serveur de relais.
Ils peuvent migrer vers un autre serveur ou gérer le leur, et ils ne perdront pas leur identité numérique ou leurs abonnés en séparant la plate-forme de leur serveur précédent, car ils gardent toujours le contrôle de leurs clés privées et les utilisateurs peuvent les utiliser ailleurs pour s'authentifier. eux quand ils les trouvent.
Les serveurs relais peuvent également exécuter ce qu'ils veulent : fonctionner gratuitement, facturer une somme modique pour publier ou télécharger des messages, et même avoir un NIP qui nécessite une preuve de travail de type hash cash pour soumettre des messages.
Il peut s'agir d'un serveur relais unique qui héberge les publications et les rend disponibles uniquement aux autres utilisateurs ou d'un serveur fonctionnant à grande échelle, comme Twitter ou Reddit (les clients peuvent afficher et organiser les informations à leur guise, ce qui permet de simuler n'importe quel média social). Tous ces éléments interagissent de manière transparente sans exclure les utilisateurs.
Questions de gestion clés à résoudre par Nostr
Les clés publiques/privées des utilisateurs font partie intégrante du fonctionnement de Nostr en tant que protocole. Cela agit comme un lien étroit entre l'utilisateur réel et la façon dont les autres l'identifient, empêchant tout serveur relais de délier ces deux choses, c'est-à-dire de donner l'identifiant de quelqu'un à un autre utilisateur. Cela résout également l'un des plus gros problèmes de la plateforme : le manque de contrôle sur la propre identité de l'utilisateur.
Mais cela introduit également de nouveaux problèmes : la clé peut être perdue, la clé peut être compromise, et si un tel événement se produit, l'utilisateur ne pourra pas appeler à l'aide.
Cela nécessitera inévitablement un système permettant aux utilisateurs de passer d'une paire de clés à une autre de manière vérifiable et détectable et d'interagir avec d'autres utilisateurs via le protocole. L'ensemble du protocole est basé sur la preuve qu'un événement provient d'un utilisateur spécifique (clé d'identité), donc une fois que la clé de quelqu'un est compromise, toutes ces garanties sont jetées en l'air.
Nostr nécessite un véritable schéma cryptographique qui lie la rotation d'une clé à une autre. Le développeur fiatjaf a proposé une solution de base qui pourrait résoudre ce problème. L’idée de base est de prendre une longue liste d’adresses dérivées d’une seule graine principale et de créer un ensemble de clés « ajustées », similaire à la façon dont les arbres Taproot sont engagés dans les clés Bitcoin.
Taproot prend la racine Merkle de l'arborescence Taproot et « l'ajoute » à la clé publique pour créer une nouvelle clé publique. Cela peut être répliqué en ajoutant cette racine Merkle à la clé privée pour obtenir une clé privée qui correspond à la nouvelle clé publique. L'idée de Fiatjaf est d'enchaîner les engagements de la fin au début afin que chaque clé ajustée contienne réellement la preuve que la clé ajustée suivante a été utilisée pour la créer.
Alors imaginez commencer par la clé Z, la dernière de la chaîne. Vous pouvez le modifier avec quelque chose, puis revenir en arrière et créer une version ajustée de la clé Y en utilisant la clé ajustée Z (Z' + Y = Y'). À partir de là, vous pouvez prendre Y' et l'utiliser pour ajuster X (Y' + X = X'). Vous feriez cela jusqu'à la clé A, obtiendriez A' et utiliseriez cette clé à partir de là. Lorsqu'il est cassé, l'utilisateur peut diffuser un événement contenant la clé A non ajustée et la clé B' ajustée.
Celui-ci contiendra toutes les données nécessaires pour montrer que B' a été utilisé pour générer A', et l'utilisateur pourra immédiatement arrêter de suivre A' et suivre B' à la place. Ils sauraient sans ambiguïté que B' est la prochaine clé pour cet utilisateur et suivraient cette clé à la place.
Cependant, cette proposition pose encore quelques problèmes. Premièrement, toutes les clés qui seront utilisées doivent être générées à l’avance, et il n’existe aucun moyen de passer à un tout nouveau jeu de clés. Ce problème peut être résolu en validant une clé principale dans ce schéma qui peut légaliser cette rotation ou en générant simplement un très grand jeu de clés dès le départ.
L’une ou l’autre voie est réalisable, mais nécessite en fin de compte de conserver la clé racine ou le matériel de chiffrement sécurisé et d’exposer uniquement les raccourcis clavier individuels (Hotkeys) aux clients Nostr.
Cependant, ce système ne protège pas les utilisateurs ni ne fournit de mécanismes de récupération d'identité en cas de perte ou de compromission du matériel de clé racine.
Pour discuter des solutions potentielles ici, une autre façon d'y penser est d'ajuster une clé à une clé froide principale qui doit également être utilisée pour signer les événements d'une clé à une autre rotation. Vous avez la clé A', qui est dérivée en ajoutant A et M (clé principale) ; l'événement de rotation sera A, M et B' (généré en ajoutant B et M) et la signature de M. M peut être une clé de seuil multi-signature – deux tiers, trois cinquièmes, etc.
Cela peut ajouter de la redondance contre la perte et fournir un mécanisme sécurisé pour la rotation des clés. Cela ouvre également la porte à l’utilisation de services pour aider à la récupération ou pour transmettre certaines de ces clés à des amis de confiance. Il offre la même flexibilité que le multisig dans Bitcoin lui-même.
PIN26 est également une proposition qui pourrait être très utile pour résoudre ce problème. Ceci spécifie une extension de protocole pour les événements qui permet à une signature d'une clé d'autoriser une autre clé à publier des événements en son nom. Le « jeton » ou preuve de signature déléguée sera alors inclus dans tous les événements publiés par la deuxième clé publique au nom de la première. Elle peut même être limitée dans le temps, de sorte que les jetons de délégation expirent automatiquement et doivent être renouvelés.
La question de la gestion des clés et de la sécurité est un problème très vaste avec un très grand espace de conception plein de compromis et de problèmes. Cependant, si Nostr ne peut pas protéger et maintenir l’intégrité de ces identités pour les utilisateurs, un protocole entièrement basé sur des paires de clés publique/privée utilisées comme identités ne sera pas adopté à grande échelle.
Agrandissement face à Nostr
L'ensemble du protocole Nostr repose sur quelqu'un quelque part qui exécute un serveur relais. Il n'y a pas de « réseau Nostr », juste des relais et des clients connectés aux relais. Les gens doivent être incités à gérer des relais, et cela déterminera en fin de compte dans quelle mesure les relais pourront évoluer à long terme. À moins qu’un relais Nostr puisse être rentable ou au moins rapporter suffisamment d’argent pour couvrir ses propres frais de fonctionnement, il n’y aura jamais de relais de la même taille que le serveur Twitter.
La publicité
Compte tenu de la manière dont Nostr fonctionne en tant que protocole, bloquer entièrement les publicités serait trivial, ce qui en ferait une solution irréalisable. Les serveurs relais peuvent essayer d'utiliser la publicité comme modèle de revenus, ce qui est apparemment le principal modèle de revenus pour presque tous les services gratuits en ligne, mais le problème est que les utilisateurs doivent fondamentalement s'y inscrire. Les relais peuvent facilement injecter des publicités dans les événements qu'ils envoient aux clients. , mais les clients peuvent également filtrer facilement les événements publicitaires à partir de leur interface utilisateur s'ils n'ont pas été créés par la clé publique à laquelle ils avaient l'intention de s'abonner.
Micropaiement
Les micropaiements constituent une autre solution évidente, surtout compte tenu des tentatives en cours pour intégrer le Foudre Réseau plus étroitement dans l’application Nostr. Ce modèle offre une grande flexibilité dans la façon dont vous facturez. Les relais peuvent facturer uniquement la publication d'événements sur place, le téléchargement de lectures d'événements, ou une combinaison des deux, en ajustant le prix de chacun en fonction de la quantité de ressources consommées. Cependant, il est peu probable que ce modèle puisse être étendu à l’échelle de Twitter.
Les micropaiements de contenu ont montré leur viabilité dans de nombreux produits de niche basés sur le Foudre Réseau, mais une véritable échelle mondiale pose deux problèmes fondamentaux.
Premièrement, l’adoption du Bitcoin n’est pas encore suffisante. Même si tout le monde acceptait comme par magie de payer pour chaque petite interaction de service sur Nostr, il n'y aurait pas assez de personnes détenant des bitcoins pour soutenir quelque chose d'aussi massif que Twitter. Les relais peuvent facturer des frais d'abonnement en monnaie fiduciaire, mais ces méthodes de paiement ne permettent pas de payer une somme modique pour chaque événement publié ou téléchargé.
Deuxièmement, les gens sont habitués à ce type de service gratuit. C'est exactement ce à quoi on pourrait s'attendre. Je ne pense pas que les micropaiements puissent vraiment permettre un relais à grande échelle.
Il existe un moyen de rendre les micropaiements plus « collants » ou plus durables sans les imposer à toutes les catégories d’utilisateurs qui utilisent le relais. On a beaucoup parlé de la création de diverses applications sur Nostr, à l'exception du clone Twitter. GitHub, Wikipédia et même Uber.
Le dernier point est essentiel : les attentes économiques. Les gens sont très habitués à payer des frais lorsqu'un emploi est annoncé quelque part ou à payer des frais à un opérateur de marché lorsqu'ils commandent quelque chose en ligne mais ne proposent pas des choses qu'ils pensent devoir être gratuites – Google, Twitter. Cela pourrait permettre aux relais de créer un solide pilier de revenus pour leurs utilisateurs sans créer beaucoup de frictions ni briser les attentes de l'utilisateur potentiel moyen.
Si les micropaiements doivent également être un facteur, les opérateurs de relais devront d'abord exécuter un nœud Lightning afin de recevoir les fonds des utilisateurs. Cela pourrait potentiellement augmenter les revenus s'il était correctement mis en synergie avec tout modèle de micropaiement mis en œuvre par le relais.
Plus un serveur relais génère des revenus, plus il a besoin de liquidités sur le réseau Lightning pour faciliter cela. Si les opérateurs planifient correctement la manière dont ils déploient ou distribuent les liquidités sur le réseau, le simple fait de gérer un nœud de routage pourrait devenir en soi une source de revenus importante, en plus des frais facturés pour la réception ou la transmission de données via des relais.
Conclusion
Projets sociaux Web3, en plus de ceux mentionnés ci-dessus Notre ainsi que le Mastodonte, incluent également des projets tels que Farceur ainsi que le Lens, qui ne remplacera pas rapidement les plateformes de médias sociaux existantes. Selon les statistiques, Twitter compte des centaines de millions d'utilisateurs actifs, Facebook a des milliards, mais Mastodonte a seulement 2.5 millions d'utilisateurset une Notre n'a qu'environ 220,000 XNUMX identités d'utilisateurs uniques. De nombreux projets sociaux Web3 sont confrontés à des obstacles en matière d'utilisabilité qui ralentissent leur adoption massive.
Les médias et la politique sont indissociables. À mesure que les projets sociaux Web3 prolifèrent et que la conversation publique se fragmente entre différentes applications et protocoles, des conséquences politiques peuvent survenir. Même Messina, qui plaide depuis longtemps en faveur de médias sociaux décentralisés, craint que la décentralisation n’alimente davantage un discours public marqué par l’hostilité mutuelle et l’incompréhension ces dernières années.
Avertissement: Les informations sur ce site Web sont fournies à titre de commentaire général du marché et ne constituent pas un conseil en investissement. Nous vous encourageons à faire vos propres recherches avant d'investir.
Rejoignez-nous pour suivre l'actualité : https://linktr.ee/coincu
Harold
Coincu Actualité
Auteur
Connaissance
La nouvelle année des médias sociaux : principes Nostr et questions clés de gestion
De nouvelles conceptions de médias sociaux sous la Cinquième Droite sont explorées depuis des années, sans aucun signe d’adoption massive. Au cours de l'année écoulée, avec le développement continu de la technologie de cryptage et les inquiétudes concernant l'acquisition de Twitter par Musk, le réseau social décentralisé a ouvert la voie à de nouvelles opportunités.
Les problèmes que ces réseaux sociaux tentent de résoudre pourraient inclure le renforcement de la censure, la modération des contenus plus flexible et la réduction du pouvoir des grandes sociétés de médias sociaux de façonner et de suivre ce dont les gens parlent en ligne, entre autres.
À mesure que de nouvelles plateformes émergent et se développent, le choix de réseaux sociaux alternatifs s’accompagne souvent de considérations politiques. Des sites comme Getr, Parler, Gab et Truth Social s'adressent tous à la droite en se présentant comme des alternatives à la liberté d'expression à Twitter.
Ce dont nous allons discuter aujourd'hui est Nostr-Damus, un nouveau protocole de médias sociaux qui a récemment reçu beaucoup d'attention et qui est quelque peu innovant. Ceux-ci incluent les principes techniques de Nostr, les principaux problèmes de gestion à résoudre et la manière d'inciter le relais à continuer de fonctionner.
Présentation de Nostr
Lancé en 2020, Notre est un protocole décentralisé qui permet aux utilisateurs de posséder leur identité et de vérifier les publications à l'aide de signatures numériques utilisant un cryptage à clé publique-privée. Ces publications sont ensuite propagées vers un réseau de serveurs interconnectés. Le protocole n’utilise pas de blockchain, qui s’est avérée lors des premières expériences trop lente pour les réseaux sociaux. Mais il existe des similitudes structurelles, et Nostr a trouvé très tôt une niche dans le monde des crypto-monnaies grâce à sa philosophie libertaire et open source.
Mastodonte contre Nostr
Le protocole Nostr et le premier serveur relais ont été créés par le développeur fiatjaf fin 2020. Avant de susciter une large attention, Nostr était un protocole de niche discret visant à être une solution légère aux problèmes de Twitter et Mastodon.
Mastodon, un réseau open source fondé en 2016, permet à quiconque de mettre en place un serveur. Le design est souvent décrit comme « fédéré » et peut ou non s'inscrire dans la ligne floue du « Web3 », selon la façon dont cela est défini. Mastodon permet aux utilisateurs de rejoindre des communautés organisées avec des règles de modération de contenu personnalisées. À l'heure actuelle, le nombre d'utilisateurs enregistrés a atteint plus de 200 w et est devenu un refuge pour les libéraux, les journalistes et les universitaires.
In Twitter ainsi que le Mastodonte systèmes, les identités/noms d’utilisateur sont contrôlés par celui qui gère le serveur.
La principale différence dans Nostr est que chaque utilisateur utilise une paire de clés publique/privée pour gérer la fonction plutôt que d'utiliser un nom d'utilisateur appartenant à l'opérateur du serveur, ce qui rend Nostr résistant à la censure. Il s’agit de l’un des éléments de base de la construction de l’ensemble du protocole Nostr.
événement: Il s'agit du type d'objet/données de base utilisé par les clients et les serveurs relais auxquels ils se connectent afin d'envoyer et de récupérer des messages. L'idée générale du protocole est que les clients envoient des événements à un serveur relais, qui les stocke et les indexe ensuite, et que d'autres clients peuvent communiquer avec le serveur relais pour demander les événements qu'ils ont reçus et stockés. Dans la version originale PIN 01, trois types d'événements différents ont été définis :
- Envoyez des métadonnées sur l'utilisateur, telles que le nom d'utilisateur, la photo, la biographie, etc.
- Envoyer des SMS et du contenu de base
- Recommander le serveur relais aux personnes qui suivent le créateur de l'événement pour se connecter
Tous les événements sont structurés d'une manière spécifiquement définie. Inclut la clé publique du créateur, l'horodatage de la création, le type (ou type dans les spécifications), la charge utile du contenu et la signature du créateur de l'événement. Alternativement, il peut y avoir des balises faisant référence à d'autres événements ou utilisateurs et ayant une valeur d'identification qui est un hachage de tout sauf la signature du créateur (similaire au TXID d'une transaction Bitcoin).
Cela permet aux utilisateurs de vérifier la signature (et qui possède la clé, si elle n'a pas été compromise) pour garantir que le message a bien été créé par le propriétaire de la clé publique qu'il contient et que le message n'a pas été modifié depuis la signature. il.
Tout comme une transaction Bitcoin ne peut pas être modifiée après sa signature sans l'invalider, un utilisateur ne peut pas la modifier après que le créateur de la transaction ait été créé. Notre l'événement l'a signé sans en faire une fraude évidente.
Le système de type événement a été considérablement étendu par rapport à l'original PIN. Il existe un type d'événement pour les messages chiffrés directs qui créent un secret partagé en combinant la clé privée de l'expéditeur avec la clé publique du destinataire, dont le résultat est le même que celui que vous obtenez en combinant la clé publique de l'expéditeur avec la clé privée du destinataire. sont identiques (c'est ainsi que fonctionnent le BIP 47 et les paiements tacites).
Il existe également des types d’événements remplaçables et éphémères. Dans le cas d'événements remplaçables (évidemment), ils sont conçus pour que le créateur original de l'événement puisse signer un nouvel événement pour remplacer l'ancien. Les serveurs relais suivant cette spécification supprimeront automatiquement les anciens événements de leur stockage et commenceront à proposer des versions plus récentes aux clients dès réception.
Les événements éphémères sont conçus de telle manière que lorsqu'ils sont envoyés à un relais, ils seront diffusés à toute personne abonnée à leur créateur, mais le serveur relais ne doit pas les stocker. Cela crée la possibilité que seuls ceux qui sont en ligne verront le message lors de sa diffusion. Il existe même un type d'événement pour représenter les réactions aux événements d'autres personnes (comme les likes ou les emojis).
En parlant de la dernière question, les événements peuvent également contenir des balises. Actuellement, il existe des types de balises pour le événement (faisant référence à un événement Nostr exact), Clé publique (pour taguer ou faire référence à un autre utilisateur), et Sujet (pour imiter une fonctionnalité, comme un sujet d'e-mail).
Tous ces éléments peuvent inclure des pointeurs vers des serveurs relais spécifiques à partir desquels les données sont récupérées afin que les utilisateurs puissent réellement interagir sur différents serveurs, c'est-à-dire qu'un utilisateur publie son contenu sur un serveur relais avec lequel il peut interagir et être référencé par un autre utilisateur sur un autre serveur. serveur relais afin que tout utilisateur puisse obtenir de manière cohérente l'ensemble du fil d'interaction dans le bon ordre sans avoir à savoir où se trouvent les données pertinentes dans un grand nombre d'opérations complexes.
Dans la version originale PIN, une spécification a été donnée sur la façon dont un client interagit avec un serveur relais en s'abonnant à une structure de message/données qui inclut des filtres pour quels événements le client souhaite recevoir. Ces filtres peuvent spécifier la clé publique de l'utilisateur, l'événement exact, le type d'événement ou même une période spécifique qu'il souhaite appliquer en fonction de critères précédents.
Les utilisateurs peuvent même soumettre des clés publiques ou des préfixes d'ID d'événement, tels que « 1xjisj… » et recevoir un ou plusieurs événements à partir d'une clé publique commençant par cette courte chaîne (cela est utile pour masquer aux serveurs relais ce que vous voulez réellement voir) .
Dans l'ensemble, le protocole est un schéma général très simple pour transmettre des messages entre utilisateurs, couvrant des éléments importants tels que la garantie de l'intégrité des messages et l'utilisation d'identités de clé publique pour l'envoi de messages, tout en facilitant également la centralisation des serveurs de relais d'infrastructure finale ou la possibilité pour les utilisateurs d'exécuter des messages. leurs propres serveurs de relais personnels tout en interagissant de manière transparente les uns avec les autres et sans provoquer de chaos massif au cas où les utilisateurs seraient interdits d'utiliser un serveur de relais.
Ils peuvent migrer vers un autre serveur ou gérer le leur, et ils ne perdront pas leur identité numérique ou leurs abonnés en séparant la plate-forme de leur serveur précédent, car ils gardent toujours le contrôle de leurs clés privées et les utilisateurs peuvent les utiliser ailleurs pour s'authentifier. eux quand ils les trouvent.
Les serveurs relais peuvent également exécuter ce qu'ils veulent : fonctionner gratuitement, facturer une somme modique pour publier ou télécharger des messages, et même avoir un NIP qui nécessite une preuve de travail de type hash cash pour soumettre des messages.
Il peut s'agir d'un serveur relais unique qui héberge les publications et les rend disponibles uniquement aux autres utilisateurs ou d'un serveur fonctionnant à grande échelle, comme Twitter ou Reddit (les clients peuvent afficher et organiser les informations à leur guise, ce qui permet de simuler n'importe quel média social). Tous ces éléments interagissent de manière transparente sans exclure les utilisateurs.
Questions de gestion clés à résoudre par Nostr
Les clés publiques/privées des utilisateurs font partie intégrante du fonctionnement de Nostr en tant que protocole. Cela agit comme un lien étroit entre l'utilisateur réel et la façon dont les autres l'identifient, empêchant tout serveur relais de délier ces deux choses, c'est-à-dire de donner l'identifiant de quelqu'un à un autre utilisateur. Cela résout également l'un des plus gros problèmes de la plateforme : le manque de contrôle sur la propre identité de l'utilisateur.
Mais cela introduit également de nouveaux problèmes : la clé peut être perdue, la clé peut être compromise, et si un tel événement se produit, l'utilisateur ne pourra pas appeler à l'aide.
Cela nécessitera inévitablement un système permettant aux utilisateurs de passer d'une paire de clés à une autre de manière vérifiable et détectable et d'interagir avec d'autres utilisateurs via le protocole. L'ensemble du protocole est basé sur la preuve qu'un événement provient d'un utilisateur spécifique (clé d'identité), donc une fois que la clé de quelqu'un est compromise, toutes ces garanties sont jetées en l'air.
Nostr nécessite un véritable schéma cryptographique qui lie la rotation d'une clé à une autre. Le développeur fiatjaf a proposé une solution de base qui pourrait résoudre ce problème. L’idée de base est de prendre une longue liste d’adresses dérivées d’une seule graine principale et de créer un ensemble de clés « ajustées », similaire à la façon dont les arbres Taproot sont engagés dans les clés Bitcoin.
Taproot prend la racine Merkle de l'arborescence Taproot et « l'ajoute » à la clé publique pour créer une nouvelle clé publique. Cela peut être répliqué en ajoutant cette racine Merkle à la clé privée pour obtenir une clé privée qui correspond à la nouvelle clé publique. L'idée de Fiatjaf est d'enchaîner les engagements de la fin au début afin que chaque clé ajustée contienne réellement la preuve que la clé ajustée suivante a été utilisée pour la créer.
Alors imaginez commencer par la clé Z, la dernière de la chaîne. Vous pouvez le modifier avec quelque chose, puis revenir en arrière et créer une version ajustée de la clé Y en utilisant la clé ajustée Z (Z' + Y = Y'). À partir de là, vous pouvez prendre Y' et l'utiliser pour ajuster X (Y' + X = X'). Vous feriez cela jusqu'à la clé A, obtiendriez A' et utiliseriez cette clé à partir de là. Lorsqu'il est cassé, l'utilisateur peut diffuser un événement contenant la clé A non ajustée et la clé B' ajustée.
Celui-ci contiendra toutes les données nécessaires pour montrer que B' a été utilisé pour générer A', et l'utilisateur pourra immédiatement arrêter de suivre A' et suivre B' à la place. Ils sauraient sans ambiguïté que B' est la prochaine clé pour cet utilisateur et suivraient cette clé à la place.
Cependant, cette proposition pose encore quelques problèmes. Premièrement, toutes les clés qui seront utilisées doivent être générées à l’avance, et il n’existe aucun moyen de passer à un tout nouveau jeu de clés. Ce problème peut être résolu en validant une clé principale dans ce schéma qui peut légaliser cette rotation ou en générant simplement un très grand jeu de clés dès le départ.
L’une ou l’autre voie est réalisable, mais nécessite en fin de compte de conserver la clé racine ou le matériel de chiffrement sécurisé et d’exposer uniquement les raccourcis clavier individuels (Hotkeys) aux clients Nostr.
Cependant, ce système ne protège pas les utilisateurs ni ne fournit de mécanismes de récupération d'identité en cas de perte ou de compromission du matériel de clé racine.
Pour discuter des solutions potentielles ici, une autre façon d'y penser est d'ajuster une clé à une clé froide principale qui doit également être utilisée pour signer les événements d'une clé à une autre rotation. Vous avez la clé A', qui est dérivée en ajoutant A et M (clé principale) ; l'événement de rotation sera A, M et B' (généré en ajoutant B et M) et la signature de M. M peut être une clé de seuil multi-signature – deux tiers, trois cinquièmes, etc.
Cela peut ajouter de la redondance contre la perte et fournir un mécanisme sécurisé pour la rotation des clés. Cela ouvre également la porte à l’utilisation de services pour aider à la récupération ou pour transmettre certaines de ces clés à des amis de confiance. Il offre la même flexibilité que le multisig dans Bitcoin lui-même.
PIN26 est également une proposition qui pourrait être très utile pour résoudre ce problème. Ceci spécifie une extension de protocole pour les événements qui permet à une signature d'une clé d'autoriser une autre clé à publier des événements en son nom. Le « jeton » ou preuve de signature déléguée sera alors inclus dans tous les événements publiés par la deuxième clé publique au nom de la première. Elle peut même être limitée dans le temps, de sorte que les jetons de délégation expirent automatiquement et doivent être renouvelés.
La question de la gestion des clés et de la sécurité est un problème très vaste avec un très grand espace de conception plein de compromis et de problèmes. Cependant, si Nostr ne peut pas protéger et maintenir l’intégrité de ces identités pour les utilisateurs, un protocole entièrement basé sur des paires de clés publique/privée utilisées comme identités ne sera pas adopté à grande échelle.
Agrandissement face à Nostr
L'ensemble du protocole Nostr repose sur quelqu'un quelque part qui exécute un serveur relais. Il n'y a pas de « réseau Nostr », juste des relais et des clients connectés aux relais. Les gens doivent être incités à gérer des relais, et cela déterminera en fin de compte dans quelle mesure les relais pourront évoluer à long terme. À moins qu’un relais Nostr puisse être rentable ou au moins rapporter suffisamment d’argent pour couvrir ses propres frais de fonctionnement, il n’y aura jamais de relais de la même taille que le serveur Twitter.
La publicité
Compte tenu de la manière dont Nostr fonctionne en tant que protocole, bloquer entièrement les publicités serait trivial, ce qui en ferait une solution irréalisable. Les serveurs relais peuvent essayer d'utiliser la publicité comme modèle de revenus, ce qui est apparemment le principal modèle de revenus pour presque tous les services gratuits en ligne, mais le problème est que les utilisateurs doivent fondamentalement s'y inscrire. Les relais peuvent facilement injecter des publicités dans les événements qu'ils envoient aux clients. , mais les clients peuvent également filtrer facilement les événements publicitaires à partir de leur interface utilisateur s'ils n'ont pas été créés par la clé publique à laquelle ils avaient l'intention de s'abonner.
Micropaiement
Les micropaiements constituent une autre solution évidente, surtout compte tenu des tentatives en cours pour intégrer le Foudre Réseau plus étroitement dans l’application Nostr. Ce modèle offre une grande flexibilité dans la façon dont vous facturez. Les relais peuvent facturer uniquement la publication d'événements sur place, le téléchargement de lectures d'événements, ou une combinaison des deux, en ajustant le prix de chacun en fonction de la quantité de ressources consommées. Cependant, il est peu probable que ce modèle puisse être étendu à l’échelle de Twitter.
Les micropaiements de contenu ont montré leur viabilité dans de nombreux produits de niche basés sur le Foudre Réseau, mais une véritable échelle mondiale pose deux problèmes fondamentaux.
Premièrement, l’adoption du Bitcoin n’est pas encore suffisante. Même si tout le monde acceptait comme par magie de payer pour chaque petite interaction de service sur Nostr, il n'y aurait pas assez de personnes détenant des bitcoins pour soutenir quelque chose d'aussi massif que Twitter. Les relais peuvent facturer des frais d'abonnement en monnaie fiduciaire, mais ces méthodes de paiement ne permettent pas de payer une somme modique pour chaque événement publié ou téléchargé.
Deuxièmement, les gens sont habitués à ce type de service gratuit. C'est exactement ce à quoi on pourrait s'attendre. Je ne pense pas que les micropaiements puissent vraiment permettre un relais à grande échelle.
Il existe un moyen de rendre les micropaiements plus « collants » ou plus durables sans les imposer à toutes les catégories d’utilisateurs qui utilisent le relais. On a beaucoup parlé de la création de diverses applications sur Nostr, à l'exception du clone Twitter. GitHub, Wikipédia et même Uber.
Le dernier point est essentiel : les attentes économiques. Les gens sont très habitués à payer des frais lorsqu'un emploi est annoncé quelque part ou à payer des frais à un opérateur de marché lorsqu'ils commandent quelque chose en ligne mais ne proposent pas des choses qu'ils pensent devoir être gratuites – Google, Twitter. Cela pourrait permettre aux relais de créer un solide pilier de revenus pour leurs utilisateurs sans créer beaucoup de frictions ni briser les attentes de l'utilisateur potentiel moyen.
Si les micropaiements doivent également être un facteur, les opérateurs de relais devront d'abord exécuter un nœud Lightning afin de recevoir les fonds des utilisateurs. Cela pourrait potentiellement augmenter les revenus s'il était correctement mis en synergie avec tout modèle de micropaiement mis en œuvre par le relais.
Plus un serveur relais génère des revenus, plus il a besoin de liquidités sur le réseau Lightning pour faciliter cela. Si les opérateurs planifient correctement la manière dont ils déploient ou distribuent les liquidités sur le réseau, le simple fait de gérer un nœud de routage pourrait devenir en soi une source de revenus importante, en plus des frais facturés pour la réception ou la transmission de données via des relais.
Conclusion
Projets sociaux Web3, en plus de ceux mentionnés ci-dessus Notre ainsi que le Mastodonte, incluent également des projets tels que Farceur ainsi que le Lens, qui ne remplacera pas rapidement les plateformes de médias sociaux existantes. Selon les statistiques, Twitter compte des centaines de millions d'utilisateurs actifs, Facebook a des milliards, mais Mastodonte a seulement 2.5 millions d'utilisateurset une Notre n'a qu'environ 220,000 XNUMX identités d'utilisateurs uniques. De nombreux projets sociaux Web3 sont confrontés à des obstacles en matière d'utilisabilité qui ralentissent leur adoption massive.
Les médias et la politique sont indissociables. À mesure que les projets sociaux Web3 prolifèrent et que la conversation publique se fragmente entre différentes applications et protocoles, des conséquences politiques peuvent survenir. Même Messina, qui plaide depuis longtemps en faveur de médias sociaux décentralisés, craint que la décentralisation n’alimente davantage un discours public marqué par l’hostilité mutuelle et l’incompréhension ces dernières années.
Avertissement: Les informations sur ce site Web sont fournies à titre de commentaire général du marché et ne constituent pas un conseil en investissement. Nous vous encourageons à faire vos propres recherches avant d'investir.
Rejoignez-nous pour suivre l'actualité : https://linktr.ee/coincu
Harold
Coincu Actualité
Autres articles
Articles Similaires
Actualité
L’affaire DEBT Box devient désormais de plus en plus compliquée avec les dissimulations de la SEC
Actualité
Les créanciers FTX peuvent recevoir jusqu'à 142 % du montant de la réclamation grâce au nouveau plan de réorganisation
Actualité
L'ETF Grayscale Spot Ethereum est désormais la priorité absolue de l'entreprise
Autres avis
Revue Fluence : la plate-forme informatique DePIN de nouvelle génération d'Internet
Actualité
L'investissement de Pantera Capital TON vise à améliorer les capacités de paiement P2P
Actualité
L’affaire DEBT Box devient désormais de plus en plus compliquée avec les dissimulations de la SEC
Actualité
90 % des volumes de transactions Stablecoin n’ont aucune participation d’utilisateurs réels
Actualité
LayerZero Airdrop suscite l’enthousiasme alors que l’instantané de la première phase est terminé
Actualité
Une erreur d'adresse entraîne une perte WBTC de 68 millions de dollars et la victime tombe dans une escroquerie par hameçonnage
Meilleurs projets
Top 10 des meilleurs robots Crypto Telegram en 2024
Connaissance
Minage de Bitcoin : combien de temps faut-il pour extraire 1 Bitcoin ?
Connaissance
Prédictions électorales américaines : effets et importance du nouveau président américain
Connaissance
Candidats potentiels aux élections américaines de 2024 : qui va gagner ?
Connaissance
