Comment fonctionne Nostr et pourquoi un réseau social sans serveur unique fonctionne

Presque chaque protocole de réseau social décentralisé finit par devenir un monstre. ActivityPub traîne des serveurs Mastodon lourds, où un bannissement sur un nœud vous coupe de la moitié du public. Les réseaux P2P comme Scuttlebutt rencontrent des problèmes de synchronisation sur les appareils mobiles et vident la batterie en une demi-journée.

Le créateur du protocole Nostr (qui signifie Notes and Other Stuff Transmitted by Relays) a adopté l'approche inverse : supprimer les blockchains, supprimer les protocoles P2P complexes, et ne garder que la cryptographie et de simples relais WebSocket.

L'idée centrale

Nostr n'est pas un réseau social prêt à l'emploi ni une application autonome. C'est une spécification pour les interactions réseau qui tient dans une paire de dizaines de courts documents (NIPs, Nostr Implementation Possibilities).

Vous n'avez pas de login, mot de passe ou numéro de téléphone. Un compte est une paire de clés cryptographiques : privée (secp256k1) et publique. Votre clé publique sert d'identifiant, et vous signez chaque action avec votre clé privée.

Chaque message, article, réaction ou changement d'avatar est appelé un événement dans la terminologie du protocole. En substance, c'est un objet JSON classique :

{
  "id": "4376c65d2f23493d6050d0c393d01f50252a607d58eab305699c6811ea70017d",
  "pubkey": "9fe415e4177d13521649f80e4293097b540e555d34a14f4e2454b62412f93008",
  "created_at": 1672531199,
  "kind": 1,
  "tags": [],
  "content": "Привет, это тестовый пост в Nostr!",
  "sig": "250e938424f...подпись...4e8f9b"
}

Le client forme un tel JSON, le signe avec votre clé privée et l'envoie via WebSocket à un ou plusieurs serveurs relais.

Comment fonctionnent les relais

Un relais est un serveur simpliste. Il ne sait pas qui vous êtes et se moque de la logique de votre application. Ses tâches sont :

• Accepter du JSON via WebSocket.
• Vérifier la signature de l'auteur.
• Stocker l'événement dans une base de données (généralement SQLite ou PostgreSQL).
• Distribuer l'événement aux abonnés qui ont demandé un filtre par votre pubkey.

Si le propriétaire d'un relais spécifique décide de vous bannir, vous basculez simplement votre client vers cinq autres relais. Vos abonnés trouveront vos publications, car la signature de l'auteur est toujours là, et le relais ne peut pas falsifier le texte du message sans la clé privée.

Dans le même temps, les relais peuvent être payants (anti-spam via abonnement ou micropaiements), privés (uniquement pour les employés d'une entreprise) ou publics.

Le principal problème d'ingénierie

En théorie, tout semble parfait : de nombreux relais, pas de censure. En pratique, une question se pose : comment le client du lecteur sait-il vers quels relais exacts l'auteur envoie ses publications ?

Si vous êtes abonné à 500 personnes, interroger des milliers de relais existants est coûteux. La communauté a adopté le modèle Outbox (NIP-65). L'auteur publie une liste des relais où il écrit (relais d'écriture). L'abonné demande cette liste et s'y connecte uniquement. Pour l'optimisation, les clients trouvent les intersections et maintiennent des connexions ouvertes vers seulement 10-15 serveurs.

Ce que les développeurs construisent sur Nostr

Grâce à la simplicité de la spécification, les gens ont commencé à construire sur Nostr bien au-delà du simple microblogging :

• Des clients comme Damus (iOS), Amethyst (Android) ou Coracle (Web) pour une communication de style Twitter.
• Des plateformes pour les articles de longue forme (NIP-23), où les publications sont stockées en Markdown.
• Des messagers P2P avec chiffrement des messages utilisant la clé publique du partenaire de conversation.
• Des systèmes d'authentification de sites web (NIP-07), où une extension de navigateur signe la requête au lieu de saisir un login et un mot de passe.

Des bibliothèques pour travailler avec le protocole existent pour pratiquement n'importe quelle pile : Go, Rust, TypeScript, Python, Dart. Écrire un client minimal qui se connecte à un relais et écoute un flux de publications peut littéralement se faire en 30-40 lignes de code.

Faut-il creuser plus profond

Nostr n'est pas parfait. Il est difficile d'organiser la recherche sans des indexeurs tiers, il n'y a pas de suppression de données intégrée (une publication supprimée peut rester indéfiniment sur un relais récalcitrant), et la synchronisation entre plusieurs clients échoue parfois.

Mais si vous êtes intéressé par un design réseau propre et minimaliste sans surdimensionnement, le dépôt mérite définitivement l'exploration. Commencez par la spécification des événements de base dans NIP-01, et vous pouvez essayer des clients prêts à l'emploi via le catalogue sur nostrapps.com.