Protocoles sociaux décentralisés comparés : Nostr vs AT Protocol vs ActivityPub vs Farcaster

Il n’existe pas un seul « meilleur » protocole social décentralisé — la bonne réponse dépend du type de souveraineté que vous recherchez réellement. Si vous voulez une identité qu’aucun serveur ne peut émettre, révoquer ou tarifer, Nostr va le plus loin; si vous voulez cette autopossession plus un filet de sécurité en cas de perte de clé, AT Protocol échange un peu de décentralisation contre une véritable récupérabilité; si vous voulez le plus grand réseau fonctionnel aujourd’hui avec des identifiants lisibles par l’humain, ActivityPub est l’option mature et éprouvée; et si vous voulez une identité ancrée à un registre onchain immuable, Farcaster ancre votre compte onchain sur OP Mainnet (Ethereum L2). Voici une analyse équitable et sourcée à partir des spécifications — forces réelles et inconvénients honnêtes pour chacun, chaque affirmation étant fondée sur la documentation primaire de chaque projet.

Nous nous appuyons sur les épaules de ceux qui ont accompli ce travail : Nostr (créé par fiatjaf et une communauté ouverte de contributeurs aux NIP, réutilisant délibérément la cryptographie secp256k1/Schnorr de Bitcoin), AT Protocol (Bluesky Social PBC et la communauté atproto), ActivityPub (le W3C Social Web Working Group, Evan Prodromou, Christine Lemmer-Webber et Eugen Rochko de Mastodon) et Farcaster (Merkle Manufactory et les contributeurs du protocole Farcaster). Cette page ne dénigre jamais aucun d’entre eux — elle énonce ce que chacun fait bien et là où chacun présente honnêtement des limites.

Le comparatif à 8 dimensions

Profils des protocoles : forces et l’inconvénient honnête

Nostr — autosouveraineté maximale, aucun filet de sécurité

L’identité de Nostr est aussi autosouveraine qu’il est possible : vous générez votre propre paire de clés secp256k1 sans la permission de qui que ce soit, sans compte serveur, sans chaîne de blocs et sans coût — la clé publique est le compte. Tout le modèle tient dans une petite spécification (NIP-01) : les identifiants d’événements SHA-256 et les signatures Schnorr rendent chaque événement vérifiable indépendamment, et diffuser le même événement signé sur des relais indépendants procure une véritable résistance à la censure sans gardien. Il crédite délibérément ses prédécesseurs, réutilisant la cryptographie de Bitcoin et les primitives standard DNS/bech32 plutôt que d’inventer les siennes. Inconvénient honnête : cette même pureté signifie que la clé n’est pas rotative — perdez votre nsec et l’identité disparaît à jamais; laissez-la fuir et un attaquant peut usurper votre identité indéfiniment. Il n’y a aucune réinitialisation de mot de passe, aucune révocation, aucune rotation dans le protocole central; la migration de clé demeure un brouillon non fusionné. C’est le prix direct de n’avoir aucune autorité au-dessus de vous — et cela rend une gestion de clés rigoureuse non négociable.

AT Protocol (Bluesky) — la voie médiane pragmatique

AT Protocol trace une voie médiane délibérée. La portabilité du compte est une fonctionnalité de première classe, définie par la spécification : le même DID + identifiant + dépôt complet peut se déplacer entre hôtes PDS via export/import CAR — ce que la plupart des systèmes fédérés ne peuvent tout simplement pas faire. Le dépôt est un Merkle Search Tree signé, de sorte que n’importe quel hôte peut le servir et n’importe quel client peut le vérifier sans faire confiance à l’hôte. Point crucial, les clés de rotation ordonnées par priorité de did:plc plus une fenêtre de récupération de 72 heures résolvent le problème « clé perdue = identité perdue à jamais » que Nostr, délibérément, ne résout pas — un avantage authentique et honnête. Les identifiants réutilisent la confiance DNS existante, et l’ensemble s’aligne proprement sur le DID-core du W3C. Inconvénient honnête : la couche d’identité comporte aujourd’hui un véritable point de centralisation — la méthode did:plc par défaut dépend d’un annuaire PLC global unique encore exploité par Bluesky Social PBC (la gouvernance est en cours de transfert, mais la transition n’est pas terminée), et le relais et l’AppView dominants sont eux aussi exploités par Bluesky. Bluesky l’affirme ouvertement et maintient les pouvoirs de l’opérateur étroits (déni de service/désordonnancement seulement, jamais la saisie de clés), mais ce point de confiance à opérateur unique est l’inconvénient équitable.

ActivityPub (Mastodon / Fediverse) — le réseau mature qui fonctionne à grande échelle

ActivityPub est le seul protocole ici à être une Recommandation ratifiée du W3C (2018), et il constitue l’ossature du plus grand réseau social décentralisé en activité — Mastodon plus le Fediverse au sens large (Threads, PeerTube, Pixelfed et d’autres) — ce qui lui confère une échelle réelle et une interopérabilité qu’aucun rival n’égale. Ses identifiants @user@domain conviviaux n’exigent aucune gestion de clés de la part des utilisateurs, aucun serveur unique ne contrôle le réseau, n’importe qui peut auto-héberger, et un outillage de modération mature par serveur le rend sûr et exploitable à l’échelle de millions d’utilisateurs. Inconvénient honnête : son identité est sous la garde du serveur et liée au domaine, non cryptographiquement autosouveraine. Aucune clé détenue par l’utilisateur n’est votre compte, de sorte que l’administrateur de votre serveur d’attache peut vous suspendre ou vous supprimer, et la migration de compte déplace vos abonnés mais pas vos publications (« Your posts will not be moved, due to technical limitations », soit vos publications ne seront pas déplacées, en raison de limitations techniques) tout en changeant votre identifiant et l’URI de votre id. Vous faites en définitive confiance à un opérateur et à un domaine que vous ne possédez habituellement pas; les correctifs DID/id-portable demeurent expérimentaux et non déployés dans les implémentations grand public.

Farcaster — identité ancrée onchain

L’identité de Farcaster est véritablement onchain et sécurisée par Ethereum : le FID est un nombre dans un contrat Id Registry immuable sur OP Mainnet, de sorte qu’aucun serveur ne possède votre compte. Elle est portable (le FID se transfère entre adresses Ethereum), et une adresse de récupération désignée par l’utilisateur offre une véritable récupération en cas de perte de clé — un avantage direct sur la clé non rotative de Nostr. La signature des messages est déléguée à des clés Ed25519 « Signer », si bien qu’une clé d’application compromise peut être révoquée sans perdre le compte. Les données utilisateur résident sous forme de CRDT répliqués sur un réseau de hubs sans permission (Snapchain), séparant proprement l’état onchain critique pour la sécurité des données sociales à fort volume. Inconvénient honnête : l’identifiant lisible par l’humain gratuit est révocable de façon centralisée, et le compte n’est pas gratuit à maintenir. Les Fnames sont contrôlés par le registre de Farcaster et « may be reclaimed » (peuvent être repris) selon le jugement humain (personnalités publiques, plus de 60 jours d’inutilisation, ou revente), de sorte que l’identifiant que la plupart des utilisateurs voient réellement n’est pas résistant à la censure à moins de payer pour un nom ENS onchain. Par-dessus le marché, l’existence comporte un coût continu — du gas onchain plus un loyer de stockage récurrent, avec des messages élagués après une période de grâce de 30 jours si le loyer expire. Le FID onchain est décentralisé; les couches de l’identifiant et de l’économie d’hébergement sont sensiblement plus centralisées et ont été pilotées en grande partie par une seule entreprise (Merkle Manufactory).

Les compromis honnêtes

Chacun de ces protocoles paie ses forces quelque part. Il n’y a pas de repas gratuit dans l’identité décentralisée — vous choisissez quel compromis vous pouvez accepter.

• Nostr : autosouveraineté contre récupérabilité. L’absence de toute autorité est précisément la raison pour laquelle il n’y a aucun filet de sécurité. Une clé non rotative signifie que la perte de clé est permanente et irréversible, et une clé ayant fuité constitue un risque d’usurpation permanent. Si vous adoptez la souveraineté de Nostr, vous assumez aussi la pleine responsabilité de la garde.
• AT Protocol : récupérabilité contre un opérateur unique. Vous obtenez la rotation de clés et une fenêtre de récupération de 72 heures — le correctif de la plus grande faiblesse de Nostr — mais aujourd’hui cela s’accompagne d’une dépendance à un annuaire PLC global unique et à des identifiants fondés sur le DNS. La sortie vérifiable est solide; l’immuabilité sans permission, elle, ne l’est pas (encore).
• ActivityPub : convivialité et échelle contre garde. Aucune gestion de clés, un immense réseau en activité et des identifiants conviviaux — mais votre identité et votre historique de publications vivent à la merci d’un exploitant de serveur et d’un domaine que vous ne possédez pas. La portabilité protège votre graphe social, pas vos données ni votre nom.
• Farcaster : permanence onchain contre coût et un identifiant révocable. Votre FID est insaisissable et récupérable, mais vous payez du gas et un loyer récurrent pour le conserver, et le @handle gratuit peut être repris selon le jugement humain. Seul le paiement d’un ENS rend l’identité visible aussi résistante à la censure que le FID sous-jacent.

Lequel devriez-vous utiliser ?

Faites correspondre le protocole à la souveraineté dont vous avez réellement besoin. Trois grands modèles couvrent le terrain :

Natif à paire de clés (vous détenez le compte lui-même) : Nostr

Choisissez Nostr si votre premier principe est « personne n’émet, ne révoque ni ne tarife mon identité, jamais ». Vous obtenez un compte qu’aucun gardien ne contrôle, sans coût, et une portabilité complète entre relais et clients. L’engagement : vous devez gérer votre propre clé avec une réelle discipline, car il n’y a aucune récupération. C’est l’expression la plus directe de l’éthos de souveraineté — et celle qui exige le plus de vous.

Hébergé sur une instance (un opérateur vous héberge, les standards vous gardent portable) : ActivityPub, ou AT Protocol pour la portabilité-avec-récupération

Choisissez ActivityPub si vous voulez rejoindre le plus grand réseau en activité aujourd’hui avec zéro gestion de clés et un identifiant familier @user@domain — en acceptant que votre serveur d’attache assure la garde et que le départ abandonne vos publications. Choisissez AT Protocol si vous voulez cette commodité hébergée plus une véritable portabilité de compte et une récupération de clés : vous pouvez migrer le même DID, identifiant et dépôt complet entre hôtes, et les clés de rotation vous offrent un retour possible après une clé compromise. Le bémol à peser est la dépendance actuelle à un opérateur unique dans l’annuaire did:plc.

Ancré onchain (votre compte est un enregistrement sur un registre public) : Farcaster

Choisissez Farcaster si vous voulez que votre identité soit ancrée à un registre onchain immuable avec une récupération de perte de clé intégrée, et que vous êtes à l’aise de payer du gas plus un loyer de stockage continu pour cette permanence. Prévoyez simplement un budget pour un nom ENS si vous avez besoin que l’identifiant visible soit aussi résistant à la censure que le FID qu’il recouvre — le Fname gratuit est pratique mais reprenable.

FAQ

Nostr est-il plus résistant à la censure que Bluesky ?

À la couche d’identité, oui — de manière significative. Le compte de Nostr est une paire de clés que personne n’émet, et aucun registre central n’existe pour la révoquer; la résistance provient de la diffusion d’événements signés sur de nombreux relais indépendants. L’AT Protocol de Bluesky est cryptographiquement solide (dépôts auto-certifiants, DID récupérables) mais sa méthode did:plc par défaut dépend actuellement d’un annuaire global unique exploité par Bluesky, et son relais/AppView dominant peut se défédérer — de sorte que sa résistance réelle aujourd’hui est la « sortie vérifiable », non le modèle sans gardien qu’utilise Nostr. La réserve honnête joue toutefois dans l’autre sens : les deux partagent la même limite pratique — si les relais (Nostr) ou le PDS/relais (atproto) où votre audience lit réellement vous abandonnent, votre portée en souffre même si votre identité survit. Aucun n’est à l’épreuve du retrait; Nostr est résistant au retrait sans aucune autorité auprès de qui faire appel, tandis que Bluesky est résistant au retrait en vous permettant de migrer la même identité ailleurs.

Lequel me permet de vraiment posséder mon identité ?

Nostr offre la possession la plus pure : la clé privée est le compte, détenue par vous seul, sans serveur, sans frais et sans aucune autorité pouvant la révoquer. Farcaster suit de près dans un sens différent — votre FID réside dans un registre onchain immuable qu’aucun serveur ne possède, avec une adresse de récupération comme filet de sécurité (bien que vous payiez pour le conserver, et que l’identifiant gratuit soit révocable). AT Protocol vous donne un contrôle cryptographique via les clés de rotation plus la récupération, avec une dépendance actuelle à un seul opérateur d’annuaire. ActivityPub est l’exception : il n’existe aucune clé détenue par l’utilisateur qui soit votre compte, de sorte que votre identité est sous la garde d’un exploitant de serveur. Si « posséder » signifie « personne d’autre que moi ne peut détenir ou saisir l’identifiant », Nostr est la réponse, le FID onchain de Farcaster étant la plus solide des alternatives.

Puis-je déplacer mon compte vers un autre serveur ?

Cela dépend du protocole. Sur Nostr, il n’y a rien à « déplacer » — votre paire de clés n’est liée à aucun serveur, alors vous publiez simplement sur différents relais et portez la même identité partout. Sur AT Protocol, la migration est une fonctionnalité de première classe : votre DID et votre identifiant restent constants tandis que votre dépôt complet est exporté (sous forme de CAR file) et importé vers un nouveau PDS. Sur Farcaster, votre FID se transfère librement entre adresses Ethereum, et vos données sont déjà répliquées sur le réseau de hubs plutôt que sur un seul hôte. Sur ActivityPub, le déplacement n’est que partiel — la fonction « Move » de Mastodon migre vos abonnés mais explicitement pas vos publications, et vous recevez un nouvel identifiant et URI sur le nouveau serveur.

Ces identités correspondent-elles à un DID (identifiant décentralisé) du W3C ?

Seul AT Protocol correspond proprement et officiellement : il utilise les méthodes DID-core du W3C did:plc et did:web comme primitive d’identité. Nostr a une proposition did:nostr, mais c’est un brouillon communautaire en cours d’élaboration, pas une norme ratifiée ni un NIP central. La spécification ratifiée d’ActivityPub n’utilise pas du tout les DID — une correspondance DID n’existe que sous forme de proposition communautaire non officielle et non déployée (FEP-ef61). Farcaster ne définit aucune méthode DID du W3C dans sa spécification primaire; l’identité est le FID numérique brut. Si l’alignement sur DID-core compte pour votre pile, AT Protocol est le seul à le livrer aujourd’hui.

Que se passe-t-il si je perds ma clé ?

C’est la ligne de partage la plus nette. Sur Nostr, une clé privée perdue ou volée est permanente et irrécupérable — il n’y a aucune réinitialisation, aucune révocation et aucune rotation dans le protocole central, de sorte que votre seul recours est d’abandonner la clé, de créer une nouvelle identité et de reconstruire votre graphe d’abonnés à la main. AT Protocol et Farcaster résolvent tous deux ce problème : le did:plc d’AT Protocol utilise des clés de rotation ordonnées par priorité avec une fenêtre de récupération de 72 heures, et Farcaster permet à une adresse de récupération désignée par l’utilisateur de restaurer le contrôle du FID. ActivityPub élude entièrement la question — il n’y a aucune clé utilisateur à perdre, mais c’est parce que votre identité est sous la garde d’un exploitant de serveur, ce qui constitue son propre compromis. Si la récupération en cas de perte de clé est une exigence stricte, AT Protocol ou Farcaster conviennent mieux que des clés Nostr brutes.

Sources primaires

Chaque cellule factuelle ci-dessus est fondée sur la spécification ou la documentation primaire propre à chaque protocole :

• Nostr : NIP-01 (bases du protocole, modèle événement/identité), NIP-05 (name@domain), NIP-19 (npub/nsec bech32), le brouillon did:nostr du Nostr Community Group, et la proposition non fusionnée Key Migration and Revocation (nips PR #1452).
• AT Protocol : atproto.com/specs/did, /specs/handle, /specs/repository, /specs/account, /guides/account-migration, la spécification did:plc v0.1, et atproto.com/blog/plc-replicas.
• ActivityPub : la Recommandation ActivityPub du W3C, le WebFinger de Mastodon, la documentation de migration de compte (« moving ») et de modération, les serveurs de joinmastodon.org, et le brouillon communautaire FEP-ef61 « Portable Objects ».
• Farcaster : la SPECIFICATION du protocole Farcaster (Id Registry, Signers, Storage Registry, hubs/CRDT, preuves de nom d’utilisateur), et la documentation d’architecture de Farcaster sur overview, contracts, et les noms ENS/Fname.

Là où une affirmation ne pouvait pas être citée verbatim depuis une spécification — notamment la caractérisation « gratuit pour exister » d’AT Protocol et d’ActivityPub, et l’absence d’une méthode DID du W3C dans la spécification de Farcaster — cela est signalé en ligne comme déduit de l’architecture plutôt qu’énoncé comme disposition explicite, afin que vous puissiez juger vous-même des preuves.