Depuis la création du bitcoin, les chaînes de blocs sont passés de composant à technique à solutionnisme technologique. Ainsi, il est assez logique que des projets comme Steem aient vu le jour. La promesse était forte puisqu’elle devait apporter à la fois de la décentralisation, de la résistance à la censure, de la gouvernance distribuée et de la monétisation.

La réalité est plutôt mitigée, car plutôt que de la décentralisation, nous avons une dizaine de nœuds nécessitant beaucoup de ressources pour répondre aux exigences des réseaux sociaux. Malgré une faible décentralisation, l’utilisation d’un registre distribué exige une grande coordination pour mettre à jour les fonctionnalités par le registre et force un seul modèle économique. Force est de constater qu’une blockchain ou un registre distribué n’est pas le modèle adapté pour supporter des applications d’échange de données résistante à la censure.

C’est là que Nostr arrive à point nommé. Puisqu’une blockchain apporte beaucoup de contraintes sans résoudre réellement la distribution du registre, pourquoi ne pas développer un protocole « client-serveur » interopérable, facile d’accès (pour les développeurs, les fournisseurs d’applications et les utilisateurs) et ne créant pas de prison dont les barreaux sont les règles du consensus ?

Nostr est l’acronyme d’un protocole de communication visant à la fois la simplicité et la résistance à la censure suffisante. Notes and Other Stuff Transmitted by Relays qui pourrait se traduire plus vulgairement par « des trucs transmis par des relais », représente l’état d’esprit du protocole.

Nostr est plutôt simple à expliquer, il existe trois types d’acteurs :

• Les utilisateurs
• Les applications utilisées par les utilisateurs
• Les relais

Les applications se connectent à autant de relais que nécessaire pour diffuser et récupérer des messages protégés cryptographiquement. L’utilisateur crée une paire de clef privée / publique à partir d’une application Nostr et y ajoute un pseudo (s’il le souhaite), une photo de profil (s’il le souhaite), une adresse de site web et les relais qu’il veut utiliser. Ces informations représentent son identité qu’il recopiera sur autant de relais qu’il le souhaite.

Contrairement à Mastodon et aux systèmes de fédération, son identité est transposable sur l’ensemble des relais sans effort supplémentaire à fournir par l’utilisateur. Cependant, Nostr n’est pas un registre distribué, ce qui veut dire qu’il n’y a pas d’annuaire d’identité partagé par tous les relais.

Vu comme un point noir, c’est pourtant un avantage immense puisque que la création d’un relai n’implique pas de porter l’ensemble des identités des utilisateurs Nostr.

Les relais ont pour mission de récupérer, stocker et transmettre les messages aux utilisateurs. Et bien qu’ils soient libres de supprimer des messages, ils ne peuvent pas en modifier le contenu. En effet, ces derniers sont signés par la paire de clef de l’utilisateur ayant créé le message. Un administrateur de relais peut également appliquer une liste noire ou blanche sur les utilisateurs. Il reste donc maitre de son relai sans que cela ait réellement d’impact pour les utilisateurs qui en utilisent eux-même plusieurs.

Concernant la transmission de message, c’est assez similaire. Malgré toutes les fonctionnalités proposées par Nostr à travers une série de NIP (Nostr Improvement Proposal), seul NIP-01 est obligatoire. Il définit le mode de communication entre les applications et les relais. Tout le reste est optionnel.

Une nouvelle fois, cela peut être vu comme un point noir. C’est cependant une force puisque ni les relais ni les applications ne sont enfermés dans les règles lourdes d’un registre distribué. Résultat, chaque nouvelle proposition peut être intégrée librement par les développeurs. Une application se spécialisant dans un cas d’usage n’a pas besoin de devoir comprendre l’ensemble des fonctionnalités. Un développeur peut itérer à son rythme sur son projet.

Pour donner un exemple, Nostr permet à la fois l’utilisation d’applications proche de Twitter (comme Astral ou de communication serveur à serveur comme Una-Connect).

Ces deux types d’applications n’ont pas les mêmes besoins et utilisent des fonctionnalités (NIP) différentes. C’est un protocole souple et très évolutif puisqu’un développeur peut proposer un NIP répondant à un cas d’usage sans nécessiter une lourde mise à jour à l’instar des protocoles blockchain.

Bien qu’un relai puisse appliquer de la censure, la création d’un relai est plutôt simple et un client peut souscrire à des relais concurrents et y republier l’ensemble du contenu.

Pas de monétisation prévue par défaut. Pas de token natif non plus. Je vous le rappelle, seul NIP-01 est obligatoire. Faire tourner un relais ne permet ni de ‘stacker’ des tokens ni de gagner de « rewards ». Cependant, Nostr est très souple. Il est possible de développer et d’utiliser un relai payant dans n’importe quel devise. Les utilisateurs, les développeurs, les administrateurs de relais sont libres de créer et utiliser n’importe quel modèle économique avec n’importe quel monnaie (même des euros). Il existera probablement à terme des relais monétisant leurs services bien que cela ne sera pas systématique.

Côté anti-spam et anti-sybil. C’est identique, il n’y a rien et ici c’est encore à l’imagination des développeurs de proposer des solutions. Il est par exemple possible d’utiliser la preuve de travail pour filtrer les messages (au niveau des relais et des applications). Concrètement, tout comme Bitcoin, cela oblige à un utilisateur à dépenser de l’énergie (à travers son application) pour produire un message qui sera accepté par les relais et/ou les applications. La quantité pourrait être infime (quelques secondes pour produire le message) et suffisant pour dissuader les spammeurs. C’est une nouvelle fois optionnel et il est facile de chercher la meilleure approche en fonction du contexte.

Le fait que les fonctionnalités soient optionnelles permet d’avoir un protocole sur mesure sans sacrifier l’interopérabilité entre les applications. Les NIPs étant publics sur GitHub, un écosystème de développeur bouillonne d’idées.

Si vous souhaitez expérimenter Nostr, voici deux applications amusantes : Astral est une sorte de clone de Twitter et Anigma reprend les codes de Telegram avec la différence notable, le non-chiffrement des salons (les messages privés le sont) et l’absence de phase d’enregistrement. Votre clef privée peut être réutilisée et les messages privés sont accessibles entre les deux applications.

Le lien suivant présente une compilation de l’ensemble des projets tournant autour de Nostr. Il s’étoffe au fil du temps : https://github.com/aljazceru/awesome-nostr

Nos derniers articles